Retyping LLM code manually. The friction builds understanding.

Eighteen months ago, the dominant anxiety around AI coding tools was whether they would produce correct code. Today, for developers who have been using tools like Cursor or GitHub Copilot long enough, a quieter problem has surfaced: the code is often correct, and you still have no idea how it works.

Ankur Sethi's post on cognitive debt proposes a deliberately slow solution to this: when an LLM gives you code you do not fully understand, retype it manually instead of pasting it. Not copy-paste-edit. Retype, character by character. The argument is not about catching bugs. It is about forcing comprehension before the code enters your codebase and your brain moves on to the next thing.

Two developers, one codebase, different results

The sharpest version of the argument is best heard as a disagreement between two working developers.

Developer A: I use AI-generated code constantly and I review every line before merging. If something looks wrong I catch it. Retyping is cargo cult behavior dressed up as discipline.

Developer B: You review it, but do you understand it? There is a difference between "this looks correct" and "I could write this from scratch if I had to." The second one is what lets you debug it at 11pm when the model is not available and the prod system is down.

Developer A: So I should slow down by 10x on every snippet to protect myself from a hypothetical incident?

Developer B: Not every snippet. The ones you copy without really reading. Which, if you are honest, is most of them.

That last line is the part worth sitting with. Sethi's method is not about speed. It is about identifying which category a given block of code falls into.

The number that matters is not lines of code

That is the number Sethi is really talking about, even if he does not frame it this way. Not how many lines an LLM produces per session, not how fast a feature ships. The relevant figure is: how much of your current codebase could you actually reason about if the model went offline, the context window reset, and you had to fix a regression from three sprints ago?

This is not a hypothetical. Codebases grow. The LLM-generated sections, pasted in during a fast sprint, become the load-bearing parts nobody wants to touch. If those sections were typed manually, they were probably typed more slowly, with pauses to check what a specific method does, what assumptions a loop makes, what would break if the input were null. Those pauses are the entire point.

Consider what happens if the threshold doubles. If you retype code that would take 30 seconds to paste, you are committing maybe 5 to 10 minutes per meaningful block. On a day where you integrate four or five significant LLM-generated functions, you have spent an extra 20 to 40 minutes. That is real time. The question is whether you would trade that time for being able to explain every line in your next code review, or maintain the module without context six months later. For library code or anything close to a system boundary, the trade is almost always worth it. For scaffolding you will delete in a week, probably not.

A specific workflow where this changes the outcome

Suppose you are building a custom rate limiter for an internal API. You describe the behavior to Claude Code: sliding window, per-user token bucket, Redis backend. The model returns 60 lines of Python. The logic looks right at a glance. You are in a sprint. You paste it in, tests pass, you move on.

Three weeks later, under production load, the rate limiter starts allowing requests through that should be blocked. The bug is in how the token refill is calculated when a request arrives exactly at the window boundary. The logic is subtle. You open the file to debug it and realize you have essentially no memory of writing it. You cannot reason about the off-by-one without re-reading the entire function from scratch, which is what you are now doing under pressure, in production, with people waiting.

Now replay the same scenario with Sethi's method. You retype the 60 lines. Somewhere around line 35, where the refill calculation happens, you pause because the arithmetic does not immediately make sense to you. You work through it. You might not even change anything. But now you own that logic. When the boundary bug appears, you remember the calculation. You know exactly where to look. The debug time drops from 45 minutes to 5.

The method works best precisely on the code that feels least necessary to retype: the parts that look obviously correct, that "any competent model would get right." Those are the parts where passive acceptance is highest and comprehension is lowest.

This connects to a broader conversation about what AI coding assistants actually change in a development workflow. Speed of initial output is obvious and measurable. Comprehension of that output is diffuse, personal, and only becomes visible during maintenance, incidents, and code reviews. Teams optimizing entirely for the first metric are accumulating something real on the other side of the ledger.

The open question following all of this: is the retyping technique scaling to the next generation of AI coding tools, where agents write entire modules autonomously across multiple files? When the unit of generation is no longer a function but a feature, manual retyping is not a practical intervention. What replaces it, and whether anything can, is something nobody has answered satisfactorily yet.