On August 2, software engineer Ankur Sethi published a counter-cultural suggestion on his blog: when writing code with AI, don’t copy and paste—manually retype the AI-generated code into your editor line by line. He gave the AI a strict rule: display suggestions only in the chat panel; never edit files directly. That day, his post reached 363 points and over 300 comments on Hacker News, becoming the second most discussed story of the day.
Figure: The Hacker News thread where the debate unfolded. Source: news.ycombinator.com
The comment section quickly split into two camps. “This is a new form of prayer invented by people who can’t quit AI.” “The best way to stay fit is to walk behind a car.” “This is an absurdly silly idea.” While many criticized the approach, plenty offered strong support. One comment was quoted repeatedly: “It used to be that programmers who went into management had their coding skills rust. Now, we’ve all become managers.”
The Hidden Cost of AI Code: Accumulating “Cognitive Debt”
Why take such a seemingly backwards approach? Sethi has over a decade of programming experience and actively uses AI assistants. When allowing AI free rein, entire features can be written in minutes. But he noticed a growing problem: the code entered the repository, but the understanding never entered his head. Features went live, yet he couldn’t explain how they actually worked.
He calls this cognitive debt—the unpaid debt of true understanding. When the time comes to modify that code later, he finds himself asking the AI again: “What does this section do?” It felt like a student reviewing copied homework before an exam, unable to decipher a single line.
He tried standard industry practices first. The conventional workflow today is straightforward: an AI bot submits code, and a human engineer reviews it line by line. But reading hundreds of lines of overly defensive, poorly commented code with subtle bugs is exhausting and unrewarding. In his blog post, Sethi noted that while you might swallow your pride at work for an employer, personal side projects demand more—the joy of personal projects comes from the process and from every line crafted by your own hand.
This dilemma has scientific backing. An MIT study monitored 54 undergraduate students split into groups to write essays: one group used ChatGPT, another used search engines, and the third worked entirely unassisted. EEG monitoring revealed that the AI group exhibited the weakest neural connectivity in the brain. When asked to recap their essays just minutes after finishing, the AI group performed worst—they barely felt like they had written the piece themselves. The more tools step in, the less the brain engages. While the study did not conclude AI makes people “dumber,” it flagged a clear warning sign worth heeding.
Figure: EEG data from MIT study (Kosmyna et al.) showing weaker brain connectivity when external tools step in. Source: brainonllm.com
Sethi’s solution was setting strict boundaries for the AI assistant. In his project guidelines, he wrote: “I want to understand every line of code entering this repository. Unless explicitly requested, do not create, edit, move, or delete any files. Present all suggested changes in the chat window so I can enter them myself. I will also execute all terminal commands and install dependencies.” In short: treat AI as a consultant, not a ghostwriter.
What Does Manual Retyping Actually Train?
The routine sounds intentionally slow: AI generates code in the chat box, Sethi types it line by line into the editor, stopping to check documentation or ask AI for clarification whenever something is unclear. He estimates his productivity dropped from “10x speed” down to “2x speed”—in exchange for ensuring every line passes through his hands and mind.
This builds on a classic learning principle. Programmers who learned in the 1980s and 90s remember: mentors explicitly prohibited copying and pasting code from books or magazines. You had to type it out by hand, get it running, and tweak it. A generation of developers learned by re-keying code line by line into their computers. Manual input naturally forces you to slow down: as your hands type a line, your eyes process it, and your brain evaluates what that line actually does.
The muscle memory of typing engraves code structures into your fingers; next time you build a similar feature, your hands recall the pattern before your brain even finishes processing.
Retyping also serves as an active code review. Sethi noted that he spots AI hallucinations and sub-optimal designs far more easily when typing—because when hands move, the mind stays active, making flaws hard to miss. Once finished, a mental “code map” forms: knowing exactly where each piece resides and what needs updating. It also improves future prompting, as you gain clearer insight into how to direct the AI. Someone in the comments recalled how writer Hunter S. Thompson retyped Hemingway’s novels word for word in his youth just to feel the master’s rhythm. Retyping code follows the exact same logic.
The Counterargument: Muscle Memory vs. Deep Intuition
The fiercest opposition came from user f311a, who argued that retyping code is like copying calculus answers—it trains memory rather than intuition. People copying solutions know how to write each step, but lack the intuition for why that solution was chosen or what alternative paths exist. Their counter-proposal: write the initial implementation yourself first, then ask AI to refine and optimize it.
This viewpoint resonated with many. Critics pointed out ironically: by that logic, programmers should manually retype compiler-generated assembly code. Others noted that “typing speed is rarely the bottleneck,” and retyping spends valuable time on low-value mechanical tasks. Some warned that adopting this practice might get developers labeled as “slow” by colleagues. On the flip side, supporters cited cognitive research showing that passive consumption of “syntactically valid but semantically empty” output degrades learning—reading code is not the same as mastering it.
| Pro-Retyping | Anti-Retyping |
|---|---|
| Copying answers = no learning; retyping = true comprehension | Copying calculus answers trains memory, not intuition |
| Slowing down helps spot AI hallucinations and poor design | Typing is rarely the bottleneck; retyping wastes time |
| Muscle memory + code map = faster maintenance | Write first, then optimize with AI for maximum efficiency |
| Classic tradition: programming is learned by typing code yourself | Tools should free humans for higher-level work |
The divide highlights two sides of the same fundamental question: after delegating work to AI, are your engineering capabilities expanding or rusting? Advocates fear skill atrophy; opponents argue retyping is an inefficient defense, suggesting human design paired with AI execution works better.
Beyond Code: A Universal Dilemma for the AI Era
While this debate unfolded among software engineers, it reflects a universal turning point for anyone using AI at work. If AI writes your annual reports, can you still write them yourself? If AI generates your slide decks and spreadsheets, what remains of your analytical and presentation skills? “Failing to grow while AI takes over” is a challenge facing every domain, and developers are simply the first to hit the wall.
Non-coders can draw three actionable takeaways from this discussion. First, let AI draft initial content, then manually rewrite it into your own words—the editing process is the learning process. Second, ask AI to outline structural frameworks while filling in details yourself. Third, adopt a popular suggestion from the Hacker News comments: after completing a task with AI, have the AI quiz you on the output. Anywhere you struggle to answer marks unpaid cognitive debt.
Whether manual retyping is the optimal strategy remains unsettled across the 300+ comments. Sethi himself conceded the approach feels “comically inefficient.” Yet the debate leaves us with a vital question: When your tools make you 10 times faster, what are you willing to trade to preserve true understanding? AI cannot answer that for anyone. As the pace of technology accelerates, running fast is great—just make sure you don’t forget how to walk the path yourself.
References:
- Ankur Sethi: Prevent cognitive debt by manually retyping LLM-generated code
- HN Discussion (item?id=49153374)
