“编码已解决”没有抓住要点

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