Rewrite All the Code, All the Time

The pitch making rounds in Silicon Valley right now goes something like this: code is dying. Not the act of programming, but the artifact itself — the files sitting in your repo — will become as disposable as assembly language is today, something a machine spits out and nobody reads. A new essay from a researcher writing under Structure and Guarantees pushes that idea further than most, and then pulls a switch nobody expects: he says the large language models currently doing all the AI-coding hype are not the tool that gets us there.

His argument starts historically. Back in 1962, programmers were furious that high-level languages and compilers were about to let "managers do their own programming." That fear was really about automating the tedious hand-writing of machine code, and it turned out fine — today's programmers just take compilers for granted. The author's point is that abstraction levels in software keep ratcheting upward, generation after generation, and there's no reason to think the current jump toward AI-driven code generation is any different in kind. What's different this time, he argues, is what we're feeding the generator.

And this is where he splits from the crowd. Most of the current spec-driven development tools — including popular formats like EARS, the Easy Approach to Requirements Syntax — still lean on natural-language sentences dressed up with keywords like WHILE, WHEN, and SHALL. The scaffolding looks formal, but the actual content is still English, still ambiguous, still exploitable by an AI that misreads intent either by accident or by design. He doesn't think that gap closes with bigger models or more training data. Natural language, he says, evolved to be a little slippery on purpose — useful for social signaling, terrible for the kind of precision you need to hand a system that will regenerate your entire production codebase with zero human review.

His alternative leans on formal logic and program synthesis instead of transformer-based generation: crisp, mathematically checkable specifications that describe what software must do, security requirements and performance budgets included, precise enough that any program satisfying them is acceptable by definition. He floats an odd but clarifying thought experiment — imagine a government hiring two rival contractors per project, one to write the spec, one to implement it, each assuming the other is out to exploit any looseness. That adversarial pressure, he says, is what forces specs to actually be airtight. If specs reach that level of rigor, regenerating a whole codebase to absorb a new security patch or a smarter algorithm becomes as routine as recompiling a program today, no auditing required.

He's not shy about the scale of the claim: entire company codebases rewritten on release schedules, the way SaaS products get pushed updates now. Getting there means retooling the stack for performance and getting far more engineers fluent in formal verification, which is presently a niche skill even among people who consider themselves cutting-edge. He's clearly aware that's a heavy lift. But his bet is that the economic pressure to keep up will simplify enough corners of the software world — one "pocket" of activity at a time — that airtight specifications stop being a research curiosity and start being table stakes.