【CSDN 编者按】AI 写代码已经不稀奇了，写得又快又多的人也越来越多。但在“高效开发”的神话背后，代码评审越来越难做、协作越来越混乱、质量控制越来越吃力，才是团队真实的日常。为此，本文作者从“写代码从来不是瓶颈”这一观点出发，深入探讨了当前 LLM 对软件开发流程的实际影响。
真正的瓶颈是什么？是代码评审，是通过带教与结对编程传递知识，是测试与调试，是沟通与协作带来的“人类开销”……这些环节层层叠加，嵌套在一张张工单、一场场会议和一次次敏捷仪式的迷宫中。这些流程本意是为了提升开发质量，却往往比编写代码本身更耗费时间和精力，因为它们需要深思熟虑、共识理解和合理判断。
如今，随着大语言模型（LLM）能更快地生成可运行的代码，一种新的观点开始流行起来：编码曾是瓶颈，而我们终于攻克了它。
但事实并非如此：借助大语言模型，生成新代码的边际成本正在趋近于零——但理解、测试并信任这些代码的代价呢？你需要对此投入的时间和精力，可能比以往任何时候都要高。
像 Claude 这样的工具，确实能加速初始实现过程，但最终结果往往是：系统中流入了更多代码，给负责审查、集成和维护的人员带来更大压力。
最终我们会面临这样一个局面：代码更容易产出，但验证、理解和维护却更复杂，致使团队整体效率未必能因此提升。
这也不是什么新问题，毕竟“复制粘贴式开发”这个调侃，开发者们早已不陌生。只是大语言模型带来的生成速度和规模，进一步放大了这种复制粘贴的习惯。
大语言模型确实缩短了代码产出的时间，但要想真正理解其行为、排查细微 Bug、保证其长期可维护性，依然是一个高成本的智力任务。尤其当审查者难以判断哪些代码是 AI 写的、哪些是人写的，甚至连“为什么要这么实现”都无法理解时，维护难度只会进一步上升。
本质上来说，软件工程是一个高度协作的工作过程，依赖于共同的理解、目标一致性以及老带新的经验传承。但现在，当代码生成速度远超过讨论和审查速度时，团队可能会陷入一个误区：默认代码是“对的”，即“假设”质量达标，而不是认真验证以“确保”质量达标。
这种心态会给审查者和导师带来巨大压力，导致整体流程在看似“自动化”的表象下，其实更加脆弱和缓慢。
没错，大预言模型的确能显著提升原型开发、框架搭建和部分自动化流程的效率。但它无法替代清晰的思考、细致的审查和合理的架构设计。如果说有什么不同的话，只能说随着生成代码增多，这些能力变得更加重要。
没错，编码成本确实下降了；但作为一个团队，一起搞懂代码的成本，并没有变低——这才是我们真正的瓶颈，不要再自欺欺人了。
以上这篇文章在 HN 上引起了开发者们的高度关注和讨论，越来越多的一线工程师开始意识到，大模型正在放大软件工程中最难啃的那块骨头：理解、审查和协作。
一位资深开发者在评论区分享了自己的真实经历：他在带实习生的过程中发现，借助 LLM，他们的代码产出速度大幅提升，一天的量抵得上过去一两周。但表面效率提升背后，是一场认知负债的积累：
● 让修改也不是改原有的 PR，而是重新提交一个全新方案，结果又是新的复杂问题。
这并不是个例。另一位开发者也表达了类似的看法：虽然 LLM 可以加速代码生成，但真正耗时的是后续的代码清理、Bug 排查、安全审查、重构和优化——这些过程没法“自动化”，也没人愿意做。
此外，还有开发者从更高的视角指出：“写代码，早已不是稀缺技能了。”他提到，如今和几十年前不同，行业已经从“谁能写出系统”演进到“谁知道该做什么系统”了。当年比尔·盖茨能靠写代码吃饭，是因为那是当时最稀缺的能力；而现在，代码早已“过剩”，市场需求和判断力才是制胜关键。
这也再次印证了原文的观点：写代码的边际成本在下降，但“理解代码、协作构建”的边际成本反而在上升。所以，当我们在谈论 LLM 提升了“效率”时，不妨多问一句：它提升的是谁的效率？在哪个环节？代价又是什么？
大模型没错，它确实是很强大的工具，但任何工具都只是放大器 —— 它放大的可能是你的能力，但也可能会放大你的短板。
互联网大厂、AI 创业公司、ToB/ToC 实战一线 大专题分享，洞察趋势、拆解路径、对话未来。
