What We Lost the Last Time Code Got Cheap
What We Lost the Last Time Code Got Cheap
上一次代码变得廉价时，我们失去了什么
I worked at a startup in Toledo called Heartland Information Services. We provided transcription services to some of the biggest hospitals in the United States, and we weren’t small. Heartland was one of the larger medical transcription organizations in the country, one of the companies at the center of offshore transcription in that era.
我曾在托莱多一家名为 Heartland Information Services 的初创公司工作。我们为美国一些大型医院提供转录服务，而且规模并不小。Heartland 是当时国内较大的医疗转录机构之一，也是那个时代离岸转录业务的核心公司之一。
While that sounds simple enough, we were the kind of service where downtime had real consequences. Imagine needing emergency surgery but having to wait on a written copy of your procedure. Waiting may not be an option.
虽然听起来很简单，但我们的服务一旦停机，后果非常严重。试想一下，如果你急需手术，却不得不等待手术过程的书面记录，而等待可能根本不是一个选项。
The engineers we worked with in India were talented. The company operated as a hybrid, and at various points our most critical work was being developed overseas and deployed stateside. The reason was straightforward: cost. Offshore development was dramatically cheaper, and for a startup watching every dollar, the savings were impossible to ignore.
我们合作的印度工程师非常有才华。公司采用混合模式运营，在某些阶段，我们最关键的工作是在海外开发，然后在美国本土部署。原因很简单：成本。离岸开发的成本要低得多，对于一家精打细算的初创公司来说，这种节省是无法忽视的。
It was also the trend of the moment, Thomas Friedman had declared The World Is Flat and developers stateside were nervous. The question on everyone’s mind was whether their jobs were next.
这也是当时的潮流，托马斯·弗里德曼（Thomas Friedman）宣称“世界是平的”，美国本土的开发者们感到非常不安。每个人都在担心：下一个被取代的会是自己的工作吗？
The code being produced was good. The engineers were some of the most talented people I have worked with. But there were moments, inevitable in any distributed system of humans, where the understanding of why something was built a certain way lived on one side of the world and the responsibility for maintaining it lived on the other. The knowledge existed somewhere, it just wasn’t always where you needed it, when you needed it.
产出的代码质量很高。那些工程师是我共事过最有才华的人之一。但在任何人类分布式系统中，总会不可避免地出现这种情况：理解“为什么这样构建”的人在世界的一端，而负责维护它的人在另一端。知识确实存在于某处，只是它并不总是在你需要的时候出现在你需要的地方。
I’ve been thinking about Heartland lately, because the dynamic feels familiar. The cost of producing code has collapsed. AI tools can generate functional, adequate, perfectly average code at a speed and cost that would have been unimaginable even five years ago.
最近我一直在思考 Heartland 的经历，因为这种动态感觉非常熟悉。代码的生产成本已经崩塌。AI 工具能够以五年前无法想象的速度和成本，生成功能完备、合格且极其平庸的代码。
And like the outsourcing wave of the early 2000s, the economics are real and rational. Nobody is wrong for using these tools. The code they produce is often fine. It works. It passes tests. It might ship as-is. But we’ve seen this pattern before.
就像 21 世纪初的外包浪潮一样，这种经济逻辑是真实且合理的。使用这些工具并没有错。它们产出的代码通常没问题。它能运行，能通过测试，甚至可以直接发布。但我们以前见过这种模式。
When code production gets cheap, the cost doesn’t disappear. It migrates. It moves from creation to comprehension. This is the argument at the heart of Prediction Machines: when a fundamental input gets cheap, the value shifts to its complements. In software, the complement of production has always been understanding.
当代码生产变得廉价时，成本并没有消失，而是发生了转移。它从“创造”转移到了“理解”。这正是《预测机器》（Prediction Machines）一书的核心论点：当一种基础投入变得廉价时，价值就会转向其互补品。在软件领域，生产的互补品始终是“理解”。
The outsourcing era taught us that the expensive part of software was never writing it. It was understanding it well enough to change it safely, to debug it under pressure, to explain to the next person why a particular decision was made at 2 a.m. on a Tuesday.
外包时代教会我们，软件开发中最昂贵的部分从来不是编写代码，而是为了安全地修改代码、在压力下调试代码，以及向接手的人解释为什么在周二凌晨两点做出了某个特定决定，而必须具备的深刻理解。
The difference this time is structural. With outsourcing, the knowledge existed in someone’s head. A developer in Delhi or Bangalore understood the intent, even if transferring that understanding across time zones and organizational boundaries was hard. With AI-generated code, the knowledge may not exist anywhere. There is no human on the other end who once held the full picture. The code has been committed, syntactically correct but devoid of intent.
这一次的区别在于结构性。在外包时代，知识存在于某人的脑海中。德里或班加罗尔的开发者理解代码的意图，即使跨越时区和组织边界传递这种理解非常困难。而对于 AI 生成的代码，这种知识可能根本不存在于任何地方。另一端没有一个曾经掌握全貌的人。代码被提交了，语法正确，但却缺乏意图。
This is not an argument against AI-assisted development. I use these tools every day and they have made me genuinely faster. But productivity that is only measured by lines produced is a metric we rejected decades ago for good reason.
这并不是反对 AI 辅助开发。我每天都在使用这些工具，它们确实让我变得更快。但仅仅以代码行数来衡量生产力，是一个我们几十年前就因充分理由而摒弃的指标。
The outsourcing era eventually taught most organizations that the solution wasn’t to stop working with distributed teams. It was to invest deliberately in shared context, documentation, code review, and the slow work of building mutual understanding. The companies that thrived were the ones that treated comprehension as a first-class engineering concern, not a byproduct of proximity.
外包时代最终教会了大多数组织：解决方案不是停止与分布式团队合作，而是有意识地投入到共享背景、文档、代码审查以及建立相互理解的缓慢工作中去。那些蓬勃发展的公司，是将“理解”视为一流工程问题，而非地理邻近性的副产品的公司。
We need the equivalent investment now. If average code is cheap, then the scarce resource is no longer the ability to produce it. The scarce resource is the ability to read it, to navigate it, to know which parts matter and why.
我们现在需要同样的投入。如果平庸的代码很廉价，那么稀缺资源就不再是生产代码的能力。稀缺资源是阅读代码、驾驭代码、以及知道哪些部分重要及其原因的能力。
Joel Spolsky wrote over twenty-five years ago that “it’s harder to read code than to write it.” It was true then. It is unavoidably true now. We need tools built for understanding, not just producing. We need practices that treat understanding as something you build deliberately, not something you hope will emerge.
乔尔·斯波尔斯基（Joel Spolsky）在二十五年前就写道：“阅读代码比编写代码更难。”那时如此，现在更是不可避免地如此。我们需要为“理解”而构建的工具，而不仅仅是为“生产”而构建。我们需要将“理解”视为一种需要刻意构建的事物，而不是一种寄希望于自然产生的实践。
I think this is what developer tools should be solving for next. Not just helping us write code faster, but helping us understand the code we already have, the code we inherited, the code that arrived fully formed from a prediction machine that does not actually know or understand the world we live in. That is where the craft lives now.
我认为这就是开发者工具下一步应该解决的问题。不仅仅是帮助我们更快地写代码，而是帮助我们理解现有的代码、继承的代码，以及那些从一个并不真正了解或理解我们所处世界的预测机器中完整产出的代码。这才是现在“技艺”所在之处。