· ai · agentic · opinion · —
AI Writes the Code. You Still Own the Decisions.
AI coding agents got genuinely good, and that makes judgment more valuable, not less. A field report on where they earn their keep, where they quietly cost you, and what never leaves your hands.
The pitch for AI coding assistants keeps swinging between two silly poles. Either they're about to replace every engineer, or they're autocomplete with a marketing budget. Neither is true, and after a couple of years of using them on real work rather than demos, I've landed somewhere less dramatic and a lot more useful.
The agents are good. Good enough that the interesting question stopped being "can it write the code?" The question now is "which decisions am I still on the hook for?" That reframing is the whole point of this post.
Where agents genuinely earn their keep
There's a category of work that is mechanical but tedious, and this is where an agent pays for itself in the first ten minutes.
Boilerplate is the obvious case: wiring a form, scaffolding a route, stamping out the tenth variation of a component. The bigger win is unfamiliar surface area. When I'm three layers deep in a library I've never touched, an agent that has read its docs gets me to a working first draft faster than I'd get through the README myself.
Test scaffolding is another. I describe the behaviour, let the agent enumerate the cases, then I prune the noise and sharpen what's left. And translation work is almost pure profit: "port this Python script to TypeScript," or "convert this handler to the new async signature." High effort, low judgment, easy to check.
That last part is the common thread. Every one of these tasks is well specified and cheap to verify. I know a good answer when I see it, and reading is faster than writing.
Where it quietly costs you
Flip that thread and you find the failure modes.
Anything where the specification is the hard part, the agent will confidently hand you something plausible and wrong. Ambiguous requirements, a domain rule that only lives in someone's head, a design that has to survive three future features: the output looks right and isn't. It's rarely broken in an obvious way. It's subtly not what you meant, and you find the gap two hours later when the edge case shows up in production.
Debugging is the other trap. Agents are pattern matchers, so a genuinely novel bug is, by definition, off the path they know. I've watched one cheerfully "fix" the same symptom five times while the actual cause sat untouched. At some point the honest move is to close the chat and read the stack trace yourself.
There's also a tax nobody puts on the label: review load. Code you didn't write is code you have to understand before you can trust it. Generate enough of it fast enough and you haven't removed the bottleneck, you've just moved it from typing to reviewing, and reviewing is the more expensive skill.
The model can write the code. It can't decide whether the code should exist.
What never leaves your hands
Take away the parts the agent is good at and you're left with a surprisingly clear picture of the actual job.
Problem framing: deciding what to build, and more often what not to. Taste: the difference between code that passes and code the next person can live in. Verification: owning the claim that this is correct, because "the AI wrote it" is not a defense that survives an incident review. And architecture: the load-bearing calls that are cheap to make today and ruinous to change in six months.
None of those are typing problems. They're judgment problems, and judgment is exactly the thing that doesn't transfer to the model.
How I actually work now
My loop changed shape. I spend less time on the first draft and more on the two ends of it.
At the front, I frame the problem tightly enough that the agent can't wander: small scope, constraints stated up front instead of corrected after the fact. At the back, I review the output the way I'd review a pull request from a junior engineer, because functionally that's what it is. I read every line before it lands.
When the task is genuinely hard, the kind where the difficulty is the thinking, I still reach for the agent. But I use it as a sounding board, not an author.
The tools got good. That didn't make the engineer optional. It made the engineer's judgment the entire job, which is the part I wanted to be doing in the first place.