The Code Nobody Remembers Writing: Maintaining What the Model Built Six Months Later

The bill for cheap code does not arrive when you write it. It arrives about six months later, when a module needs to change and the person assigned to change it opens the file and realizes that nobody on the team remembers how it works. It passed review. It shipped. It ran quietly for two quarters. And now a new requirement means someone has to reach in, and the git blame points to a pull request that a model mostly wrote and a human mostly approved on a Tuesday, and neither of them retained a working model of the thing. That's the failure mode I now spend the most leadership attention on, and it's almost invisible until it's expensive.

For most of my career, understanding decayed slowly because it accumulated slowly. You wrote a subsystem over weeks, and the weeks of typing left a residue — you remembered the dead ends, the reason a function took an odd parameter, the bug that explained an ugly guard clause. That residue was never in the code; it was in your head, and it was the real asset. Generation removed the typing, which was good, and it also removed the residue, which we didn't notice was a loss. You can now acquire a large, working, well-commented subsystem in an afternoon without ever building the mental model that used to come free with the effort. The code arrives fully grown and completely unfamiliar.

Comprehension is the thing that decays, not the code

It helps to be precise about what rots. The code doesn't rot; it does exactly what it did on day one. What decays is the team's ability to change it safely — and that ability was always stored in people, not files. When a subsystem is written by hand, the author is a living index of its assumptions for a year or two afterward. When it's generated, there is no such index from the start. So the maintainability problem isn't new, but AI moved it earlier and made it quieter: you can now reach the "legacy code nobody understands" state on the day you ship, instead of drifting into it after the original authors leave. We had a payments-adjacent module that was six months old, green in every dashboard, and effectively legacy — not because it was old or bad, but because the understanding of it had never existed in the first place.

Legacy code used to mean code that outlived the people who understood it. Now it can mean code that never had anyone who understood it. AI didn't create the problem; it just deleted the delay.

What we do at write time to pay a debt we won't feel yet

The fix is unglamorous and it happens at the moment of lowest motivation — when the code already works and everyone wants to move on. First, review is where comprehension gets manufactured, not just checked. On my team the author of a model-heavy change has to explain it back as if the model weren't in the room: what it assumes, where it will break, what a future change would have to be careful of. If they can't, the change isn't ready, no matter how green the tests are — because we're not buying working code, we're buying a person who understands working code, and only one of those two is actually load-bearing next quarter. Second, we write down the why, because the why is the only part a model can't regenerate. The what is in the diff forever; the reason this module exists, the alternative we rejected, the constraint that explains the weird shape — that lives in a short note next to the code or it lives nowhere.

Third, and most boring, we keep modules small and legible enough that comprehension is re-acquirable on demand. When you accept that no one will remember this in six months, you optimize for the stranger who has to understand it cold — clear boundaries, obvious seams, no cleverness that only makes sense if you were there. Generated code trends toward local sophistication because the model has no incentive to keep the whole thing re-readable by a tired human in Q3. That incentive has to come from the team standard. We'd rather ship something slightly duller that a newcomer can rebuild a mental model of in twenty minutes than something elegant that requires an archaeology dig.

Why this is the leadership tax on cheap code

None of this shows up in the velocity numbers that make AI tooling look like a miracle, because the cost is deferred and diffuse. The team that generates aggressively and skips the comprehension work looks faster for exactly two quarters, and then slows down in a way that's hard to attribute — every change to the older code takes surprisingly long, and nobody connects it to the afternoon they saved in the spring. My job is to spend the deferred cost on purpose, up front, while it's cheap to pay. Treat every generated subsystem as something a stranger will have to change under deadline, because in six months, on my team, that stranger is us. The model made it trivial to produce code we don't understand. It did nothing to make code we don't understand safe to own — and owning it, quarter after quarter, is still the whole job.

If your team is starting to feel the six-month bill on code that shipped clean, I'd be glad to compare notes. Reach me at arun@arunjalota.com.