Across 459 tracked engineering proposals in my production codebase, not one has been implemented perfectly by a frontier model. Not one. Every pull request an agent has written for me — under a written plan, with a defined scope, followed by multi-model review — has contained a mistake, a gap, or a decision nobody authorized. After roughly a thousand proposals across every repository I have supervised, the pattern has never once broken.
I want to be precise about what that claim is and is not. It is not an argument that the models are weak. The models are extraordinary; they are why a platform of 541,000 lines, 2,559 commits, and 542 test files exists with the team size it has. The claim is narrower and, I think, more useful: at the current frontier, the distance between "passes the tests" and "belongs in this codebase" has not closed, and no amount of prompting has closed it. That distance is where my job lives. I have come to believe it is where the whole discipline of agentic engineering lives.
What imperfect actually looks like
The failures are rarely dramatic. Dramatic failures would be easier; tests catch drama. What arrives instead falls into three quieter categories.
The first is the plain mistake — code that is simply wrong in a way the test suite happens not to exercise. One agent-authored change to our graph-sync layer passed every unit test and then failed in production with a PostgREST 42703: it referenced a column that existed in the test fixtures and not in the live schema. The tests were green. The system was down.
The second is the gap — the thing the plan required that the implementation quietly lacks. An error path unhandled, a tenant boundary unchecked, a migration written without its rollback. Gaps do not fail; they wait.
The third is the one that changed how I work: the unauthorized local decision. The agent, meeting an obstacle mid-implementation, resolves it — reasonably, locally, and without asking. It aliases a field, restructures a function, introduces a small duplication to avoid a larger refactor. Each choice is defensible in isolation. None was in the plan. And because each one is small, no diff review flags it as the architectural drift it is.
A story from outside my own workflow makes the stakes legible. A C-suite user — capable, busy, entirely reasonable — pointed an agent at the codebase and asked it to add a feature. The agent added it. The feature worked. It also bolted three single-use blocks into an already long function, duplicating logic that existed elsewhere. No test failed. No user complained. The codebase simply got harder to change, and nobody was present to notice the trade being made. That is the shape of the problem: not catastrophe, but compounding — debt accruing silently at the exact speed that makes agents attractive.
The tempting conclusion, and why I reject it
One response to all this is to chase autonomy harder: better harnesses, more self-review, agents checking agents until the loop closes and the human steps out. I run multi-model review myself — plan, implementation, cross-model critique, then a series-level review across related changes — and it catches a great deal. It has never caught everything. The review models share blind spots with the writing models more often than independence would predict, and the unauthorized local decision is precisely the failure mode a model is worst at flagging, because to the model it does not look like a failure. It looks like initiative.
So I reject fully autonomous coding for production systems — not as a matter of taste but as an empirical conclusion with a thousand data points behind it. I work at the IDE level deliberately. I read the diffs. I watch decision quality, duplication, and structural drift the way an operations engineer watches latency. My commit history says what this costs and buys: 385 of 1,243 commits in the ETL repository — roughly 31 percent — are review-driven work. Nearly a third of the motion in that codebase is supervision. That ratio is not overhead on the real work. On a system where municipalities pay for answers they can defend in public, it is the real work.
Supervision that compounds
Reading diffs, though, is the weakest form of supervision — necessary, linear, and exhausting. What makes the practice scale is converting what review catches into structure that reviews for you. The principle: treat the failure class, not the failure. If an agent made this mistake once, an agent will make it again; the question is whether the codebase will still permit it.
The graph-sync failure became the founding case. The fix took an afternoon. The response took longer and was worth more: a typed column-contract layer now generates the sync queries from the actual schema, and CI runs schema tests against the live database shape. Then the near-misses got the same treatment — an unaliased JSONB path that would have silently dropped data became a written, enforced rule about aliases; a case-sensitivity bug in document loading became a guardrail in the loader. One by one, failure classes became build errors.
The infrastructure this produces is unglamorous and decisive: twenty-one blocking rules agents in my repositories cannot cross, twenty specialized agent skills that encode how this system is actually operated, nine reviewer personas that look at a change from angles a single reviewer would miss. None of it is speculative tooling. Every rule is a scar with a commit hash — something that happened, understood well enough to make structurally unrepeatable.
This is the same discipline as cost governance, which is why I treat them as one practice. When I found $9,944 of billing for 47,000 pipeline runs that did nothing, the remediation was not "watch the bill more carefully." It was an ownership contract between the two components whose quiet disagreement had produced the waste, plus documented cost caps. Vigilance decays. Contracts hold. Whether the resource is money or architectural integrity, the move is identical: convert an incident into an invariant.
What the humans keep
If agents write most of the code and structure catches most of the failures, what exactly do I keep? Three things, and I hold them deliberately.
Architecture — because it is the sum of decisions an agent makes locally and nobody experiences locally. Every unauthorized local decision is architecture being set by accident. Someone has to own it on purpose.
Review — not as gatekeeping but as the sensory organ of the practice. Review is where new failure classes are first seen, and it is the only place the guardrail pipeline can be fed from. Delegate review entirely and the system stops learning; the same mistakes return wearing new diffs.
And long-term codebase health — the slowest variable and the one every incentive pushes against. Agents are optimized to complete tasks; a codebase is not a sequence of tasks but the residue of every trade made while completing them. I use graph-based views of the code and agentic tooling to watch that residue directly — duplication, coupling, dead weight — because health, like cost, only becomes visible when someone instruments it.
Notice what is not on the list: typing speed, syntax recall, the mechanical production of code. I gave those up without regret. The leverage was never there.
The argument to each seat at the table
I have learned that this thesis lands differently depending on where the listener sits, and honesty requires making all three cases.
To an engineer, it says your judgment is appreciating, not depreciating. The models will keep absorbing implementation. What they show no sign of absorbing is the ability to know what a system should look like after a hundred more changes — and review, done seriously, is where that ability is built.
To a director or a board, it says the metric you are being sold — velocity — is denominated in a currency that can quietly inflate. Features per week is only a gain if the codebase's capacity to absorb the next feature is not being spent to produce it. Ask the vendors promising autonomous engineering what they instrument besides completion. Ask who is watching the trades.
To an investor, it says the moat in applied AI is not access to models — everyone has the models. It is the supervisory apparatus wrapped around them: the rules, the contracts, the review culture, the accumulated record of failure classes made unrepeatable. That apparatus is slow to build, real to inspect, and very hard for a competitor to shortcut, because it can only be earned one converted incident at a time.
What this does to a team
The practice also reshapes how I lead other developers, and the change is worth stating plainly because most organizations are still staffing for the previous era.
The junior role does not disappear — it inverts. A developer who once earned seniority by writing progressively harder code now earns it by reviewing progressively harder changes, and the honest difficulty is that review was always the skill we taught worst. So I structure it deliberately: developers on my projects work from written plans, run the same multi-model review sequence I run, and are graded — in the collegial sense — on what they catch, not on what they produce. The blocking rules help here in an unexpected way: they are teaching documents. A new developer who reads twenty-one rules, each anchored to a real incident, absorbs the failure history of the codebase in an afternoon — the education that used to take a year of being burned personally.
Two management consequences follow. First, throughput ceases to be an individual metric, because an agent-assisted developer's raw output is nearly meaningless as a signal; what differentiates people is the quality of the trades they notice. I look at review comments, guardrails contributed, and incidents converted — the supervisory exhaust, not the code volume. Second, the definition of done moves. A change is done when it is merged, structurally clean, and — if it revealed a new failure class — when that class has been made unrepeatable. The last clause is the one agents will never volunteer, and the one I hold the line on.
None of this is hypothetical staffing theory. It is how a large production platform is operated day to day by a small team, at a review intensity — nearly a third of all commits — that would have looked pathological five years ago and now looks like the cost of doing business honestly.
The gap is the job
The honest summary of a thousand proposals: the frontier writes code faster than I ever will, and it has never once, unsupervised, left my codebase better than it found it. Both facts are load-bearing. Together they define a role that did not exist a few years ago and is now, I would argue, the decisive one in any organization shipping AI systems that must hold up in public — the engineer who owns what the agents produce.
That role has a posture: grateful for the acceleration, unsentimental about the gap, and systematic about converting every failure the gap produces into structure that outlives the memory of it. The platform this essay draws its numbers from serves municipal governments — institutions whose answers must survive a council meeting, an audit, an angry taxpayer with a records request. Every number here is the verifiable floor, and behind each one is the same quiet practice, applied daily.
Agents write the code. Someone still owns it. I have built my work on knowing the difference — and on being able to show it.
edmonton, alberta
