Coding with agents without losing control of the code

The promise holds: an agent delivers in an hour what used to take a day. What almost nobody mentions is what happens next with the thousand lines nobody has read carefully.

The bottleneck moved, it did not disappear

Writing used to be the expensive part and reviewing the cheap one, because whoever reviewed usually understood how the code got there. Now writing is cheap and reviewing costs the same — but there is far more to review and no human remembers why each decision was made.

The typical outcome: it gets approved on sight. And code approved on sight works, right up until it has to change.

What we do

• Small, verifiable tasks. A change that can be reviewed in ten minutes gets reviewed. A thousand-line one gets accepted. If the agent proposes something large, it gets split before starting, not after.
• The test before the implementation. If there is a test that fails and then passes, there is evidence. Otherwise there is only trust.
• Verify properly, do not read the summary. An agent can report that something works when it does not. It happened to us this very week: a remote command returned “success” without having executed anything. If the agent says it fixed something, check against the system, not against its message.
• The why, in the code. Comments matter more than before, and they should explain the decision, not the syntax. Six months from now nobody will be able to ask the agent why it chose that path.

The rule that has served us best: if you cannot explain the change to a colleague, do not merge it. It does not matter that the tests pass.

Where they genuinely pay off

Not everywhere equally. They pay off enormously on mechanical, verifiable work:

• Repetitive migrations — changing an API across forty files.
• Tests for code that already exists and works.
• Exploring somebody else's code: “where is this calculated?”
• First versions of something that will change anyway.

They pay off far less where the decision matters more than the keyboard: designing a data model, choosing between two architectures, deciding what NOT to build. There the agent proposes reasonable and occasionally wrong things with equal confidence, which is precisely the dangerous combination.

And one thing this project reminded us of

Working fast with agents, it is easy to overwrite a file and lose what was in it. If the project is not under version control, recovery depends on luck.

The speed agents give is only safe on top of basic hygiene: a repository, branches, and the ability to go back. Without that you are not moving faster, you are taking on more risk at the same speed.