Ankur Sethi has an intentionally inefficient answer to AI-generated code: let the model propose the patch, but type every line into the project yourself.
It sounds almost comic in an era built around autonomous coding agents. It is also a sharp response to the real bottleneck AI creates. Code can now arrive faster than a human can build a mental model of it.
Sethi still uses coding assistants because they can fast-forward through boring work. What he dislikes is the disorientation that follows when an assistant one-shots an entire feature.
The feature may exist, but the understanding that normally grows alongside implementation does not. The developer inherits a diff rather than building a system.
Reviewing the generated PR is the obvious answer, but it is a weak learning surface. Hundreds of lines of defensive, verbose, subtly wrong code encourage scanning and approval rather than reconstruction. The human sees what changed without necessarily learning why each part belongs where it does.
That gap is cognitive debt: short-term delivery purchased by reducing the team's ability to reason about the system later.
Sethi puts a strict instruction in his project agent files:
> Never create, edit, move, rename, or delete project files unless explicitly asked. Show every proposed edit in chat so I can type it manually.
He applies the same restriction to commands that install dependencies or change repository state. The model remains useful—it can draft code, remove boilerplate work, and explain unfamiliar APIs—but it cannot silently turn suggestions into facts inside the codebase.
This changes the assistant from an autonomous implementer into a fast pair-programming partner whose output must pass through the developer's hands.
Manual transcription creates several forms of friction that normal code review often removes:
1. Every line consumes attention. Skimming is harder when each token must be placed deliberately.
2. Confusion becomes visible. An unfamiliar API or algorithm interrupts the flow and invites a lookup or question.
3. Adaptation happens immediately. Generated code can be simplified, reorganized, renamed, or commented while it enters the project.
4. Bad choices feel expensive. Overbuilt abstractions are more obvious when the human must personally reproduce them.
5. Location becomes memory. Typing changes into specific files builds a spatial map of where functionality lives.
The last point matters beyond comprehension. A better map of the codebase improves future prompts: the developer knows which files, boundaries, and constraints to mention to the model.
Sethi connects this workflow to how many programmers learned before LLMs. Beginners were often told not to paste examples blindly from books or forum answers. Typing and adapting an example made the learner confront its assumptions and confirm that it actually ran.
LLM output is a new source of plausible snippets, but the learning problem is the same. A result can work before the developer understands it. Retyping slows the transfer down enough for understanding to catch up.
This is not the fastest way to produce software, and Sethi does not pretend otherwise. He estimates that it makes him perhaps 2× faster than working without an LLM, while people who delegate more aggressively may claim much larger gains.
But the optimization target is different:
For a disposable prototype, mechanical migration, or heavily verified low-risk task, manually retyping everything may be excessive. For a personal project used partly to learn and think, it is coherent. The right amount of friction depends on whether understanding is part of the product.
The provocative claim is not that everyone should type every generated line. It is that the software industry is accumulating infrastructure which works today but is becoming harder for any human to reconstruct from first principles.
Agent rules, tests, small diffs, design notes, and review interfaces can all preserve comprehension. Retyping is simply the most literal version: generated code does not enter the world until a responsible human has actively rebuilt it.
The workflow looks slow only if code output is the metric. If the metric is software that its author can still explain, modify, and own a year later, the extra friction may be the productive part.