很多人以为，程序员最费劲的工作就是敲代码。但在我的经验中，写代码本身从来都不是软件工程的真正瓶颈。

真正让开发进度一拖再拖的，是一系列围绕代码展开的工作：代码评审、知识同步（尤其是在带新人和协作开发时）、全面的测试流程、定位问题的调试过程，以及在各部门之间沟通协调所花费的大量精力和时间。而这一切，常常被密密麻麻的用户需求、项目排期和敏捷管理流程进一步放大。

这些流程的初衷当然是为了提升软件质量，但在实际工作中，它们往往增加了认知负担和决策难度，使得整个开发链条变得臃肿而低效。写出功能代码的那一刻，反而成了最轻松的部分。

现在，随着大语言模型（LLM）让写出可运行的代码变得前所未有的简单，坊间突然冒出一种说法：写代码才是原来的瓶颈，而现在我们终于突破了它。

但这话——其实不对。

写新代码的“边际成本”确实在急剧下降，尤其是在 AI 的加持下。但问题是，理解、测试、信任这段代码的代价，却变得更高了。

AI 并没有减少工作量，只是把负担转移了

像 GPT、Claude 这样的工具，确实在项目启动阶段提供了极大的便利。缩短了从想法到初稿的距离。但随之而来的问题也显而易见：系统里流动的代码更多了，而负责评审、集成和维护的人压力也更大了。

我们经常会遇到这样的情况：

• 很难判断开发者是否真正理解了自动生成的那段逻辑；

• AI 输出的代码风格与团队现有规范不一致，导致融合困难；

• 一些边界情况或隐藏的副作用难以一眼看出。

表面上，开发工作变得“更快”了，但在底层逻辑验证和团队协同层面，复杂度反而上升。效率提升的是局部，拖慢的却是全局。

这是一个“负担转移”的过程。AI确实降低了初期开发门槛，但却把后期的理解、验证、评估、维护等任务的难度无声地放大了。

其实这也不新鲜。开发者早就调侃“复制粘贴工程师”这种现象。只不过，有了 LLM，这种“复制粘贴”的习惯被放大了，速度更快、数量更多。

真正难搞的，始终是“理解与维护”

代码的成本不在于写，而在于理解和传承。

即便是由最先进的模型生成的代码段，也依然需要人类开发者去理解它的意图、分析它的逻辑、判断它的副作用、排查 BUG——尤其是当它需要融入到一个庞大系统中时。开发者不仅要搞清楚“这段代码干了什么”，还要弄明白“为什么要这么干”。

有时候，代码审查会陷入“这是人写的还是 AI 写的？”的尴尬判断中，更别提解释这段代码是否符合业务意图、是否能长期演化。

引申一句：“系统的复杂性，往往不是由技术的难度决定的，而是由理解它的人数决定的。”只要有一个团队成员读不懂这段代码，那它的维护成本就已经变高了。

做技术，始终离不开信任和上下文

软件开发从来都不只是一个人对着电脑冥思苦想的孤独旅程，它更像是一场多人协作的长跑。共识、协同、责任感和信任，才是团队运转的底层逻辑。

但如果生成代码的速度远超评审与讨论的速度，就很容易形成一种“默认代码没问题”的惯性思维，久而久之，质量控制从“明确确认”变成了“潜在假设”。团队变得依赖运气而不是机制，这无异于在为未来埋雷。

尤其是在多团队、多人协同的复杂项目中，盲目的快并不会带来持续的产出，只会让维护成本爆炸式增长。

AI 是助力，但不是银弹

快速搭建原型、生成模板、自动化一些重复劳动，这些确实是 LLM 的优势。但无论技术怎么发展，清晰的思考、认真的审查、合理的设计永远都不会被替代。甚至，恰恰因为生成的代码变多了，这些工作才显得更重要。

是的，写代码的成本的确降低了。但要把这些代码“搞明白”，让一个团队一起理解它、维护它，这个成本——没降。

这才是当下真正的瓶颈。

别装作它不存在。