Agent-Native Software Engineering: Why Specs Alone Aren't Enough
Coding agents fail less at writing code than at holding architectural context. A look at spec-driven development's limits and what comes next.
The real weakness of coding agents isn't code generation - it's misreading requirements. An agent can implement a function flawlessly, pass every existing test, and still violate a business rule no test encodes. Drawing on experience maintaining 100K+ line codebases, this piece argues that as agents speed up delivery, the human's mental model of the system quietly erodes, and architectural decay follows.
The root cause: the entire software engineering stack - git, pull requests, code review, CI - was built assuming a developer with long-term memory, tacit context, and accountability for outcomes. Agents have none of these properties; context vanishes at session end, wrong goals get pursued with total consistency, and no one is answerable for the output. Spec-driven development (intent → spec → plan → tasks → code) helps by giving agents a stable basis to work from, but a spec alone doesn't solve permissions, sandboxing, verification, or responsibility.
The proposed fix: stop treating specs as permanent system-level truth and instead scope them to a single change's lifetime, retiring them once merged. Mechanizable constraints - type contracts, module boundaries - belong in tests and CI; non-mechanizable ones, like why an architecture looks the way it does, need a separate decision record. The core loop should be intent ↔ implementation ↔ evidence, since a spec, code, and tests all produced by the same agent can share the same blind spot.