Coding agents make software engineering harder, says Simon Willison
Simon Willison argues that coding agents raise the bar on discipline and knowledge rather than lowering it. Here is what that means for security teams.
Key Takeaways
- Simon Willison wrote on 24 September 2026 that the more he works with coding agents, the more convinced he is that they make software engineering even harder.
- His point is that agents enable remarkable results, but unlocking their full potential takes extraordinary discipline and knowledge.
- Our view: for security teams this suggests agents shift risk from writing code to specifying, constraining and reviewing it, so review and permission boundaries matter more.
- Treat agent output as untrusted input and limit what agents can do, in line with OWASP's excessive-agency guidance.
On 24 September 2026, Simon Willison published a short note with a claim that cuts against the prevailing pitch for AI coding tools. In his words: "The more time I spend working with coding agents, the more convinced I am that they make software engineering even harder." He adds that agents let us do amazing things, but that unlocking their full potential requires extraordinary discipline and knowledge.
What the note actually says
The note is brief and makes no security claim. It does not cite an incident, a vulnerability or a study. It is one experienced practitioner's observation: capability goes up, and so does the skill needed to use it well. Everything below this section is our own analysis of what that observation implies, not something the source states.
Why this matters to security teams
If agents make the work harder rather than easier, the difficulty has to land somewhere. In our experience the likely places are the ones security teams already care about:
- Specification. An agent does what it is told and what it infers. Vague intent produces plausible code that may not meet security requirements.
- Review. Generated code can arrive faster than a human can properly read it. Review capacity, not typing speed, becomes the bottleneck and the control.
- Verification. Tests, static analysis and build checks become the real safety net, so their quality matters more than before.
- Permissions. An agent that can run commands, edit files and reach the network has a much larger blast radius than an autocomplete tool.
Treat agents as untrusted actors with real access
The OWASP Top 10 for LLM Applications lists excessive agency as a risk category: giving an LLM-driven system more functionality, permissions or autonomy than the task needs. Coding agents are a direct instance. The practical response is the usual least-privilege discipline, applied to a new kind of actor.
- 1Run agents in sandboxes or disposable environments, without production credentials.
- 2Scope tokens and file access to the single task at hand.
- 3Require human review before agent-authored changes reach protected branches.
- 4Keep deterministic gates, such as tests, linters, dependency checks and secret scanning, in CI so they do not depend on the agent behaving.
- 5Treat content the agent reads, such as issues, web pages and dependencies, as untrusted input that could carry injected instructions.
The takeaway
Willison's note is a useful counterweight to the idea that agents remove the need for engineering judgement. For defenders, the implication is that agent adoption should come with stronger controls, not fewer. The discipline he describes is, in large part, what a secure development lifecycle already asks for.
Frequently Asked Questions
Did Simon Willison say coding agents are insecure?
No. His 24 September 2026 note says coding agents make software engineering harder and that getting their full potential requires extraordinary discipline and knowledge. The security implications discussed here are our own interpretation.
What is the main security risk of coding agents?
In our assessment, it is over-broad access combined with insufficient review. OWASP's LLM Top 10 describes this class of problem as excessive agency, and least privilege plus mandatory human review are the standard mitigations.
How should teams control agent-written code?
Run agents in sandboxes with scoped credentials, require human review of their changes, and keep automated tests and security scanning in CI as gates that do not rely on the agent.
Sources
- 1Note on 24th September 2026 — Simon Willison
- 2OWASP Top 10 for LLM Applications — OWASP GenAI Security Project