2026-09-12

AI Code Needs a Higher Bar

Code written by an agent should face a higher bar before it reaches production. Not because a person is automatically better, but because automation can repeat one bad assumption across a codebase before a human team finishes discussing the first pull request.

Speed changes the risk

People write bad code. Agents write bad code. Treating authorship as a quality verdict misses the point. The difference that matters is operating scale. An agent can touch more files, attempt more fixes, and reproduce the same mistaken pattern without getting tired or wondering whether the fifth copy looks suspicious.
That changes the cost of a weak control. A vague rule that fails once a month in a human process can fail every afternoon when agents are running continuously. A reviewer who used to catch drift by noticing an odd pull request now faces a queue of plausible changes, each arriving with a clean explanation and enough passing checks to look finished.
The higher bar is not punishment for machine authorship. It is the price of machine throughput. When production capacity rises, verification capacity has to rise with it. Otherwise you have built a faster path from one wrong assumption to every place it can spread.

More review is not the answer

The obvious response is to put more people behind the agents. That works until the output grows. Then review becomes the bottleneck, engineers skim because the queue never clears, and the organization congratulates itself for keeping a human in the loop while that human is doing little more than approving traffic.
A higher bar has to be executable. Formatting, types, tests, dependency policy, security checks, scope limits, and change-size budgets should run before a person sees the work. End-to-end checks should exercise the behavior in an environment the builder did not arrange for its own success. Fuzzing and adversarial inputs should search the edges no ticket bothered to name.
None of those controls is glamorous. That is precisely why they matter. The model demo gets attention because it shows production. The factory earns trust by showing refusal: the change that could not advance, the permission that could not be borrowed, and the claim that failed when another system tried to reproduce it.

Match the proof to the consequence

Not every generated line deserves the same ceremony. A copy change on an internal page and a migration that can alter customer data do not carry the same consequence. A useful factory routes them differently instead of making low-risk work wait behind heavy gates or letting dangerous work borrow the easy lane.
Start with blast radius. Ask what the change can read, write, spend, publish, or delete. Then ask how reversible it is and how quickly failure would become visible. Those answers should determine the environment, credentials, evidence, approvals, rollout, and rollback required before the work moves forward.
This is where human judgment belongs. People decide which consequences are unacceptable and where uncertainty requires escalation. Once that decision repeats, it should become machinery. A rule trapped in a senior engineer's memory cannot govern agents that run when that engineer is asleep.

Make every failure improve the line

A rejected agent change is useful only if the next run inherits the reason. If a reviewer catches the same missing authorization check three times, the factory did not learn three lessons. It rented the same person's attention three times.
Turn recurring findings into durable controls. Add the test. Tighten the policy. Improve the task contract. Give verification the missing context. Record the failed route so another agent does not rediscover it from scratch. The goal is not a longer instruction file that workers follow most of the time. The goal is a boundary that holds every time the consequence demands it.
The bar should get harder as the system gets more capable. Better agents will clear old checks more easily, find paths nobody anticipated, and produce explanations that sound increasingly complete. Verification cannot remain frozen while the builder improves. The proof system has to evolve on purpose, using failures as inputs to the next version of the line.

The factory owns the quality

Blaming the model for messy production code is an operating failure disguised as a technical opinion. The model did not choose its authority, define done, approve its own evidence, or decide that a green check was enough. The organization built that route and called it automation.
Our position is simple: agent-written code should clear a higher bar because the factory can demand one. Machines can run the checks on every change, preserve the evidence, compare the result with the repository's standards, and stop work without getting bored or pressured by a deadline. Repeatable quality control is exactly the kind of labor agents should absorb.
That will eliminate work built around manually carrying code through routine review and release steps. Human value moves upward: choosing the destination, setting the standards, and owning the consequences. The winning organization will not be the one that trusts agents most or fears them most. It will be the one whose factory can prove what deserves to ship.
In response to Quoting Boris Cherny by Simon Willison's Weblog.