Do You Still Read the Code?

“Do You Still Read the Code?” 14 September 2026 “你还在读代码吗？” 2026年9月14日

There is considerable difference between that question and a more innocuous “do you read the code?” The addition of still smuggles with it a theory of progress: reading code is something on its way out, like memorising phone numbers or unfolding paper maps, and the asker seems to want to know if you by chance aren’t one of the obscurantists still clinging to the old ways. 这个问题与更温和的“你读代码吗？”之间存在巨大差异。增加“还”（still）这个词，暗含了一种进步论：读代码正逐渐被淘汰，就像背诵电话号码或展开纸质地图一样。提问者似乎想确认你是否恰好不是那些仍固守旧习的“蒙昧主义者”。

I use AI extensively, and I read what it produces. This is a deliberate choice about how I want to develop software, at least at my job, where I’m expected to be reasonably responsible for the code that I commit and deploy. Other people make a different choice, sometimes with considerable care. But we have begun sharing codebases without necessarily agreeing on what either path asks of our colleagues. 我广泛使用人工智能，并且我会阅读它生成的代码。这是我对自己软件开发方式的一种深思熟虑的选择，至少在我的工作中是这样——因为我需要对我提交和部署的代码承担合理的责任。其他人做出了不同的选择，有时也相当谨慎。但我们开始共享代码库，却未必就这两种路径对同事提出的要求达成了一致。

It is very hard to tell which choice will prevail. The still presumes that the matter has been settled, and indeed producing a working application these days has become quite a bit easier. But finding out what it costs to maintain it through changes of requirements, developers, and tooling takes considerably longer. We are making commitments with respect to how teams work now, and their consequences will only later be felt and understood. The confidence with which either mindset announces its victory seems somewhat premature. 很难说哪种选择会胜出。“还”这个词预设了问题已经解决，确实，如今开发一个可运行的应用程序变得容易多了。但要弄清楚在需求、开发人员和工具变更的过程中维护它需要付出什么代价，则需要更长的时间。我们现在正在对团队的工作方式做出承诺，而其后果只有在以后才能被感知和理解。任何一种思维模式在宣布胜利时所表现出的自信，似乎都有些操之过急。

Accelerators and vibecoders

加速者（Accelerators）与氛围编码者（Vibecoders）

As far as I can tell, there are two prevalent approaches to using AI these days. Accelerators use AI to help translate their understanding into code. They intend to retain enough understanding of the implementation to explain the reasoning behind the translation from intent to code, anticipate the consequences of changes, and maintain the resulting model and its implementation. Reading the generated code is part of that commitment. 据我观察，目前使用人工智能有两种主流方法。“加速者”利用人工智能帮助将他们的理解转化为代码。他们打算保留对实现的足够理解，以便解释从意图到代码转换背后的逻辑，预见变更的后果，并维护生成的模型及其实现。阅读生成的代码是这一承诺的一部分。

For accelerators, language models and harnesses exist in roughly the same category as text editors and their plugins: they can now code faster. They invest in their continued ability to explain and change the implementation. Large changes are slow to review, a generated diff that is determined to incorrectly implement a model is rewritten, cognitive debt piles up whenever the team’s reading falls behind the generating, and the whole thing requires discipline that is very hard to keep. 对于“加速者”来说，语言模型和辅助工具与文本编辑器及其插件大致属于同一范畴：他们现在可以写代码更快了。他们投入精力以保持解释和修改实现的能力。大型变更审查缓慢，被判定为错误实现模型的生成差异会被重写，每当团队的阅读速度跟不上生成速度时，认知债务就会堆积，而这一切都需要极难保持的纪律性。

Vibecoders aim to delegate implementation and its continued revision to AI. Their attention moves towards specifying the desired behaviour, supplying context and domain knowledge, and establishing ways to determine whether the result is satisfactory. Understanding every implementation detail is no longer an intended product of their work. “氛围编码者”旨在将实现及其持续修订工作委托给人工智能。他们的注意力转向指定期望的行为、提供上下文和领域知识，并建立确定结果是否令人满意的方法。理解每一个实现细节不再是他们工作的预期产出。

Vibecoders expect language models to abstract away implementation, putting them in the same category as compilers and frameworks: there should no longer be a need to understand technical details. They invest in their continued ability to specify, regenerate, and evaluate code. Intent debt may accumulate as requirements are rewritten or forgotten, context drifts between sessions, engineering time goes into curating what the agents get to see to keep them away from the “dumb zone,” and the whole thing stands or falls with the quality of a model that is controlled by Anthropic or OpenAI. “氛围编码者”期望语言模型能抽象掉实现细节，将它们归入与编译器和框架相同的范畴：不再需要理解技术细节。他们投入精力以保持指定、重新生成和评估代码的能力。随着需求被重写或遗忘、上下文在会话间漂移，意图债务可能会累积；工程时间被用于筛选代理程序所能看到的内容，以使它们远离“愚蠢区”；而这一切的成败都取决于由 Anthropic 或 OpenAI 控制的模型质量。

The distinction concerns the developer’s relationship to the output, rather than how much of it the model writes. An accelerator might generate almost every line of a feature and still understand what was built, taking ownership of the reasoning behind it. A vibecoder might spend considerable time refining a specification and its acceptance criteria, while deliberately treating the resulting implementation as disposable. Being an accelerator doesn’t require knowing the answer before asking the model—you can use generated code to explore a problem you don’t yet understand, provided that understanding is something you intend to acquire before the code ends up on the master branch. 这种区别在于开发者与输出结果的关系，而不是模型写了多少代码。“加速者”可能会生成一个功能中几乎每一行代码，但仍然理解所构建的内容，并对背后的逻辑负责。“氛围编码者”可能会花费大量时间完善规范及其验收标准，同时刻意将生成的实现视为一次性的。成为“加速者”并不要求在询问模型之前就知道答案——你可以使用生成的代码来探索你尚未理解的问题，前提是你打算在代码进入主分支之前获得那种理解。

Naur is still undefeated

Naur 的理论依然未被击败

My own preference comes from what I think programming is for. I wrote before about how programming is essentially pure applied philosophy. I hadn’t read, at that time, Peter Naur’s essay, since brought to renewed prominence by the advent of LLMs, making a similar point thirty-five years earlier. It is essentially the same argument, made better, by someone much smarter: the code is not the real product of programming. If anything, we mistake the code for an asset, while more often than not it’s indeed a liability. 我个人的偏好源于我对编程目的的理解。我之前写过，编程本质上是纯粹的应用哲学。当时我还没有读过 Peter Naur 的文章（该文章因大语言模型的出现而重新受到重视），他在三十五年前就提出了类似的观点。这本质上是同一个论点，由一个更聪明的人表达得更好：代码并不是编程的真正产物。如果说有什么的话，那就是我们误把代码当作资产，而实际上它往往是一种负债。

The real product, the asset, is the model, or the theory, behind it. The theory is the kind of knowledge that lets a person not merely do something, but explain it, answer questions about it, use it to project the future, and adapt it if circumstances change. The programmer who possesses it is capable of three things: “The programmer having the theory of the program can explain how the solution relates… 真正的产物，即资产，是代码背后的模型或理论。这种理论是一种知识，它让人不仅能做某事，还能解释它、回答关于它的问题、用它来预测未来，并在环境变化时对其进行调整。拥有这种理论的程序员能够做到三件事：“拥有程序理论的程序员能够解释解决方案是如何关联的……”