Prevent cognitive debt by manually retyping LLM-generated code

通过手动重打 LLM 生成的代码来防止认知负债

Despite what I said in April, I’m still using coding assistants on my personal projects. Using them to one-shot entire features leaves me unsatisfied and disoriented, but I do enjoy using them to fast-forward through the boring parts of my projects. 尽管我在四月份曾那样说过，但我仍在个人项目中使用编程助手。用它们一次性生成整个功能让我感到不满足且迷失方向，但我确实喜欢用它们来快速跳过项目中枯燥的部分。

However, allowing my coding assistant to roam free in my projects leaves me with a colossal amount of cognitive debt. I might hate the idea of poring over the Django documentation to figure out how to add tagging to my website, but I still fundamentally want to understand how it works. Just because a problem is boring doesn’t mean I want to fully offload my understanding of the solution to a machine. 然而，任由编程助手在我的项目中自由发挥会给我留下巨大的认知负债。我可能讨厌钻研 Django 文档来弄清楚如何为我的网站添加标签功能，但我从根本上仍然希望理解它是如何工作的。仅仅因为一个问题很枯燥，并不意味着我想把对解决方案的理解完全转嫁给机器。

Of course, I could review every single line of code the LLM produces. That’s what most developers are expected to do in this cursed year of 2026. Robots raise PRs, humans review them. It’s a brave new world. 当然，我可以审查 LLM 生成的每一行代码。这就是在这个该死的 2026 年，大多数开发者被期望做的事情。机器人提交 PR，人类进行审查。这是一个勇敢的新世界。

But I don’t enjoy reviewing AI-generated PRs. Poring over hundreds of lines of overly-defensive, badly-commented, subtly incorrect code is not fun. I might grudgingly do it for an employer—while making sure said employer becomes an ex-employer as soon as possible—but I’m sure as hell not doing it for my personal projects. Personal projects must be fun above all else. The joy of working on personal projects comes from the process, not from the outcome. 但我并不喜欢审查 AI 生成的 PR。盯着数百行过度防御、注释糟糕且存在细微错误的代码一点也不有趣。我可能会为了雇主勉强去做——同时确保该雇主尽快成为“前雇主”——但我绝不会在个人项目中这样做。个人项目最重要的是乐趣。从事个人项目的快乐源于过程，而非结果。

So what’s a boy to do? How do I offload the boring work to LLMs without ceding control of my own work and cognition to the slop machine? 那么，我该怎么办呢？我该如何在不把自己的工作和认知控制权交给这台“垃圾制造机”的情况下，将枯燥的工作卸载给 LLM？

I’ve come up with a solution that’s grossly inefficient and perhaps slightly comical: I ask my coding assistant to generate code in the chat, then manually make all the edits myself. 我想出了一个非常低效甚至有点滑稽的解决方案：我让编程助手在聊天窗口中生成代码，然后我自己手动进行所有的编辑。

I have these instructions in all the agents files in my personal projects: I want to understand every line of code that goes into this project. Never create, edit, move, rename, or delete project files unless I explicitly ask you to do so. Instead, show me every proposed edit in the chat so I can type it in manually. 我在个人项目的所有代理配置文件中都加入了这些指令：我希望理解进入该项目的每一行代码。除非我明确要求，否则永远不要创建、编辑、移动、重命名或删除项目文件。相反，请在聊天窗口中向我展示每一个建议的修改，以便我可以手动输入。

Do not run commands that modify project files, install dependencies, or change repository state unless I explicitly request that action. Instead, show me those commands in the chat so I can run them manually. 除非我明确要求，否则不要运行修改项目文件、安装依赖项或更改仓库状态的命令。相反，请在聊天窗口中向我展示这些命令，以便我可以手动运行它们。

I’m an experienced developer. Do not explain syntax, APIs, programming concepts, or implementation details unless explicitly asked. Using LLMs this way allows me to work faster than not using LLMs at all, but I’m still slower than those who are willing to allow the machine to think for them. Instead of being 10x faster, I’m probably only 2x faster. But what I lose out on in terms of speed, I gain in terms of a deeper understanding of my code. 我是一名经验丰富的开发者。除非明确要求，否则不要解释语法、API、编程概念或实现细节。以这种方式使用 LLM 让我比完全不用 LLM 工作得更快，但我仍然比那些愿意让机器替自己思考的人要慢。我可能只快了 2 倍，而不是 10 倍。但我在速度上失去的，在对代码的更深层理解上得到了补偿。

As I manually type every single line of LLM generated code into my editor, I build up a mental model of how it works and fits into my existing codebase. If I don’t understand an API or algorithm, I can stop to look it up, or just ask the LLM to explain it. 当我手动将 LLM 生成的每一行代码输入编辑器时，我建立了一个关于它如何工作以及如何融入现有代码库的心理模型。如果我不理解某个 API 或算法，我可以停下来查阅，或者直接让 LLM 解释它。

Typing the code myself forces me to slow down, which means I’m more likely to detect hallucinations or bad design choices the LLM might have made. I can clean up the code as I go, reorganizing it, refactoring it, adding comments, and generally adapting it to my own taste. 亲自输入代码迫使我放慢速度，这意味着我更有可能发现 LLM 可能产生的幻觉或糟糕的设计选择。我可以在输入过程中清理代码，对其进行重组、重构、添加注释，并根据自己的喜好进行调整。

Most importantly, this workflow allows me to build a spatial map of my codebase. I know where every bit of functionality lives in the codebase. When I need to make a change, I need to know exactly where I need to make it. It not only helps me work faster within my projects, it also makes it easier for me to better prompt and instruct the LLM in the future. 最重要的是，这种工作流让我能够构建代码库的“空间地图”。我知道每一部分功能在代码库中的位置。当我需要进行更改时，我确切地知道需要在哪里进行。这不仅帮助我在项目中工作得更快，也使我在未来能更容易地更好地提示和指导 LLM。

When I was learning to code as a teenager, experienced programmers would often tell me to never copy and paste code into my projects. If I was learning from a book, I was advised to copy all the examples into my computer and make sure I could run them. If I was learning from a blog post or forum answer, I was advised to type it out and adapt it to my codebase so I understood it completely. 当我十几岁学习编程时，经验丰富的程序员经常告诉我，永远不要直接复制粘贴代码到我的项目中。如果我是从书本上学习，他们建议我把所有的示例都敲进电脑，并确保我能运行它们。如果我是从博客文章或论坛回答中学习，他们建议我把它敲出来并适配到我的代码库中，这样我才能完全理解它。

Manually typing LLM-generated into my codebase feels like the exact same learning process. It might not be the most efficient way to work with an LLM, but I value comprehension over productivity. I’ve been doing this for a few months now, and it’s been working well for me. I plan to continue using this workflow for as long as I can. 手动将 LLM 生成的代码输入到我的代码库中，感觉就像是完全相同的学习过程。这可能不是使用 LLM 最有效率的方式，但我更看重理解而非生产力。我已经这样做了几个月，效果很好。我计划尽可能长久地继续使用这种工作流。

I fear the software industry is taking on a large amount of cognitive debt that we’ll have to pay back very soon. There will come a time when we no longer understand how large parts of our digital infrastructure are put together. I might not personally be able to change the course of the entire industry, but I can at least make sure I completely understand the software I put out into the world. Anything else would be professional malpractice. 我担心软件行业正在承担大量的认知负债，我们很快就必须偿还。终有一天，我们将不再理解我们数字基础设施的很大一部分是如何构建起来的。我个人可能无法改变整个行业的走向，但我至少可以确保我完全理解我发布到这个世界上的软件。除此之外的任何做法都是职业失职。