Coding agents make software engineering harder, not easier

On 24 September 2026, Simon Willison posted a two-sentence note. His view: the more time he spends with coding agents, the more convinced he is that they make software engineering *even harder*. We can do amazing things with them, but unlocking their full potential requires extraordinary discipline and knowledge.

It is a short post, but it runs against the usual pitch that agents lower the bar for building software. We think it describes something builders keep running into, so here is our reading of it. The claim that follows from the note is Willison's. The interpretation is ours.

Why easier typing can mean harder engineering

An agent removes one bottleneck, which is producing code. It does not remove the others: understanding the problem, choosing an architecture, spotting a subtly wrong assumption, and deciding whether a change is safe to ship. When output gets cheap, those judgement calls become the main work, and there are more of them per day.

That is one plausible reading of "discipline and knowledge". Discipline is the habit of not accepting a plausible-looking diff because it arrived quickly. Knowledge is being able to tell when the diff is wrong. An agent can produce work faster than you can review it, and the gap between the two is where problems get in.

What discipline looks like in practice

The note does not list practices, so these are ours. They are the habits we would expect to matter most when an agent is doing the typing:

• Write the acceptance check first. Give the agent a test or a concrete definition of done, so "it looks right" is not the bar.
• Keep changes small enough to review. A diff you cannot read in one sitting is a diff you are trusting rather than checking.
• Run everything the agent touches. Tests, type checks and linters should be the gate, not the agent's own claim that it worked.
• Own the design. Decide the boundaries, data flow and failure modes yourself, then let the agent fill in the implementation.
• Know the domain. In payments, credit decisioning or order execution, the hard bugs are business-logic bugs that compile cleanly.

Why this matters more in fintech and trading

In most apps, a subtle bug means a bad afternoon. In trading automation or payments code, a subtle bug can mean a wrong order, a mis-scored applicant or a broken reconciliation. Speed in writing code does not reduce the cost of those mistakes. If anything it raises the odds of shipping one, unless the checking scales up with it.

That is why we would treat agent-written code the way we treat any untrusted contribution: reviewed, tested against the domain rules, and never merged on the strength of the agent's own summary. The same goes for LLMs inside a trading loop. The safety layer around the model deserves as much engineering as the model call itself.

The takeaway for builders

Vibecoding is real and useful, but the note is a fair warning against reading "AI-assisted" as "less engineering required". The people who get the most from agents are likely to be those who already know how to specify, test and review software, because the agent multiplies whatever practice is already there.