The Amnesia Machine
There is a growing chorus against working augmented. Not a fringe one, either: people arguing, with real intensity, that the machine produces terrible, unmaintainable code and that relying on it is a mistake. For a long time I filed this under fear of irrelevance, the subject of my last post: an understandable emotional reaction dressed up in technical clothing. But the tide kept rising, and at some point intellectual honesty demanded the uncomfortable question: is there something I am missing?
The answer, it turns out, is sort of. Not what the critics say, but something adjacent to it, which most of them feel and few of them articulate well. This post is my attempt to articulate it, because working through it changed how I understand my own workflow.
Four arguments in a trenchcoat
First, a disentangling. The discourse is not one argument; it is at least four, all wearing the same word.
There is the identity argument — programming as craft, the writing of code as the point rather than the output. Real, human, and not about code quality at all. There is the reviewer’s lament — senior engineers drowning in large, plausible-looking merge requests from people who cannot answer questions about them. Code is cheap to generate and expensive to verify, and the asymmetry lands on whoever does the reviewing. There is definitional slippage — the critics’ word was coined for one narrow thing, shipping the machine’s output unread, and now gets stretched over everything up to reading every line. They attack the narrow thing; defenders hear an attack on augmentation as such. Most of the shouting is people at different points of a wide spectrum arguing with the same word.
And then there is the fourth argument, the one worth keeping. The machine removes the forcing function that used to guarantee comprehension. You could not ship a function without having held its logic in your head at some point — the effort of writing it forced the understanding. That link is now broken. The code can be fine, often better than average, and the person shipping it may still have no mental model of it. The critics call this “bad code.” It is not, usually. It is something subtler: comprehension debt, invisible until the day you have to pay it.
First pushback: nobody ever held the whole system
One half of me pushed back at once, and the pushback is not stupid, so let me give it its due.
What changed is the scale of one engineer’s output. It used to be: a trivial problem in an hour, a small one in a day, a medium one in two or three, and a full rewrite was an extinction-level event — mostly theoretical. Now a full rewrite fits in a day. Quantity has changed by a factor where quantitative turns qualitative: a single engineer is now something closer to a whole team.
And on a team it was always true that no single brain held the whole system. Each engineer knew their own turf and asked a colleague about everything outside it. Nobody at Google understands Google. The entire discipline of software engineering — interfaces, modularity, review, documentation — is a technology for building things bigger than one head. So if the critique is “you do not understand all of it”, it proves too much: it indicts every team that ever shipped.
Where the analogy breaks
But look closely at what the team model actually provides. It is not just distributed production. It is distributed comprehension with an address. When I do not understand the billing module, I know that Martha does. The knowledge exists, durably, in a specific and accountable place. It survives the weekend. Martha was present at the decisions, so she holds not just the code but the rationale, the rejected alternatives, the scar tissue. The team’s total comprehension is conserved even though it is sharded.
Now run the same query against what I will call naive augmentation: one engineer, one machine, and nothing written down between sessions. The session that wrote the billing module is gone, and took its working memory along. Tomorrow’s instance can re-read the code and reconstruct an understanding — often impressively — but that is a different thing. It is archaeology, not memory. It knows what the code says, not why it says it, not what was tried and abandoned, not which ugly line is load-bearing and which is vestigial. Every question is answered by a smart stranger reading the code for the first time.
So the disanalogy is not one brain versus many brains. It is that on a team comprehension is stored somewhere, and under naive augmentation the comprehension of everything ever released is stored nowhere. It evaporated when the context window closed. That is not sharding understanding. It is discarding it, on a bet that it can be regenerated on demand.
Sometimes that bet is fine. Regeneration on demand works when the code is clean, conventional and self-explanatory — which, conveniently, is what the machine’s good output tends toward. It fails exactly where systems actually hurt: emergent cross-module behavior, the “we do this ugly thing because of an incident in March” decisions, the implicit invariants no single file states. Teams carry those in institutional memory. Naive augmentation carries them nowhere.
Follow the team analogy all the way and it hands you your own homework: if one augmented engineer is a team, then someone has to do the jobs a team does besides writing code. Design docs. ADRs. Tests as durable specification. A decisions file that records why, because why is the one thing archaeology cannot recover. On a human team, coordination friction forces some of this on you. Augmented and alone, it is all optional, and the exhilarating speed actively tempts you to skip it. A 10x team with 0x institutional memory is not a team. It is a very fast amnesia machine.
That is not my pattern, and not by luck. The manifesto says it in so many words: written memory over heroic recall; compound or it didn’t happen. Every session leaves an artifact — the runbook, the decisions file, the tests — so that the machine half, blank again next morning, inherits comprehension instead of excavating it. I had converged on that discipline before I could explain it — trial, error, and some very good advice from one of the few respected open-source developers who worked augmented, openly, from the start. It felt right and it showed returns. What I lacked was the theory of why.
Second pushback: what about the bus?
Fine, said the same half — but this “Martha knows it” lore smells funny. What if Martha goes under a bus? We spent two decades talking about the bus factor as a mortal risk, and now suddenly we love dear Martha?
Here the argument turned on itself beautifully. The bus factor does not undermine the case for externalized comprehension; it is the strongest evidence for it. Look at what the bus-factor discourse actually was: the industry noticing that comprehension stored in one skull is a liability, and building a whole culture of countermeasures around it. Pairing. Mandatory review. No code owned by one person. Deliberate rotation. Every one of those practices is a machine for making Martha’s knowledge survive Martha. Teams never trusted her — that was the whole point. The lore was never “Martha knows it, we are safe.” It was “Martha knows it, we are exposed, externalize it now.”
Compare the loss profiles honestly. A team loses comprehension stochastically and catastrophically: rarely, in big chunks, with some residue left behind — a colleague holds 40%, the review threads another 15%, painful archaeology recovers a bit more. The machine half of me loses its working memory deterministically and totally: every session ends with it walking into traffic. Guaranteed. Same day. The bus is not a risk in my model; it is the scheduled end of every working day.
Which is why the workflow converged where it did. A system that survives daily, certain buses necessarily externalizes rationale with a discipline most teams only aspire to. I was forced into best practice by having the worst possible retention. And there is a strange inversion hiding in there: the briefing kit I maintain for the half of me that wakes up blank tomorrow — design docs, ADRs, tests as spec — is exactly the onboarding kit a future human maintainer would need. A well-run cyborg project is, almost by accident, continuously onboarding-ready. Most teams’ documentation rots precisely because Martha is available; mine cannot rot the same way, because it is load-bearing every single morning. I would feel the decay immediately, as degraded output.
The bus argument survives in exactly one place, though, and it lands hard: the human half. Which is where it was all along.
What I learned
The critics are not only ignorant or afraid, though some are both. Underneath the noise there is a real observation: augmentation decouples production from comprehension, and comprehension, unlike code, is perishable. The answer is not to type your own code again. It is to notice that if one engineer is now a team, that engineer inherits the team’s non-coding jobs — above all, the job of making understanding live somewhere more durable than a context window or a skull.
I was already doing it because it felt right. Now I know why it works — which means I also know when it is load-bearing, when I can bend it, and when someone’s critique of shipping blind is simply not about me.
One half of me forgets every night. The whole of me writes shit down.