每隔几周，就会有人宣称编码已经解决。如果他们的意思是将一个清晰规范的问题转化为可运行的代码，他们的说法越来越正确。但写出可运行的代码是否曾经是整个问题？语言模型在软件工程中的解决程度就像文字处理软件在新闻报道中的解决程度一样：它们使得产生输出变得更容易。让你去构建一个 REST API 或实现一个 React 组件，过去需要几个小时的工作现在只需几分钟。非常显著。但是组织需要一个更难的问题的答案。人工智能能解决他们实际上存在的问题吗？演示应用是缩小版的初创公司 说服自己编码已经解决的最简单方法是构建一个演示应用，比如待办事项列表、天气应用或个人仪表板。需求很明确，几乎没有任何限制，你可以自由地不断发明架构。在一片空白画布上构建。现在将其与一个成熟的组织进行比较。这项任务听起来可能是增加一个按钮，但在你写下第一行代码之前，你需要回答：哪个服务拥有这一功能？我们是否应该使用现有的 API？为什么之前没有实现这一点？哪些安全要求适用？哪些架构模式是可以接受的？哪个团队负责这一领域？这将如何影响下游系统？我们在优化哪些业务约束？这些问题中，有多少是关于写代码的？非常少。大多数问题都需要你理解组织。这就是为什么在周末项目中感到神奇的同一个模型在企业内部可能仅仅是有帮助的。尽管编程问题是相似的，但环境使其变得更加困难。我们误把瓶颈当作学科 几十年来，编写代码是软件开发中最昂贵的部分之一，因此我们开始将软件工程等同于实现。人工智能正在大幅降低实现的成本，并将瓶颈转移到其他地方。自动化改变了稀缺性的定义。随着实现变得丰富，我们的注意力转向下一个抽象层。软件工程一直涉及几个层次：每个层次回答一个不同的问题：商业目标：我们要解决什么问题？产品设计：用户应该如何体验解决方案？解决方案设计：系统应该如何实现这种体验？实现：我们如何将其用代码表达？今天的模型在最底层变得异常出色。其余的栈仍然存在。我们终于注意到有多少工作坐落在实现之上。组织以上下文为运行基础 一个将爱好项目与企业软件区分开来的因素是上下文。更具体地说，是组织上下文。组织已经熟悉其架构和领域语言。它有历史决策、工程惯例、所有权边界、安全要求和业务优先级。多年构建软件也产生了无数没有被记录下来的假设。这种上下文影响着每一个步骤。战略和监管塑造商业决策。客户期望和既定用户体验模式塑造产品决策。现有的平台和服务限制了解决方案设计。编码标准、框架和部署管道指导实现。初创公司在成长过程中创建这种上下文。企业则继承数十年的上下文。让语言模型构建一个全新的应用与让它扩展一个十年的生产系统是根本不同的。困难的部分是在现有环境中做出明智的决策。人工智能正在攀登抽象楼梯 每一代开发工具自动化都会软件工程最具体的层次。编译器自动化了机器代码。更高级的语言自动化了低级编程。框架自动化了基础设施。现在语言模型正在自动化实现。每一次突破都感觉像是革命性的，直到下一个层次成为瓶颈。今天正发生着这样的事情。人工智能在生成代码方面做得越好，我们的谈话就越倾向于理解商业问题和设计正确的体验。我们在将解决方案融入现有系统和在组织约束内做出明智决策方面花费了更多的时间。代码始终是媒介人工智能可以编写代码。错误在于假设编写代码曾经是整个工作。组织雇佣工程师以解决商业问题。代码是媒介，而不是结果。那么，编码解决了吗？如果你的意思是将清晰的规范翻译成可工作的软件，我们正越来越接近。软件工程涵盖了整个栈。每一代工具将一个层次做得更便宜，并揭示下一个。人工智能正在揭示软件工程一直以来的本质。