译：写代码从来都不是瓶颈
原文： https://ordep.dev/posts/writing-code-was-never-the-bottleneck
作者： ordep.dev
译者： Gemini 2.5 Pro
For years, I’ve felt that writing lines of code was never the bottleneck in software engineering.
多年来，我一直觉得在软件工程中，写代码本身从来都不是瓶颈。
The actual bottlenecks were, and still are, code reviews, knowledge transfer through mentoring and pairing, testing, debugging, and the human overhead of coordination and communication. All of this wrapped inside the labyrinth of tickets, planning meetings, and agile rituals.
真正的瓶颈过去是，现在依然是：Code Review、通过指导和结对编程进行的知识传递、测试、调试，以及协调和沟通这些人力开销。所有这些，又被包裹在工单、计划会议和敏捷仪式组成的迷宫里。
These processes, meant to drive quality, often slow us down more than the act of writing code itself because they require thought, shared understanding, and sound judgment.
这些流程本意是为了提升质量，但它们往往比写代码本身更拖慢我们的脚步，因为它们需要深思熟虑、共识和可靠的判断。
Now, with LLMs making it easy to generate working code faster than ever, a new narrative has emerged: that writing code was the bottleneck, and we’ve finally cracked it.
现在，LLM 让我们能以前所未有的速度生成可用代码，一种新的说法随之出现：写代码曾经是瓶颈，而我们终于解决了它。
But that’s not quite right.
但这并不完全正确。
The marginal cost of adding new software is approaching zero, especially with LLMs. But what is the price of understanding, testing, and trusting that code? Higher than ever.
增加新软件的边际成本正在趋近于零，尤其是在 LLM 的帮助下。但是，理解、测试和信任这些代码的代价是什么？前所未有地高。
LLM 转移了工作，但并未消除工作
Tools like Claude can speed up initial implementation. Still, the result is often more code flowing through systems and more pressure on the people responsible for reviewing, integrating, and maintaining it.
像 Claude 这样的工具可以加快初始开发速度。然而，结果往往是更多的代码涌入系统，给那些负责审查、集成和维护它的人带来了更大的压力。
This becomes especially clear when:
当出现以下情况时，这一点尤其明显：
- It’s unclear whether the author fully understands what they submitted.
- The generated code introduces unfamiliar patterns or breaks established conventions.
- Edge cases and unintended side effects aren’t obvious.
- 提交者是否完全理解自己提交的代码，这一点并不清楚。
- 生成的代码引入了不熟悉的模式或破坏了既定规范。
- 边缘情况和意想不到的副作用并不明显。
We end up in a situation where code is more straightforward to produce but more complex to verify, which doesn’t necessarily make teams move faster overall.
我们最终会陷入这样一种境地：代码的生产变得更简单，但验证却变得更复杂，这未必能让团队的整体速度变得更快。
It’s not a new challenge. Developers have long joked about “copy-paste engineering”, but the velocity and scale that LLMs enable have amplified those copy-paste habits.
这不是什么新挑战。开发者们早就拿 “复制粘贴工程” 开玩笑了，但 LLM 带来的速度和规模放大了这种复制粘贴的习惯。
理解代码，仍然是难点所在
“The biggest cost of code is understanding it — not writing it.”
“代码最大的成本是理解它——而不是写它。”
LLMs reduce the time it takes to produce code, but they haven’t changed the amount of effort required to reason about behavior, identify subtle bugs, or ensure long-term maintainability. That work can be even more challenging when reviewers struggle to distinguish between generated and handwritten code or understand why a particular solution was chosen.
LLM 减少了产出代码的时间，但并没有改变我们为推断其行为、识别潜在 bug 或确保长期可维护性所需付出的精力。当审查者难以区分生成的代码和手写的代码，或者不理解为何选择某个特定方案时，这项工作甚至会变得更具挑战性。
团队依然依赖信任和共享的上下文
Software engineering has always been collaborative. It depends on shared understanding, alignment, and mentoring. However, when code is generated faster than it can be discussed or reviewed, teams risk falling into a mode where quality is assumed rather than ensured. That creates stress on reviewers and mentors, potentially slowing things down in more subtle ways.
软件工程向来是协作性的。它依赖于共识、目标一致和指导。然而，当代码生成的速度超过了讨论或审查的速度时，团队就可能陷入一种 “质量靠假设而非保证” 的模式。这给审查者和导师带来了压力，并可能以更不易察觉的方式拖慢整个进度。
LLM 很强大——但它们解决不了根本问题
There’s real value in faster prototyping, scaffolding, and automation. But LLMs don’t remove the need for clear thinking, careful review, and thoughtful design. If anything, those become even more important as more code gets generated.
在快速原型、脚手架和自动化方面，LLM 确实有其价值。但它们并没有消除对清晰思考、仔细审查和周全设计的需求。如果说有什么不同，那就是随着代码量的激增，这些需求变得愈发重要。
Yes, the cost of writing code has indeed dropped. But the cost of making sense of it together as a team hasn’t.
是的，写代码的成本确实下降了。但是，作为一个团队去理解代码的成本却没有。
That’s still the bottleneck. Let’s not pretend it isn’t.
这仍然是瓶颈。我们别再假装它不是了。