A Short Note That Moves the Question Beyond Generation Speed
In a blog note published on September 24, 2026, Simon Willison writes about coding agents, systems that can participate in software-development tasks rather than merely autocomplete a small fragment of code. His conclusion is blunt: the more time he spends working with these tools, the more convinced he becomes that they make software engineering harder. At the same time, he acknowledges that coding agents can do amazing things, while arguing that unlocking their full potential requires extraordinary discipline and knowledge.
Those two observations create a more important tension than the familiar question of whether a model can write code. An agent can increase output without removing the work of understanding requirements, identifying risks, validating results, or accepting responsibility. As the system enters a longer chain of work, the engineer is no longer reviewing only a piece of code. The engineer is reviewing a process that includes interpretation, actions, assumptions, and outcomes. Speed is therefore not a one-way benefit. It can move the bottleneck into review and control.
The Agent Changes What Engineers Have to Watch
Traditional autocomplete tools generally leave the decisive judgment with the engineer. The engineer expresses a relatively local intent, the tool proposes an implementation, and a person decides whether to accept it. Coding agents change the situation by allowing a system to pursue a larger goal across multiple steps. Although the source material does not describe a specific agent architecture, this mode of work is enough to expand the review surface. A person must examine not only the final edit, but also how the agent interpreted the task, selected its path, and handled uncertainty.
That widens the gap between something that appears complete and something that is actually correct. An agent may produce more files, more changes, or a more comprehensive-looking result, but the size of the output says nothing about whether it respects the system’s constraints. Engineers still need to know which requirements are hard boundaries, which tests can expose the important failures, and which side effects are unacceptable. The closer an agent gets to closing the loop on its own, the less sufficient a final code reading becomes as a quality guarantee.
The discipline Willison describes is not primarily a matter of personal temperament. It is a working method that keeps automation inside inspectable limits. Tasks need to be divided into boundaries that can be checked independently, the code and environments that may be modified need to be explicit, and important decisions during execution need to leave enough evidence. Knowledge cannot be delegated in the same way. Only people who und
Why Faster Generation Can Produce More Expensive Review
When an agent performs a narrow and repeatable action, the review cost may remain manageable. The problem begins when a team mistakes an agent’s ability to complete a task for the ability to make the team’s judgment. The first is execution capability. The second would be a transfer of responsibility, and the source note makes clear that the two are not equivalent. The more work an agent performs, the more time engineers need to establish what it did, what it missed, and whether its decisions were based on the right context.
This is where a speed advantage can reverse. More code appearing in less time does not mean less engineering work. Review, testing, regression diagnosis, and recovery to a known-good state become more important as the scope of change and uncertainty grow. The material frames the trade-off in practical terms: faster code generation may be exchanged for slower and more expensive review, testing, and rollback. The cost is not limited to compute or API usage. It also includes the cost of responsibility when a bad decision enters a real system.
The same distinction applies to lower model or agent prices. The surrounding material mentions Claude Opus 5.5, GPT-6 Sol, GPT-6 Luna, and a new price war, but the note does not provide a performance comparison among them, nor does it show that price competition reduces engineering risk. For an engineering leader, cheaper calls only lower the threshold for adoption. They do not answer who verifies the result, who approves the change, or who is accountable when something goes wrong.
When Introducing Agents, Design the Boundaries Before Maximizing Autonomy
When a coding agent enters a team, the first task should not be comparing which system generates faster, nor should it be granting the maximum possible permissions immediately. A safer starting point is to define the class of work the agent may handle, the directories, environments, and tools it may access, and the results that require human confirmation. This does not reduce the agent to autocomplete. It recognizes that the agent has become an executor that needs governance.
In this setting, visibility into the process matters more than an impressive final result. A team must be able to trace what the agent changed, how it understood the task, which tests it ran, and whether it had an opportunity to stop when uncertain. The material offers no ready-made audit metrics, error rates, or incident statistics for coding agents, so these recommendations cannot be presented as standards already established by data. The absence of such metrics, however, is not a reason to skip traceability.
Project rules also need to connect with testing, approval, and rollback rather than living only inside a prompt. For high-risk changes, human approval should be part of the workflow. Where tests cannot provide coverage, the team needs an explicit permission boundary for the agent. When the result is not as expected, the system must be able to return to a known state. Each additional layer of autonomy should be matched by additional visibility, verification, and a reliable way to stop execution.
The Engineering Decision: Ask What the Team Can Carry Before Asking What It Can Accelerate
The note does not prove that coding agents necessarily cause more incidents, nor does it specify how an agent error rate should be calculated. Its value lies in a deployment question that comes first: does the team possess the discipline and knowledge required to absorb the agent’s capabilities? If engineers cannot explain why a change was made, cannot tell what the tests covered, and do not know who approves a release, a more capable agent may simply expand the amount of invisible work.
This has a direct effect on the division of engineering work. The value of engineers does not move in some vague sense from coding to “supervising machines.” It becomes concrete in task decomposition, system constraints, risk identification, result acceptance, and final accountability. An agent can take on more execution steps, but it cannot own the business judgment of the team or become the responsible party when an incident occurs. Higher productivity exists only when the new supervisory work is included in the process and in capacity planning.
The actionable conclusion for an engineering leader is therefore not to reject coding agents, but to make the conditions for adoption explicit. A project should be able to answer what the agent may do and may not do, how changes are recorded, how tests provide evidence, who can approve a release, and how a failed result is rolled back. If those questions have no answers, greater autonomy should not be treated as an efficiency strategy. The most honest assessment is that the agent may be exchanging coding time for more expensive debugging time.