The short version
Think about the difference between using a GPS to get somewhere and actually learning the route yourself. With the GPS, you arrive just fine — but try to drive there again without it, and you're lost. You never built a mental map of the streets; you just followed turn-by-turn instructions.
That's what happens when programmers copy and paste code straight from an AI assistant (a "Large Language Model," or LLM — a program trained to generate humanlike text and code from a prompt) into their project. The code works, the task gets done, but the programmer never really absorbed how or why it works. Over time this creates what people are calling "cognitive debt": a growing gap between the code you're officially responsible for and the code you could actually explain, fix, or rebuild from memory. Like financial debt, it's invisible at first and painful later, usually when something breaks and nobody remembers how the pieces fit together.
A simple counter-practice is gaining a following: instead of pasting AI-generated code directly into your project, you ask the AI for it in a separate window, read it carefully, and then type it out yourself, by hand, into your actual codebase. This is deliberately slower than copy-paste. But that slowness is the point — it forces you to read at the speed you can type, and that speed is roughly the speed at which humans actually understand things.
The people who do this aren't claiming it makes them superhuman. They're not chasing the "10x" productivity gains that AI coding tools are often marketed with. Their honest estimate is closer to 2x faster than coding entirely from scratch — a real but modest boost. What you get in exchange for giving up some raw speed is something copy-paste can't offer: a working mental map of your own codebase, a habit of catching the AI's subtle mistakes before they ship, and the assurance that the person responsible for the code is also the person who actually understands it.
How it works
The excitement around LLM coding assistants is built on a promise of radical efficiency. But a growing body of evidence suggests this speed comes at a steep price. To understand the retyping protocol, we first need to look at the problem it's designed to solve: a measurable decline in code quality and an erosion of developer understanding.
The Problem: Cognitive Debt and Doubling Code Churn
"Cognitive debt" is the implicit cost of implementing a solution you don't fully understand. Every time a developer accepts a block of AI-generated code without internalizing its logic, the debt grows. The codebase becomes a labyrinth of black boxes, making future debugging, maintenance, and extension exponentially harder.
This isn't just a theoretical concern. A 2024 analysis by GitClear, examining 153 million lines of code, delivered a stark warning. It projected that "code churn"—the percentage of lines that are reverted or significantly updated within two weeks of being written—was on track to double compared to its pre-AI 2021 baseline [5]. Churn is a direct indicator of low-quality, misunderstood, or incorrect code. The very tools meant to accelerate development appear to be fueling a cycle of rework.
The term "cognitive debt" itself was propelled into the mainstream by a June 2025 paper from the MIT Media Lab, Your Brain on ChatGPT. While the study's conclusions warrant caution, its findings are provocative. Researchers tracked 54 participants and found that those who became dependent on the LLM showed reduced alpha and beta brainwave connectivity. These users also reported the lowest sense of ownership over their work and struggled to accurately recall what they had written [5]. It's crucial to note that the study's strongest claims are based on a final session with only 18 participants, making it risky to draw sweeping conclusions. Yet it adds a neurological dimension to an effect many developers are feeling intuitively.
The Retyping Protocol: A Step-by-Step Guide
In response to this growing debt, developers like Ankur Sethi have championed a workflow that is both simple and radical. It's a deliberate re-insertion of the human into the loop, not as a passive observer, but as an active participant.
Generate in Isolation: The process begins by treating the LLM as a consultant, not a collaborator. Instead of using in-editor tools that suggest and complete code automatically, you open the LLM in a separate chat window. You ask for a function, an algorithm, or a boilerplate setup.
Review and Comprehend: The LLM generates a block of code. The next step is the most critical: do not copy it. Read it. Read it again. Does it make sense? Does it use APIs you recognize? Does the logic follow a sound pattern? Is it elegant or convoluted? This is the moment of critical engagement.
Transcribe, Don't Copy: Once you are confident you understand the code, you manually type it into your editor, character by character. The physical act of typing, of placing the curly braces and naming the variables, is central to the method. It leverages muscle memory to reinforce a mental model.
Learn as You Go: This slower pace creates opportunities for deeper learning. As one former computer science teacher noted in a discussion, this is where the real value emerges. If you encounter an unfamiliar API or algorithm during your transcription, you should "stop to look it up, or just ask the LLM to explain it" [1]. The retyping process transforms from a mundane task into a structured, self-directed learning session, exercising a "different brain muscle" focused on critical engagement.
The Rationale: From Muscle Memory to Mental Maps
Why does this seemingly inefficient process work? The answer lies in cognitive science. It's not that the act of typing has magical properties; it's that it "forces you to slow down to reading speed, which forces comprehension" [5]. You cannot physically type as fast as you can copy-paste, and this bottleneck is a feature, not a bug.
This method builds what developers call a "spatial mental map of the codebase" [3]. When you type code into a specific file and location, you are creating a stronger memory of its context and its relationship to the surrounding code. This is a stark contrast to pasting a block of code that exists in your mind as an abstract, location-less entity.
The entire practice echoes a classic piece of programming advice: when learning a new language, never copy-paste examples from a textbook [3]. Type them out yourself. The retyping protocol is simply the modern application of this time-tested pedagogical technique to the age of AI. It frames the LLM not as a magical code-writer, but as a dynamic, interactive textbook.
The Trade-off: A 2x Gain, Not a 10x Fantasy
The most important aspect of this method is its honest appraisal of productivity. The hype around AI coding assistants often centers on a "10x" improvement. The retyping protocol abandons this fantasy for a more sustainable reality. The developer who popularized this workflow estimates it makes him "roughly 2x faster than no LLM, not 10x" [3].
This is a conscious trade-off: you sacrifice the raw, brittle speed of copy-pasting for the durable velocity that comes from deep understanding, choosing to move at the speed of comprehension. The "slow photocopier" criticism [5] misses the point entirely. You aren't just duplicating the code; you are assimilating it. The goal is to produce code that sticks, both in the codebase and in your mind, avoiding the churn that doubles back to erase the gains of reckless speed.
What this means in practice
This isn't just a personal quirk — it changes how developers, teams, and companies actually operate day to day.
For an individual programmer, retyping is a way to stay the author of your own work instead of becoming a middleman who shuttles AI output into a project without really touching it. Some experienced programmers already worry about a kind of "brain rot" that can come from long, obsessive stretches of coding, leaving the mind "less open" over time [2]. For those developers, letting an AI handle the grunt work is a relief — it frees them to focus on the bigger goal of "building things" for clients, which many find more satisfying than the mechanics of coding itself [2]. One developer using an AI coding tool called "Claude Code" said they loved seeing clients happy and getting paid, but disliked wrestling with obscure integrations and chasing down odd bugs [2].
Retyping offers a middle path between those extremes. It still cuts out the tedious boilerplate, but it keeps the human as the one steering and understanding the code — preserving what many developers actually enjoy about the craft: solving real technical problems [2], not just assembling other people's output.
From a pure learning standpoint, there's an even more rigorous method: read an example, understand it, then try to reproduce it from memory without looking, as one former CS teacher points out [1]. That builds deeper skill, but it's slow — probably too slow for the day-to-day pressure of shipping software. Retyping is the practical compromise: most of the learning benefit, without abandoning production speed entirely.
For companies and engineering teams, the stakes are more concrete than "developer happiness." GitClear's finding — that AI-era code churn is on pace to double [5] — translates directly into wasted engineering hours, delayed releases, and more bugs slipping through to customers. Seen this way, a developer who works at a modest 2x speed but produces code that rarely needs to be redone is worth far more to a team than a "10x" developer whose output keeps bouncing back for fixes.
Retyping is, in effect, a way of managing the risk of accumulating "cognitive debt" across an entire team [3]. When developers actually understand the code they write, code reviews catch more real problems, knowledge doesn't stay locked in one person's head (lowering what's sometimes called the "bus factor" — how much the team suffers if one key person leaves or is unavailable), and the whole system becomes easier to maintain. It's a bet that a bit more care up front buys a faster, steadier pace over the long run.
Where this is heading
The debate over retyping isn't really about typing speed — it's a small, concrete stand-in for a much bigger question: how much of software development should we hand over to machines, and how much human understanding are we willing to trade away for speed?
The evidence so far — the GitClear churn numbers, the small but suggestive MIT study — are early warning signs rather than final proof [5]. But they point in the same direction: just generating code faster, without anyone truly absorbing it, doesn't scale well. Retyping is a grassroots response to that — individual developers deciding, on their own, to slow down enough to actually learn what they're shipping.
This is my own reading of the situation, but the signs suggest this won't stay a purely manual habit for long. Right now, retyping is a personal discipline — a deliberate choice to resist the fastest available option. It's easy to imagine tools evolving to support that choice directly: code editors that track whether code was typed or pasted, or AI assistants redesigned to ask you questions and check your understanding rather than simply handing over finished code — more like a tutor than a vending machine.
Some real questions remain open. Can a habit that works for individual developers scale up to large teams working under hard deadlines? What exactly is the "Explanation Gate" — a method mentioned only in passing in one source [5], hinting that more formal, team-wide versions of this idea may already be taking shape? And underneath it all is a genuine disagreement that isn't going away: some developers see programming as a craft worth mastering for its own sake, while others see it as a means to an end — a chore to automate so they can focus on building products [2].
What does seem settled is that the question has shifted. It's no longer "should we use AI to write code" — it's "how do we use it without losing the understanding that makes us capable of catching its mistakes." Retyping is one of the first answers to that question, and a very personal one: a bet that, even in the age of AI, understanding your own code is worth more than getting it faster.