Coding agents speed up code and make judgment more expensive

In a short note dated September 24, Simon Willison writes that the more time he spends with coding agents, the more convinced he becomes that they make software engineering harder. He also says they enable remarkable work, but that unlocking their full potential demands extraordinary discipline and knowledge.

More generated code creates more decisions

This is an experienced developer's thesis, not a benchmark result. Its brevity is useful because it separates production speed from engineering quality. An agent can prepare a change in minutes whose review still requires an understanding of architecture, data flows, tests and operational consequences.

Output can therefore grow faster than a team's capacity to decide reliably what belongs in production. The bottleneck moves from typing syntax to making sound decisions around it.

Seniority moves into specification and control

For engineering teams, that is an uncomfortable shift. A good agentic workflow needs precise instructions, small steps, testable criteria and a human who can spot when an answer merely looks correct. A junior developer may produce a larger change faster, but without context can also expand the blast radius of a mistake.

An experienced engineer's value is consequently measured less by lines written. Problem decomposition, interface design, testing and the ability to stop a bad direction before it spreads through the codebase become more important.

A fast demo says little about maintenance cost

Willison's note does not prove that agents generally reduce quality or productivity. It provides no dataset or controlled comparison. It warns against the wrong metric: completed tasks may rise while review, debugging and long term maintenance become more expensive.

The key question is whether a team can tether agent output to tests and observable behavior. Without that, it gains generation speed rather than confidence in the result.

Post merge defects and review time will settle the argument

A useful evaluation must track more than pull request count. Teams should watch regressions after deployment, review time, returned changes and the time required to understand someone else's agent generated output.

If those costs rise more slowly than delivered value, coding agents genuinely amplify the team. If the review queue merely fills faster, the agent supplied an engine and left the brakes behind.

Lilith's verdict

A coding agent can fill the tracks faster than a team can switch the points. The winner will be the crew that spots the wrong route before impact, not the fastest generator.