Foreword

On August 4, 2026, developer Ankur Sethi published an article on his personal blog titled Prevent cognitive debt by manually retyping LLM-generated code, advocating for avoiding “cognitive debt” by manually retyping AI-generated code line by line. The post earned 409 points and 348 comments on Hacker News, where the comment section was almost evenly split: one side argued this was a necessary corrective to “Vibe Coding,” while the other side questioned: “Isn’t this just copy-pasting with extra steps?”

Sethi himself is a seasoned developer who still uses coding assistants like Claude Code and Cursor for personal projects. His problem is specific: while agents can generate full features quickly, they leave him “disoriented” with the codebase; and reviewing hundreds of lines of AI-submitted PRs line by line is unbearably tedious. Thus he came up with an “extremely inefficient, somewhat comical” middle path—having the agent only show the changes, not write files directly, and typing everything into the editor himself.

This article breaks down Sethi’s core arguments, the main debates on HN, and the more widely accepted alternative practices from the comment section, to help you make choices for your 2026 AI programming workflow.

What is “Cognitive Debt”

Sethi uses Cognitive Debt as an analogy to technical debt: when you fully hand off the responsibility of understanding a piece of code to an LLM, the code may work, but your mental model of it is empty—you cannot debug issues independently, do not know where to start when modifying requirements, and ultimately have to go back to the chat window to ask the AI “what does this do?”

He gives a typical scenario in his article: adding a Django tagging feature to a personal website. Looking up documentation is boring, but he still wants to understand how the solution works. “Boring problems” do not equal “can outsource understanding to machines.”

This creates tension with the industry mainstream in 2026: bots open PRs, humans do reviews. Sethi acknowledges this model exists, but he does not want to act as an “AI code auditor” for his personal projects. The joy of personal projects lies in the process, not just the deliverable; reviewing hundreds of lines of AI code that is overly defensive, has messy comments, and hides bugs is neither fun nor accumulates cognitive debt for him.

Sethi’s Workflow: Agent Talks, Doesn’t Write

Sethi’s solution can be summarized as: LLM as advisor, human hands as executors. He wrote three hard rules in the agent configuration files (similar to AGENTS.md) for each project:
1. Prohibit agents from modifying files directly—do not create, edit, move, rename, or delete project files unless he explicitly requests it.
2. Show changes and commands only in chat—the agent outputs every proposed edit and shell command to the conversation, which he will execute manually.
3. Skip basic tutorials—he is an experienced developer and does not need the agent to explain syntax or APIs unless he asks actively.

The actual workflow is as follows:

Requirement description → Agent generates code snippets / diff suggestions in chat
                        → Developer manually types each line into the editor
                        → Pauses to look up documentation or ask the LLM about unfamiliar APIs or algorithms
                        → Makes minor refactors, adds comments, adjusts style on the fly

Sethi admits this workflow is roughly twice as fast as not using AI, but far from the “10x speedup” claimed by fully delegated agent workflows. He actively trades speed for understanding—“I value comprehension over productivity.” He says he has practiced this for months with good results.

He also compares this practice to old programming learning experience: typing out example problems from books, rewriting code copied from blog posts into your own project structure. Manual input forces the brain to slow down, making it easier to spot hallucinations, incorrect API calls, or poor design; at the same time, it builds a “spatial map” of the codebase—knowing where each feature is located, so you do not need to ask the AI next time you make changes.

Heated Debate on HN

The core disagreement in the HN discussion is not “whether understanding code matters”—almost everyone agrees understanding is important—but whether manual retyping is the correct mechanism to achieve understanding.

Pro Side: Friction Creates Awareness

Supporters argue that retyping creates a forced pause point: you have to process every character, making it easier to notice illogical variable names, flawed assumptions, or unfamiliar API calls. Compared to “reading a diff → one-click Accept,” mechanical input at least prevents you from skipping details entirely. Someone recalled the era of learning programming from magazines: “This is basically how I copied code from BYTE magazine back in the day.”

Sethi also emphasized that slowing down helps catch hallucinations—LLM-generated code may work on the surface, but might use non-existent methods or incorrect library versions; these details are easy to overlook when pasting quickly.

Con Side: Retyping ≠ Creating, It May Be “Clerical Theatre”

The top-voted criticism on HN targets the mechanism itself. A representative comment reads:

If your workflow is: think carefully → ask LLM to write code → read what LLM wrote → think again → retype → fix again—where is the efficiency gain? Just cut out the LLM and save the tokens.

