Spent this week trimming glue code out of an agent setup, letting Claude write straight to a Postgres function instead of routing through three API layers I built last month. Felt good to delete more than I added for once. Also kept coming back to one piece about how we argue over AI risk, and why the loudest arguments feel useless in practice.
AI as normal technology beats both loud camps
There are two camps that eat up most of the oxygen when people talk about AI risk. One says we're building something that might end us and we should probably stop. The other says we're on the ramp to a world so much better that any caution is just cowardice. I read both and mostly feel like neither describes the work I do on any given Tuesday.
A piece from Normal Tech this week put a name to what I've been circling. It argues that cybersecurity's incident-response playbook might be a better fit for AI risk than the alignment-vs-nothing binary. That landed for me. Because the systems I ship don't fail in cinematic ways. They fail the way software fails. A tool schema grows past a dozen params and Claude's function-calling gets shaky. An agent takes one bad step and the whole chain rots downstream. A long-horizon run drifts somewhere around hour three and comes back with confident garbage.
None of that is existential. None of it is utopia either. It's the normal texture of running things in production, and the field that already knows how to think about it is security, not philosophy.
What the normal frame actually buys you
When I treat an agent like a system that will fail rather than a mind that might wake up, my choices change. I build failure modes before I build capability. I put memory in an actual database table with expiration logic instead of a bigger context window and hoping. I add a kill switch and drift detection because I assume the thing will wander, not because I fear it wants to. That's the same posture I'd take with any service that touches production data.
The doomer frame tells you to slow down and the accelerationist frame tells you the brakes are cowardice. Neither tells you where to put the retry logic. Incident response does. Detect, contain, recover, learn, ship the fix. That loop has run enterprise infrastructure for twenty years and it doesn't care whether the threat is a misconfigured firewall or a model calling a Postgres function it shouldn't.
The useful question isn't how afraid to be. It's what happens on the bad step, who catches it, and how fast you recover. I've rebuilt infrastructure under acquisition deadlines and migrated live billing systems over a weekend. The projects that held up weren't the ones with the grandest vision. They were the ones where I'd already thought through what breaks and had a plan for the morning after.
3 things worth your time
1. Detect-and-respond is measuring graceful failure
A millisecond threat doesn't care about your mean-time-to-response. The argument for building prevention (code that never runs) over detection (code you catch after) is worth sitting with, especially as autonomous attacks speed up.
2. Identity debt becomes an agent problem
Years of orphaned accounts and over-broad permissions sit quietly until an agent inherits them and moves faster than any audit cycle. Application-level kill switches and drift detection are the right shape of answer.
3. AI accelerates output, not innovation
Coding throughput goes up. Architectural and creative thinking doesn't move much. Matches what I keep seeing: models are great scaffolding and still bad at the decisions that need someone who's stared at bad embeddings before.
Curious whether anyone else has quietly borrowed their security instincts for agent work. Reply and tell me what your bad-step plan looks like.