这是一个在网络上已经被广泛讨论的话题，现在再谈多少有些“过时”。但基于最近一段时间使用大模型进行实际开发的体验，还是想表达一些更贴近一线实践的看法。

                先说结论： 从“编码执行”的角度看，AI已经具备承担大部分开发工作的能力。虽然仍有不足，但在很多场景下，确实可以显著减少对程序员的依赖了。

• 在编码层，AI已经非常强大，几乎可以胜任各阶段程序员的能力

• 在工程层（调试、依赖、上下文管理），仍然不稳定

• 在架构层（系统设计、权衡决策），仍高度依赖人

那些仍需要程序员参与的工作，一部分来自模型本身的能力边界，另一部分则来自使用方式。

        LLM本质上是一个概率模型，这一点在实际使用中体现得非常明显。上下文的微小变化，往往会导致生成结果产生较大差异。

        最近，笔者使用大模型开发了一个解析 Wireshark 显示过滤语法的模块。第一次尝试时，并没有抱太大期望，但结果相当惊艳：模型基于 ANTLR 语法规则，在大约两个小时内就生成了一个可用的语法解析引擎。这个工作如果完全由人工完成，大约需要3～4天时间。

        但问题随着一次误操作而出现。由于代码非手工编写，印象不深，不经意将其删除了。不得不重新编写该功能。这一次，大模型努力完成任务，但始终无法达到第一次的效果。期间多次因为上下文长度限制而中断，不得不重新组织指令。最终，还是需要人工介入，对关键部分进行调整，问题才得以解决。

        两次编程体验有很大的差异。本质上这并不是“模型突然变弱”了，更可能是上下文变化引起的。第二次应用时，上下文可能不如第一次完整，后续追加的约束可能又进一步限制了模型的生成空间。但凭借记忆给出完全相同的上下文，现实中我们很难做到。所以这种情况出现的可能性非常大。在这里我们可以看到：

LLM更像是一个“高效的一次性问题求解器”，而不是一个“稳定可复现的软件生产系统”。

        除了使用方式之外，不同模型和工具之间的差异也非常明显，选择合适的组合本身就是一项工程能力。在实际使用中，还会遇到一些必须由程序员介入的问题，例如：

• 依赖版本与代码不匹配

• 生成代码质量不稳定，甚至形成“低质量代码堆积”

• 上下文膨胀带来的token消耗与维护成本问题

这些问题在短期Demo中不明显，但在长期系统演进中会被迅速放大。

        进一步说，软件开发的核心从来不只是“写代码”，而是“构建系统”。软件设计才是灵魂。

        AI能否给出好的设计？能否替代包括架构师在内的全部程序员？这个问题值得单独讨论。但至少可以明确一点：

“只懂业务就能开发软件”在当前阶段仍然不成立。

        因为软件开发不仅包含功能性需求，还包含大量非功能性需求，例如性能、可扩展性、安全性、可维护性等。这些内容涉及一定的计算机基础知识。虽然不一定难，但使用者必须能够清晰地表达这些约束，AI才能更好地发挥作用。

        从更宏观的角度看，软件开发从“手工生产”走向“自动化生产”是一个不可逆的趋势。AI对程序员的影响，某种程度上确实类似于工业革命中机器对工人的替代。

        但历史经验也表明，被替代的往往是“工作方式”，而不是“人本身”。

        对于程序员而言，与其焦虑被替代，不如主动调整角色：从单纯的代码生产者，转变为能够驾驭AI的工程组织者。借助AI能力，以产品或服务的形式为各行业提供支持，从而在新的技术范式下继续创造价值。