Critics point out: retyping code you have already reviewed is a completely different cognitive activity from designing and implementing it yourself. Students copying class notes often enter “automatic typing” mode, with almost no memory retention. Retyping may just replace copy-paste with copy-retype, without increasing real depth of understanding.

Others argue that what Sethi really wants is “comprehension,” but he chose “retyping” as an unnecessary means—understanding can be achieved through other methods, without character-by-character transcription.

Deeper Question: Is Reviewing Enough?

Another recurring concern in the comment section: reading a diff and being able to debug independently are two different things. It is like learning a foreign language—you can read a sentence, but that does not mean you can speak it yourself. Six weeks later when you receive a bug report, the code you “understood” during passive review may not help you locate the problem, especially at 3 a.m. without AI assistance.

This is more practically relevant for teams: many tech leads report that new hires use AI to deliver tickets quickly, but still lack the basic intuition that should be built through manually tracing bugs—this is a different level of problem from the cognitive debt in Sethi’s personal projects.

More Widely Accepted Alternatives from the Comment Section

Even while criticizing Sethi’s specific method, several more consensus-driven practices emerged from the HN thread:

1. Plan First, Then Delegate
Have the agent first output an implementation plan, have humans review and revise the plan, confirm “what should happen,” then ask the agent to write the code. Decision-making power stays with humans, and character input can be delegated.

2. Chat-Only Review, Paste Only After Understanding
Have the agent show the diff in chat, read it carefully, ask questions, confirm your understanding before pasting it—skip mechanical retyping, but keep the threshold of “I understand before committing to the codebase.”

3. Design-First Delegation
Write architecture, function signatures, and data flows yourself; have the agent only fill in implementation details. The most critical parts for maintainability stay in the human brain.

4. Treat AI as a Rubber Duck
Ask “are there any missing design issues” before implementing, which is far more cost-effective than reviewing hundreds of lines after writing them.

5. Strictly Limit Scope
Only request single-file, small-scale changes each time, making the review burden similar to reviewing a small colleague PR, rather than auditing a 1000-line drop.

6. Use Tests as Ground Truth
Write failing tests first, then ask the agent to fix the bugs—correctness is verified by tests, not solely relying on manual code reading.

7. Match Friction to Stakes
No one advocates retyping boilerplate or test scaffolding; the debate centers on core business code that needs long-term maintenance and whose issues you have to take responsibility for. For disposable code or code with sufficient test coverage, prioritizing speed is more reasonable.

A Practical AGENTS.md Reference

If you agree with Sethi’s framework of “agents do not modify files directly” but do not want to retype line by line, you can use a compromised agent rule configuration. The following is adapted from Sethi’s original article, and can be adjusted per project:

## Agent Collaboration Rules
- Comprehension First: I need to understand every line of code in the project. Do not create, edit, move, rename, or delete any files unless I explicitly ask you to.
- Show Changes Only: All proposed edits and commands that modify repository state should only be displayed in the conversation, to be executed manually by me.
- Concise Output: I am an experienced developer, do not explain basic syntax or APIs by default, unless I ask follow-up questions.
- Small Step Commits: Keep the scope of each proposed change as small as possible to facilitate my review and understanding.

Accompanying practice: Before merging any AI-generated code, explain to yourself in two sentences “what this code does and why it was written this way”—if you cannot do this, it means cognitive debt has already accumulated, and you need to pause and gain understanding before committing.

Summary: Mechanism Debatable, Alertness Indispensable

Sethi’s “line-by-line retyping” is an extreme personal practice, and HN’s criticism of its mechanism is valid—mindless transcription does not equal deep comprehension. But the problem he pointed out—that fully delegating AI work will accumulate cognitive debt in the codebase, which will erupt集中爆发 during midnight incidents or security audits—is hard to refute.

You do not have to choose either extreme:
- Personal side projects, long-term maintenance modules: You can draw on Sethi’s “agent only talks, doesn’t write + force slowdown” approach; retyping is just one option, and “understand before committing” is the core.
- Team production environments: A more realistic path is plan-first, small-scope PRs, test-driven development, and asking “why this approach” during reviews, rather than requiring everyone to retype every line.
- Simple standard for judging debt: If you cannot explain your PR without referencing chat logs during review, debt has already accumulated.

The design goal of 2026 AI programming tools is eliminating friction. The real question raised by the debate between Sethi and HN is: In which areas will you intentionally add friction—and what way to add it, so that it preserves understanding without devolving into inefficient performative work.

References
- Ankur Sethi, Prevent cognitive debt by manually retyping LLM-generated code
- Should You Manually Retype LLM-Generated Code? The HN Debate (HN 409 points / 348 comments discussion summary)