Linus Torvalds recently said1 AI will be to code what compilers were to assembly — freeing us from writing it by hand.
Around the same time, I talked with Jesse Vincent (creator of one of the most popular agent skills out there — superpowers). Something he said stuck with me: Specs are going to be the new code.
I realize those two ideas snap together a little too neatly. Agents are compilers2 and specs will become code. Software engineering is moving up another level of abstraction and we’ve seen this play out before.
Specs as source ##
I saw this first-hand with my tiny USB-C cable checker — usbi.
It started as a shell command over macOS’s system_profiler, then became Go
when I wanted a proper binary, then Rust because I wanted to practice Rust, and
later a .kts version.
The code kept changing. The thing I cared about did not: parse the USB tree, identify the attached devices, report the speed, and make bad cables obvious.
Podsync, my voice track sync program, followed the same
pattern. It started in Python because the audio libraries were there. Then I
moved it to Rust because I didn’t want to ship a Python runtime
or care which Python version happened to be on a machine.
Again, the implementation changed. The behavior stayed boringly stable: take a master track and local tracks, find the offset, pad or trim each file, and drop aligned audio into the DAW.
Compilers freed us from writing assembly. Agents may free us from writing code because it becomes an artifact the spec produces.
The somewhat recent push around detailed exec plans could be an early signal of the looming shift at bigger scale.
Rebuilds instead of patches ##
Push that thought further. We might get comfortable rebuilding whole modules instead of patching and refactoring them.
We preserved the old shape of a system because throwing it away cost too much. Even when you know the module is wrong, you sand it down: extract an interface, migrate one caller at a time, add tests around behavior nobody fully understands. You keep moving because the alternative is a rewrite, and rewrites have a well-earned reputation for eating companies alive.
But agents change that cost curve. If an agent can read the spec, understand the tests, inspect production traces, and rebuild a module in an afternoon, the sensible move may be to replace the entire module altogether.
Push that even further and the unit of work changes. You stop asking an agent to patch one function or file. You ask it to rebuild the entire payment module against the tweaked spec. Heck, swap out the auth layer with a new library. Or regenerate the API boundary, now that the domain model is clearer.
This is the part I cannot stop thinking about.
- Each rebuild can start from what we now understand about the whole module, not from what we believed the first time someone shipped it.
- Tech debt the old code carried (because it grew one patch at a time) can finally come off.
The spec can absorb what we learned from the old implementation: the weird edge case in billing, the migration path nobody wrote down, the customer whose workflow depends on a “bug”, the batch job that only fails on the first day of the month.
Specs become the place where the system’s memory lives. Once those lessons move into the spec, the implementation becomes replaceable.
We are becoming Spec Writers.
starts at the 1:48 mark ↩︎
Yes, agents aren’t deterministic the way compilers are — same prompt tomorrow may give different code. But that may be the wrong bar moving forward. What has to stay stable is behavior under the spec; the code can vary. Also my dude, are you seriously nitpicking with Linus Torvalds? ↩︎