Article
The shift this year was from AI that completes a line to AI that takes a task. Terminal-based coding agents plan a change, edit across files, run the tests, and open the pull request. Used well, they let a senior engineer do the work of a small team. Used badly, they produce a codebase nobody has read, with vulnerabilities the author never saw because there was no author.
The difference is not the tool. It is what sits between the tool's output and production. We use five gates, and none of them are optional.
Gate one: a task that can be reviewed
An agent given "make the checkout better" produces a change nobody can evaluate. An agent given "add address validation to the checkout form using the existing validation helper, with tests for the three failure cases" produces a change one person can read in ten minutes. Task shaping is the first gate and it is done by a human before the agent starts. Large tasks are split until each piece is reviewable.
Gate two: the tests run, and the agent did not write all of them
Agents write tests happily. They also write tests that assert whatever the code does, which proves nothing. The rule: the tests for a change's critical behaviour are written or at least specified by a person, before or alongside the agent's work. The agent can add more. The build fails if any test fails, and there is no override.
Gate three: security and secrets scanning on every change
Studies of generated code keep finding the same classes of problem: injection, missing authorisation checks, secrets in the wrong place, dependencies added without thought. These are exactly what static analysis, dependency auditing, and secret scanning catch, so they run in CI on every pull request and block the merge. This gate exists because it is the one a tired reviewer skips.
Gate four: a senior engineer reads the diff
Not skims. Reads. The reviewer's job is different from reviewing a colleague's work: the questions are "does this belong here", "did it change anything it was not asked to", and "would I be able to maintain this". Agents drift: they refactor things they were not asked to, add abstractions nobody wanted, and duplicate code that already exists. The reviewer catches the drift. This is why the person steering needs to be senior; the tool amplifies judgement, and it amplifies its absence too.
Gate five: the architecture the agent works in
The most reliable way to get good output from an agent is a codebase with clear conventions, a documented structure, and tests that describe behaviour. Agents follow the patterns they find. In a well-structured codebase they extend it; in a messy one they add to the mess, faster. Part of every engagement using AI tools is writing the conventions down where the agent reads them, and part of every cleanup of an AI-generated codebase is building that structure after the fact.
What we measure
Speed, yes, but also defect rate, review time per change, and how often a change is reverted. If speed goes up and the others go the wrong way, the gates are not working and the gain is borrowed. We report all four to clients rather than the one that looks good.
The tools will keep changing. The gates will not. A codebase with the five in place can adopt the next generation of agents in a week; one without them gets faster at accumulating problems.