--- title: "A Developer Retypes Every Line of AI Code by Hand" description: "A developer retypes AI-generated code by hand to avoid what he calls cognitive debt — shipping software nobody on the team actually understands." dek: "A programmer asks an AI to write his code, then types every line out again by hand. He says the wasted effort is the only thing keeping him from losing track of his own software." published_at: "2026-08-05T04:59:46.698Z" updated_at: "2026-08-05T04:59:46.698Z" tags: - "AI" - "Labour" source_url: "https://ankursethi.com/blog/prevent-cognitive-debt-by-manually-retyping-llm-generated-code/" source_domain: "ankursethi.com" canonical: "https://hex37.com/a-developer-retypes-every-line-of-ai-code-by-hand" --- Ankur Sethi, a software developer who writes about his work on his own website, has adopted a habit that sounds like a joke at his own expense. He asks an AI assistant to write code for him. He reads what it produces on screen. And then he types the whole thing out again himself, character by character, into his editor — the same code, in his own keystrokes. He is not confused about how inefficient this is. He estimates it makes him roughly twice as fast as working without an assistant at all, rather than the tenfold speedups people claim when they let the machine write directly into their files. He accepts the trade because of what he thinks he is buying: an understanding of his own software that he does not believe he would otherwise have. That trade is worth taking seriously, because it rests on a claim most of the industry has quietly decided is false — that there is a real difference between code that works and code you understand, and that the difference has a price attached. ## Working code and understood code are not the same thing A [large language model](https://en.wikipedia.org/wiki/Large_language_model) — the kind of system that powers coding assistants — can produce a functioning feature in seconds. What it cannot produce is your comprehension of that feature. The output arrives complete. The mental model that would normally accompany writing it, the sense of why this function sits here and calls that one, simply is not generated along with the text. Sethi calls the resulting shortfall cognitive debt, borrowing from the older idea of [technical debt](https://en.wikipedia.org/wiki/Technical_debt): shortcuts taken in code today that must be paid for in maintenance tomorrow. Cognitive debt is the same bargain applied to the programmer rather than the program. The software ships. The understanding is deferred. And, like any debt, it comes due at the least convenient moment — usually when something breaks and nobody can say why the code was shaped that way in the first place. The industry's answer to this is [code review](https://en.wikipedia.org/wiki/Code_review), the long-standing practice of having a human read code before it becomes part of the product. In the arrangement most companies have landed on, the machine writes and the human reviews. On paper the understanding is preserved: someone did read it all. ## Reading hundreds of lines is not the same as reading them The problem is what generated code actually looks like in volume. It tends to be long, heavily defended against errors that will never occur, sparsely or misleadingly commented, and wrong in ways that are subtle rather than obvious. Reviewing a few hundred lines of it is not intellectually engaging work, and Sethi is blunt that he does not enjoy it. He would do it for an employer. He will not do it on a personal project, where the whole point is that the process is enjoyable. This is not merely a matter of taste, because reviewer attention is a consumable resource. Read enough tedious code and you stop reading and start skimming, and skimming is precisely the mode in which subtle errors survive. The reviewer's eye moves at the speed the reviewer chooses, and under fatigue that speed rises until comprehension quietly drops out. The review still happens. It just stops catching things. Retyping removes that option. You cannot skim code you are entering keystroke by keystroke; the workflow enforces a pace roughly equal to the speed at which a human can actually decode what is in front of them. The inefficiency is the mechanism. It is not a side effect to be minimised. ## What you notice when you are forced to go slowly At that pace, things surface. A function call to an interface that does not exist — the model inventing a plausible-sounding capability, which practitioners call a hallucination. A structure that does not match how the rest of the codebase is arranged. Three layers of error handling where one would do. Sethi describes stopping mid-line to look up an unfamiliar interface, or asking the assistant to explain an algorithm before continuing to type it. And because he is typing anyway, he edits as he goes: reorganising, renaming, stripping the defensive scaffolding, adapting the code to the conventions he already uses. The output arrives as a draft rather than a delivery. The accumulated result is what he considers the real prize. He calls it a spatial map — knowing where each piece of functionality lives, so that when something needs changing he knows immediately which file to open. That map then feeds back into the assistant. A developer who knows the shape of their own codebase writes sharper instructions, gets more usable code back, and spends less time repairing it. The slow path compounds into a faster one. Which is the point at which the usual framing starts to look wrong. The choice is not between accepting code you do not understand and grinding through exhaustive review of code you did not write. There is a third arrangement, in which the model is treated as a research tool whose output must pass through a human before it touches the project — an input layer rather than a replacement layer. Cognitive debt, on this account, is not an unavoidable cost of the technology. It is what happens when comprehension is allowed to be optional. ## The bill nobody has been handed yet Sethi's worry extends past his own projects. He expects [software development](https://en.wikipedia.org/wiki/Software_development) as a whole is accumulating this debt at scale, and that a point is coming when large parts of the world's digital infrastructure are no longer understood by anyone maintaining them. Each individual decision to skip comprehension is rational — it is faster, and the costs land later and on everyone. The costs, when they arrive, land on people who made no such decision. He is candid that his own approach is contraindicated for anyone whose career depends on shipping quickly, and that he cannot change the direction of an industry. What he claims is narrower: that he understands the software he releases. One question his method does not settle is whether it prevents the debt or merely holds it. He carries the map in his head. The next person to open the codebase does not, and nothing in the retyped code records why any of it is shaped the way it is. The [original post is here](https://ankursethi.com/blog/prevent-cognitive-debt-by-manually-retyping-llm-generated-code/).