When AI Agents Write 1,000 Lines a Day, Who's Reviewing for Security?
Simon Willison's case for measuring AI coding agents in lines of code exposes a harder problem: as generation speed multiplies, review capacity — and the architectural discipline that keeps security controls consistent — becomes the real bottleneck.
Key Takeaways
- Simon Willison argues AI coding agents can plausibly produce around 1,000 debugged lines a day, against roughly 50-60 lines of production-ready code from a solo human engineer on a typical day (200 on an excellent one).
- Faster, cheaper code generation erodes what Fred Brooks called "conceptual integrity" in The Mythical Man-Month — the property that a system covers exactly the right domain with no surprises — because ideas that used to be filtered out by effort now ship in an hour.
- For security teams, eroding architecture is eroding trust boundaries: inconsistent patterns are exactly where authorization checks, input validation, and secrets handling drift out of sync as a codebase grows.
- Human review and secure-code-review capacity, not agent throughput, is becoming the real constraint on how much AI-generated code an organization can safely ship.
The productivity argument nobody wants to make
In a recent episode of the *Talking Postgres* podcast, Simon Willison made a case he's been building for a while: lines of code, dismissed by most engineers as a meaningless productivity metric, actually says something useful once AI agents are doing the typing. He points to rough baselines — a human engineer producing 50-60 lines of production-ready code on a typical day, with 200 lines counting as an excellent one — against agents that can plausibly turn out 1,000 debugged lines in the same period, provided the operator has the skill to get there. source
That gap is the interesting part. A 15-20x jump in raw output doesn't mean 15-20x more shipped, reviewed, understood code — because the human on the other end of that pipeline hasn't gotten any faster at reading it.
Conceptual integrity: a term security teams should borrow
Willison frames the resulting bottleneck using a concept from Fred Brooks' *The Mythical Man-Month*: conceptual integrity — a codebase where "there are no surprises in it, it covers exactly the right domain of things, everything fits together and makes sense." Podcast host Claire Giordano offered the analogy that stuck: the Winchester Mystery House, where the owner spent "40 years... adding new rooms" with no unifying plan, producing staircases to nowhere and doors that open onto walls.
Agents make that failure mode cheap to reach. A feature idea that used to take a week to build — long enough that a bad one got rejected before it shipped — now takes an hour. The discipline that used to come from effort has to come from somewhere else.
Why this is a security problem, not just an engineering-quality one
Conceptual integrity isn't purely an aesthetic concern. A codebase that "covers exactly the right domain" is also one where a security engineer can build an accurate mental model of trust boundaries: where auth checks live, where input gets validated, where secrets are handled, and where those patterns should repeat. Once agent-driven feature sprawl breaks that consistency, the same erosion that produces a Winchester Mystery House of dead-end UI flows also produces inconsistent authorization logic, duplicated validation with subtly different rules, and expanding attack surface that nobody explicitly decided to build.
Threat modeling assumes a codebase whose boundaries hold still long enough to model. Agent-speed iteration is a direct challenge to that assumption.
What actually scales: review capacity, not agent output
Willison's own framing points to the fix: teams need to "load balance that cognitive capacity across the team," because a single engineer can't meaningfully review code produced 15-20x faster than they could write it themselves. For security-conscious engineering organizations, that translates into a few concrete practices.
- Track review throughput, not lines shipped, as the capacity metric that actually gates safe release velocity.
- Treat AI-authored code as untrusted input to the codebase until it clears the same review, SAST, and secure-coding gates as human-written code — no fast lane for agent output.
- Tie architecture and security review checkpoints to feature additions, not just to pull-request merges, so conceptual integrity — and control consistency — survives agent-speed iteration instead of eroding silently.
None of this requires slowing agents down. It requires accepting that the bottleneck moved, and building review and governance capacity to match where it moved to.
Frequently Asked Questions
Does more AI-generated code automatically mean more vulnerabilities?
Not automatically, but the risk is real: when generation speed far outpaces review capacity, code — including security-relevant logic — reaches production with less scrutiny than before, and architectural drift makes it harder to reason about where controls should consistently apply.
What is "conceptual integrity" and why should security teams care?
It's a term from Fred Brooks' The Mythical Man-Month for a codebase where everything fits together with no surprises and covers exactly the right domain. Security teams rely on that consistency to model trust boundaries accurately; when it erodes, authorization and validation logic tends to drift out of sync across the codebase.
How can engineering teams keep security review paced with agent-speed code generation?
By treating review and architectural oversight as the capacity constraint to plan around — distributing review load across the team, gating AI-authored code through the same checks as human code, and tying architecture review to feature additions rather than just PR merges.
Sources
- 1Conceptual integrity and counting lines of code — Simon Willison
- 2Talking Postgres with Claire Giordano: AI for data engineers with Simon Willison — Talking Postgres