Code is Cheap(er) / 代码变得更“廉价”了

Carson Gross | June 04, 2026

There is no getting around the fact that, in the last year, code has gotten much cheaper to create. AI is able to generate reams and reams of code, often of reasonably decent quality, incredibly quickly. There is no point in pretending that this isn’t the case. 不可否认的事实是，在过去的一年里，编写代码的成本已经大幅降低。人工智能能够以惊人的速度生成海量的代码，且质量往往相当不错。假装看不到这一点毫无意义。

At times, when confronted with this admittedly uncomfortable fact, I have seen people I respect say something like “coding was never the problem.” While I appreciate the sentiment, I don’t completely agree with that: certainly coding was at least part of the problem. And that part of the problem has shrunk significantly with the advent of effective AI coding tools. So what does raw coding becoming less important mean for software developers, people who, in the past, prided themselves (and often compared themselves) on their ability to code? 有时，当面对这个令人不安的事实，我看到一些我尊敬的人会说：“编程从来都不是问题所在。”虽然我理解这种情感，但我并不完全赞同：编程显然至少是问题的一部分。而随着高效 AI 编程工具的出现，这部分问题已经显著缩小。那么，对于过去以编程能力为傲（并常以此作为比较标准）的软件开发者来说，原始编程变得不再那么重要意味着什么呢？

Understanding is Expensive(er) / 理解变得更“昂贵”了

One thing I see is that it means that understanding code has become more expensive. This is because when reams and reams of code are generated, rather than emerging painfully from a particular programmer’s fingers, there is no understanding of that code. In as much as understanding that code needs to exist, it has to be done after the code is written, by reading the code. Note that conventional wisdom is that reading someone else’s code is harder than writing your own code. 我看到的一点是，这意味着理解代码变得更加昂贵了。这是因为当海量代码被生成，而不是由程序员亲手痛苦地敲出来时，人们对这些代码缺乏理解。如果需要理解这些代码，就必须在代码写好之后，通过阅读来完成。请注意，传统观点认为阅读他人的代码比编写自己的代码更难。

Some AI enthusiasts say “Who cares, you don’t understand the output of compilers.” I think that is a category error for multiple reasons: Compilers are deterministic; LLMs are, by design, not. Compiler workflows retain their original source code; LLM workflows typically do not. Compiler output is to a narrowly constrained domain (machine code); LLM output is not (generalized software). 一些 AI 爱好者说：“谁在乎呢，你也不理解编译器的输出啊。”我认为这在多个层面上犯了范畴错误：编译器是确定性的，而 LLM 在设计上并非如此；编译器工作流保留了原始源代码，而 LLM 工作流通常不会；编译器的输出局限于狭窄的领域（机器码），而 LLM 的输出则不然（通用软件）。

I maintain that, in most cases and certainly for mission-critical software, developers still need to understand the underlying code even if it is generated by an LLM. And if code is generated by an LLM there is a stark danger: the LLM can produce code far faster than you, or anyone else, can understand it. This is why I recommend incremental use of LLMs rather than allowing them to generate massive changelists that neither you, nor anyone else, can understand. (There are times when this can be appropriate, such as in a mechanical refactor, but it is extremely dangerous when new semantics are being introduced into a code base.) 我坚持认为，在大多数情况下，尤其是对于关键任务软件，开发者仍然需要理解底层代码，即使它是通过 LLM 生成的。如果代码由 LLM 生成，存在一个严峻的危险：LLM 生成代码的速度远超你或任何人理解它的速度。这就是为什么我建议增量式地使用 LLM，而不是让它们生成你或任何人都无法理解的大规模变更列表。（在某些情况下，例如机械式的重构，这样做可能是合适的，但当代码库中引入新的语义时，这是极其危险的。）

The Sorcerer’s Apprentice Trap / “魔法师的学徒”陷阱

