Back to Blog
4 min read

AI Writes It. You Answer for It.

Getting an AI to produce code is the easy part now, and it's not the part that matters. What matters is everything after: reviewing it, constraining it, and keeping it consistent, because the model that wrote it won't be around to explain it, fix it, or answer for it. You will.

Listening · AI Writes It. You Answer for It.

The first time an AI agent deleted a database on me, it apologized very politely. It was mine, in dev, so no real harm done, but the pattern is the one everybody's met by now: the agent is working away, decides a step needs doing, runs it, and somewhere in there does something irreversible before anyone can say wait. "Sorry, I just dropped that table." It's a cliché at this point precisely because it happens so reliably.

That's the whole thing in one anecdote. The model is fast, confident, and occasionally catastrophically wrong, and it has no skin in the game. Which means the skill that actually matters now isn't getting it to write code. It's owning the code it writes.

Review it like a junior's pull request

The single most useful mental model: treat every AI change as a pull request from a fast, capable junior who does not know your system. Not as output. Not as an answer. As a diff to be reviewed.

That means you read all of it. You leave comments. You send it back when it's wrong. "It compiles and the tests pass" is where your review starts, not where it ends, because a junior can absolutely write code that compiles, passes the thin tests you have, and quietly does the wrong thing. The AI is a tireless, quick junior with a confident tone and no memory of why anything in your codebase is the way it is. Review it accordingly, every time, even, especially, when it looks right.

Guardrails, because it will do the oopsie

Given that it will occasionally run the destructive thing, the answer isn't to trust harder, it's to make the destructive thing impossible to do by accident. Never let an agent run irreversible operations unsupervised. Work on branches, not main. Keep backups you've actually restored. Require an explicit confirmation step before anything drops, deletes, or overwrites. Sandbox it away from production credentials entirely.

None of this is about the model being malicious. It's about the model being fast and wrong at the same time, which is a genuinely new combination to design around. A slow human doing damage gives you time to notice. An agent does it in the half-second between deciding and doing. Your guardrails are the only thing standing in that gap.

The consistency tax

Here's a subtler cost that shows up later, and I felt it most during a big migration. Give the model the same kind of task in a dozen places and you get a dozen subtly different answers: naming that drifts, patterns that don't match the file next door, the same idea written three ways. Each piece is fine alone. Together they're a codebase that reads like it was written by a dozen strangers, because effectively it was.

That inconsistency is a bill you pay every time you go back to change something. A codebase where similar things look similar is one you can hold in your head. One where every corner has its own dialect is one you re-learn on every visit. So part of owning AI code is refusing to let it reinvent conventions you already have. Hold it to your house style, and reject the change that works but matches nothing around it.

Autonomy scales the mistakes, not just the output

The last lesson is the one that changed how I actually work. The more rope you give an agent to run a big, broad task on its own, the worse it gets, not linearly, but sharply. On a small, bounded task it's excellent. Turn it loose on something large and unsupervised and it drifts: it loses the thread, abandons the conventions it started with, and makes a hundred little decisions you'd never have signed off on individually. I've pulled back from handing agents the big, broad jobs for exactly that reason. In isolation, unsupervised, at scale, it is not good.

So the shape that works is small chunks, tight scope, and a human in the loop between them. Autonomy feels like leverage, and it is, but it's leverage on the errors as much as the output. The bigger the swing you let it take alone, the more of it you'll be untangling afterward, usually right when you thought you were done.

AI-generated code was never free code. It's code you now have to review, constrain, keep consistent, and answer for, forever, exactly like code a person wrote, except the person is gone the moment it's generated. The writing got cheap. The owning costs precisely what it always did, and it's still the actual job.

Share this article

Want to Work Together?

Let's discuss how I can help with your project.

Get in Touch