From reviewing code to converting judgment: a developer's note on working with agents

What actually changes in the chain of production when coding agents become part of daily work? Well, the most useful skill may turn out to be the one nobody trained for.

Here is a small, real moment from working with coding agents. You hand one a task, it comes back with a pull request, and buried in its own review of the work is a note like this: “The second SELECT in this procedure isn’t protected against the first — what if someone drops the table in between?” The window in question is sub-millisecond. No one is dropping that table. And yet the agent flags it with the same gravity it would give a genuine data-loss bug. Multiply that across a large PR and you get the experience many of us now recognise: diffs that sprawl, reviews that pick at pre-existing code nobody asked about, and a quiet sense that you are losing the handle on your own codebase.

The popular explanation is that our job is becoming managerial — you are now the manager of several agents, perhaps even an agent that manages other agents. We think that framing is seductive and mostly wrong. Managing people works because people are slow enough that your throughput roughly matches theirs, and because they carry your intent. Agents are faster than you can supervise and they do not hold your intent; they hold a plausible reconstruction of it. “Manager of agents” collapses into “reviewer of a firehose,” which is where the over-engineering bites hardest.

The deeper issue is that the over-engineering is not a bug you can prompt away. It is structural. A human engineer who has shipped code carries an unspoken risk budget: a finite pool of attention, review capacity, and tolerance for regression that they spend deliberately. This path is hot, so it gets the careful treatment; this script runs once a quarter, so good enough is good enough. An agent has no such budget. Every possible improvement looks free to it, so it proposes all of them. The drop-the-table note is simply an agent spending from a budget it does not know exists.

Look, I’ll be honest: some afternoons I just approve the bloated version because arguing with the thing costs more than I’ve got left in the tank. Not proud of it. But any engineer who says they’ve never done that is lying.

So the instinct is right: the agent needs a notion of the cost of effort. But teaching it the cost directly tends to fail, because the cost is not a fact about the code. It is a fact about your situation this week: how much review capacity you have, how close you are to release, how much you trust this corner of the system. Encode that and it is stale the moment the situation shifts. Hard structural limits — a diff cap, say — fail differently: they punish the agent for the occasional genuinely better refactor that happens to be large. Neither extreme holds.

What works better sits in between, and it is cheaper than it sounds: let the agent surface the cost as a choice, up front, in the plan rather than in the code. Ask it, before it writes anything, to lay out three plans — a minimal intervention, a reasonable one, and a thorough rewrite of the whole chain — and you pick. Three plans are cheap; three implementations are not. You spend your judgment at the one moment it is cheap to exercise — before the work — instead of re-spending it line by line in review afterwards. This is close to what Anthropic’s own guidance for Claude Code recommends with plan mode: explore and agree scope before any file is touched, and let runnable verification hold the line at the back.

But the sharpest reframe we found goes further, and it is the one worth taking to heart. The reason review feels like a losing battle is that you pay the same judgment cost on every PR and nothing accrues — it is pure labour, nothing compounds. The alternative is a discipline a recent model of agentic engineering calls governance conversion: the act of taking a judgment you would otherwise re-make by hand every time and freezing it into durable structure — a lint rule, a spec clause, a scoping default, a test invariant — so the system makes the call automatically from then on. You spend the judgment once and bank it permanently.

There is a twist that makes this almost appealing. The agent’s speed, the very thing that overwhelms you, is also a sensor. Because it generates so much code so fast, it surfaces the same failure classes over and over — far faster than a human team would. The sprawling PRs and the drop-the-table notes are not just noise; they are signal, showing you at high frequency exactly which judgments you keep having to make. Each recurring one is a candidate for conversion. The question stops being “how do I review faster” and becomes “which of the judgments I made this week should never have to be made by a human again.” That accumulated structure is engineering capital: you build it once and it keeps paying. The honest catch is that specifications and controls can drift from the evolving code, so the capital needs maintenance — but that is a far better problem than the firehose you started with.