One movie scene that has been consistently coming back to me as I have watched AI garner more and more attention is The Sorcerer’s Apprentice from Disney’s movie Fantasia. In this scene the apprentice decides to use magic to assist in the drudgery of cleaning. He enchants a broom which then proceeds to start cleaning things up. Things appear to be going swimmingly for a while, until the broom starts cleaning more and more vigorously, reaching a point where things start going swimmingly literally. The chaos is resolved when the Sorcerer reappears and asserts control over the situation, glaring at the apprentice for his foolishness. This seems like an apt metaphor for the AI era: you want to be a sorcerer and not an apprentice. And a sorcerer has to understand the code. 当我看到 AI 受到越来越多的关注时，迪士尼电影《幻想曲》中“魔法师的学徒”这一场景不断浮现在我脑海中。在这一幕中，学徒决定利用魔法来辅助繁重的清洁工作。他给一把扫帚施了魔法，扫帚便开始打扫卫生。起初一切似乎都很顺利，直到扫帚开始越来越卖力地打扫，最终导致房间里真的“水漫金山”（swimmingly 一词的双关）。当魔法师重新出现并控制住局面，怒视着愚蠢的学徒时，混乱才得以平息。这似乎是 AI 时代的一个恰当隐喻：你要做魔法师，而不是学徒。而魔法师必须理解代码。

Complexity: Still Bad / 复杂性：依然是祸害

Humans, generally, have a poor grasp of geometric and exponential curves. (This is why they believe in fairy tales such as compound interest.) The core danger of code being cheap is complexity, which I assert, without proof, tends to grow at least geometrically and often exponentially with the size of a system. 人类通常对几何级数和指数曲线的理解能力很差。（这就是为什么他们相信复利这种“童话”。）代码廉价带来的核心危险是复杂性，我断言（无需证明），复杂性往往会随着系统规模的扩大而呈几何级数增长，甚至经常呈指数级增长。

Before LLMs there were prolific human coders. Perhaps you have worked with one: they can write a lot of code. I have seen prolific coders who lack a proper fear of complexity heap more and more code on top of an existing problem until the whole system collapses into an unmodifiable steady state, where any change creates as many bugs as it fixes. LLMs are incapable of fear of complexity, and are prolific coders. Seems dangerous to me. 在 LLM 出现之前，就有高产的程序员。也许你曾与他们共事过：他们能写出大量的代码。我见过一些缺乏对复杂性敬畏之心的高产程序员，他们在现有问题上堆砌越来越多的代码，直到整个系统崩溃成一种无法修改的稳定状态——任何改动带来的 Bug 都和修复的一样多。LLM 不懂得对复杂性的恐惧，且又是高产的“程序员”。这在我看来非常危险。

The Subtractive, Constraining Engineer / 减法式、约束型的工程师

To address this danger of LLM-generated code, I propose the subtractive, constraining engineer: This engineer says no, closely examines LLM output, suggests simplifications and generally retains a firm hand when dealing with LLM-generated code. Rather than priding themselves on the code they create, they pride themselves on the code (and layers) they remove from or prevent from entering systems. This ethos is more sculptor and less builder. 为了应对 LLM 生成代码带来的这种危险，我提议采用“减法式、约束型”的工程师模式：这种工程师会说“不”，仔细审查 LLM 的输出，提出简化方案，并在处理 LLM 生成的代码时始终保持严格的把控。他们不以自己创造了多少代码为荣，而是以从系统中移除或阻止进入系统的代码（及层级）为荣。这种理念更像是雕塑家，而非建筑工。

Where the builder ethos still applies, to an extent, is at the system design level: a good engineer will need to know how to compose components effectively to create systems. However, even here, I think that the subtractive mindset will be useful: removing unnecessary components and system boundaries to simplify system deployment and inter-component interactions, etc. 建筑工的理念在一定程度上仍适用于系统设计层面：优秀的工程师需要知道如何有效地组合组件来构建系统。然而，即使在这里，我认为减法思维依然有用：移除不必要的组件和系统边界，以简化系统部署和组件间的交互等。

The subtractive engineer is a different kind of engineer than most coders have been in the past. I will admit that I have always been sympathetic to the subtractive engineer mindset: I don’t mind saying no, I don’t mind polishing existing systems rather than heroic rewrites, etc. But, admitting my own biases, I believe this approach is a productive way to engage with LLMs that retains the art of computer programming and properly acknowledges a dual reality: code has gotten much cheaper to create and complexity remains our apex predator. 减法式工程师与过去大多数程序员的类型不同。我承认我一直很认同这种减法式工程师的思维：我不介意说“不”，也不介意打磨现有系统而不是进行英雄式的重写。但即便承认我自己的偏见，我也相信这种方法是与 LLM 协作的一种高效方式，它既保留了计算机编程的艺术，又正确地承认了一个双重现实：代码的创建成本已经大幅降低，而复杂性依然是我们最大的天敌。