编程尚未被AI解决：为何写代码只是软件工程冰山一角

一个流行论调背后的误区

随着大语言模型在代码生成上的表现越来越亮眼，"编程已经被解决"（Coding Is Solved）的论调在技术社区甚至投资圈广为流传。开发者 Alex Ewerlöf 在其博客文章《Coding Is Not Solved》中对这一观点提出了直接反驳，文章在 Hacker News 上获得 215 分、超过 200 条评论的热烈讨论，触及了当下软件行业最敏感的神经。

作者的核心论点并不复杂：把"写代码"等同于"软件工程"，本身就是一个范畴错误。AI 确实能快速生成可运行的代码片段，但代码只是整个软件生命周期中最表层、也最容易被自动化的部分。真正困难的工作发生在代码之外——理解模糊的需求、在相互冲突的约束之间做权衡、维护系统的长期可演进性。

写代码不等于软件工程

作者强调，编程作为一项职业活动，远不止敲键盘输出语法正确的函数。软件工程更像是一个持续决策的过程：需求往往是不完整、甚至自相矛盾的，工程师需要在客户表述背后挖掘真实意图；系统架构涉及性能、成本、安全、可维护性之间的取舍，而这些取舍没有标准答案。

当一个模型生成了一段能通过测试的代码，它解决的只是"如何实现"这个已经被明确定义的子问题。而在现实项目中，"应该实现什么"以及"为什么这样实现"往往消耗了工程师大部分的精力。这些判断依赖对业务上下文、历史包袱和团队协作的深刻理解——这恰恰是当前生成式 AI 最薄弱的环节。

上下文与意图的鸿沟

AI 生成代码的质量高度依赖于提示词所提供的上下文。但在真实的大型代码库中，隐性知识、组织约定和历史决策难以被完整地喂给模型。一个看似合理的代码建议，可能因为忽略了某个边界条件或团队规范而埋下隐患。这种"看似正确"的输出，反而增加了人类审查的认知负担。

这一现象在软件工程领域有时被称为"暗知识"（tacit knowledge）问题——系统中大量的设计决策从未被文档化，只存在于开发团队的集体记忆中：为什么某个接口被设计成这样、为什么某段代码刻意回避了某种优化、某个字段名背后对应的是哪次业务变更。这类知识无法通过阅读代码本身获得，更无法被结构化地传递给语言模型。研究者将此称为"上下文窗口之外的世界"——即便模型的上下文窗口已扩展到数十万 token，它依然无法容纳一个中等规模代码库所承载的完整历史与组织语境。这也解释了为何 AI 在绿地项目（greenfield project，即从零开始的新项目）上表现远优于遗留系统维护：前者几乎没有隐性约束，后者则充满了只有"老人"才知道的地雷。

维护成本才是软件的真实重心

软件行业早有共识：代码被阅读和修改的次数远多于被编写的次数。文章指出，一段代码从写完的那一刻起就进入了漫长的维护期——修复缺陷、适应新需求、重构以应对规模增长。这些工作要求对既有系统有整体性的把握，而不是孤立地生成新片段。

当 AI 大量产出代码时，如果缺乏对整体架构的约束，很可能带来技术债务的加速累积。生成得越快，需要人类理解和维护的代码就越多。换句话说，AI 提升了代码产出的速度，却未必降低了软件工程的整体复杂度，甚至可能把复杂度转移到了更难处理的审查与维护阶段。

技术债务（technical debt）这一概念由软件工程先驱 Ward Cunningham 于 1992 年提出，用于描述为追求短期交付速度而做出的设计妥协——这些妥协会像债务一样累积利息，最终以更高的维护成本偿还。AI 辅助编程在技术债务维度上引入了一个新的风险结构：传统技术债务至少是由理解系统的人类工程师主动决策产生的，而 AI 生成的代码所带来的债务可能更隐蔽——生成者（模型）对系统全局架构并无真正的理解，审查者（人类）又面临代码量激增的压力，两者叠加可能导致债务在被识别之前已大规模扩散。部分团队因此开始在 AI 辅助开发流程中引入强制性的架构审查门控，将"AI 可生成"与"可合并入主干"明确区分为两个不同的质量标准。

社区讨论中的分歧

这篇文章之所以引发广泛共鸣，是因为它触及了从业者对"AI 替代程序员"叙事的普遍焦虑与反思。在 Hacker News 的讨论中，支持者认为作者精准指出了"编程"与"工程"的概念混淆，这种混淆常被用来夸大 AI 的能力边界。

也有不同声音提醒，不应因此低估 AI 工具带来的生产力提升。对于原型开发、样板代码、脚本编写等定义明确的任务，AI 确实显著提高了效率。分歧的核心并不在于 AI 是否有用，而在于"有用"是否等同于"解决"。工具能加速局部环节，与整个学科被攻克，是两件不同量级的事。

对开发者的现实启示

对于一线开发者而言，这场讨论的价值在于重新校准对自身工作的认知。如果把职业价值仅仅锚定在"写出代码"上，那么面对 AI 确实会感到威胁；但如果认识到工程师的核心竞争力在于问题定义、系统设计和长期决策，AI 更应被视为放大能力的工具，而非替代者。

• 把 AI 当作加速器，用于处理明确、重复的编码任务，把精力留给需求分析与架构权衡。
• 对 AI 生成的代码保持审查意识，尤其关注它是否符合系统的隐性约束。
• 持续投资于难以被自动化的能力：业务理解、抽象设计、跨团队沟通。

软件工程作为一门学科，其难点从来不在语法层面。"编程尚未被解决"这个判断，与其说是对 AI 能力的否定，不如说是对软件工程本质的一次澄清：真正的复杂性，藏在代码之外。