I know that's a bold claim for someone whose byline is "I solve hard software systems problems," but let's step back and look at the economics.

Bespoke code used to be expensive. A large project could take several human lifespans of collective effort to build. This week I ran David Wheeler's SLOCCount against the current Linux kernel, using the model he recommends for kernel work: 28.8 million lines of source, an estimated 38,218 person-years of effort—849 professional lifespans.

When you hold an object, whether physical or digital, that's irreplaceable, whose value is more than the entire output of your life, the reflex toward it is care, stewardship, maintenance.

When I started tasking AI with the generation of my code, I estimated I was ten times faster. Then I got better at understanding how to use the AI and specify my problem. And at the same time, the AIs improved, decreasing the amount of time I spend creating boilerplate specifications that state the obvious. Now I estimate that multiplier is closer to 50.

Even the hard stuff gets faster. Optimizing for Loongson, the model reaches for AVX2 habits that don't hold on LASX, and I have to explain where the two differ. That's fine. Ten minutes of me describing the algorithm and the lane rules in English, three minutes of the machine emitting the intrinsics, and a day's work is done. The explanation isn't wasted, either. It used to live in my head and in the code I typed. Now it lives in the spec, where the next build can find it. It's a larger change in how we interact with knowledge than even the printing press.

Then I hear the common refrain on the internet: "AI generates unmaintainable code. Your project could reach a point where the AI itself can't take care of it. You have to eventually revert to human authors."

Hogwash.

What we call code is no longer code. C++, Python, Rust: this is all the machine implementation. It is the binary.

If something worth preserving exists only in the code, then the code is the specification. The fact that you wrote it in C++ instead of English and mixed it up with what now amounts to binary just means you're working with legacy code. You have a specification to recover. That knowledge still matters. The language you happened to bury it in doesn't have to.

Nobody commits build artifacts. You commit the input to the compiler and let the build reproduce the output. That's been the rule for as long as I've been doing this—a .o file in the repo is a code smell, and a checked-in binary gets you a code review comment you don't want.

Now look at what's actually in your repo. There's no specification in it. Until recently the first compiler was a person: the spec ran in your head, you emitted C++, and GCC emitted the binary. Nobody committed the input to the first stage, because the input was somebody's understanding, and that's why you have a specification to recover. The first stage is a program now. We just haven't noticed that we're still committing its output—the intermediate representation—instead of what goes in.

Git is where the spec should go. The C++ sitting next to it is memoized build output—kept around because today, going from spec to spec-plus-delta is still faster with the last implementation on disk than regenerating from nothing. That's not maintenance. That's a build cache with commit messages.

And build caches don't have to live in your repo. ccache, sccache, Bazel's remote cache: we already share compiler output across machines and across teams, because most of what everyone builds is the same thing. The same will happen one level up. The memoized C++ moves out of your repo and into a shared cache at the model level, and the compute everyone is burning to re-derive the same implementation stops being spent.

It's been a long time since we've thought about maintaining binary files. Nobody looks at an executable with a hex editor and complains that GCC didn't emit maintainable machine code. It wasn't always that way. When a rebuild cost a night of machine time, people patched binaries. IBM shipped fixes as SuperZap patches applied straight to the load module, because recompiling was the expensive part. Binary patching didn't die because it was ugly. It died because rebuilding got cheap.

People say you can't trust models because they are non-deterministic, but GCC itself is chock-full of arbitrary thresholds—numbers somebody had to pick. As far as the specification is concerned, those might as well be random numbers chosen at compile time. We already accept that the compiler makes implementation choices for us.

We didn't trust early compilers either. When Fortran shipped in 1957, the assembly programmers said what the internet says about AI now: the machine's output is bloated, nobody can read it, nobody can maintain it, and when it breaks you'll have to go back to writing it by hand. Backus's team knew that going in. They spent years on the optimizer, because nobody was going to accept output slower than a human could write, and programmers still read the assembly listings to check its work.

Nobody reads the listings now. The trust didn't get argued into anyone. It accumulated, one build at a time, until inspecting compiler output became a specialist's hobby. I can't fix the problem that you don't trust the model. Neither could Backus. What I can tell you is that the objection has a date on it, and the date is 1957.

That's what the model is. Not a pair programmer, not an intern: a compiler. A specification goes in—plain English, or English thick with the vocabulary of whatever field the problem lives in—and an implementation comes out. That the implementation is C++ this year instead of machine code is a detail of the toolchain.

So yes, maintain your specification. Track the changes you make to your file formats, constraints, business rules—these can get really complicated, especially if your topic is technically sophisticated. But let go of your attachment to the code. In 2026, you still need your memoized code fragments to help the AI get from one specification to the next, but you no longer have to worry about maintainability, because those fragments are getting cheaper by the day to replace.