AI时代，对软件开发未来的思考
大型语言模型（LLMs）在创意界引起了巨大的轰动，因为它们能够生成图像、文本和代码。最初，结果非常搞笑，画的是手乱的人，产生了错误的事实和代码的幻觉。但事情正在缓慢而稳步地好转。在这些模型出现之前，反对自动化这些任务的主要论点是机器不能创造性地思考。现在这个论点一天比一天弱。我们该何去何从？
试图思考一些模糊的问题，比如预测未来，其缺点是你的想法会变得混乱，很难清晰地思考。因此，我们需要提出框架和类比供我们依靠。
框架：软件开发能力水平
软件开发不仅仅是编写代码。人们对程序员的印象是一个人坐在黑暗的房间里看着电脑，疯狂地输入代码。虽然整天编码听起来很有吸引力，但大部分软件开发时间都花在了与其他人沟通或其他管理工作上，而不仅仅是编写代码：
- 收集业务用户的需求
- 优化这些需求，以便将它们建模为代码
- 与设计师和产品经理等其他团队成员交谈，以可视化解决方案并提出攻击计划
- 与其他开发人员合作提出技术设计并对其进行改进
- 设置基础架构、配置、样板等。
- 实际编写一些代码
- 调试、尝试理解其他人的代码、编写文档等。
- 部署到生产环境
- 消防生产问题
- ...还有更多任务
因此，说“人工智能将取代开发人员”这样的话需要“人工智能”能够胜任上述所有任务，而不仅仅是编写代码。
因此，说“人工智能将取代开发人员”这样的话需要“人工智能”能够胜任上述所有任务，而不仅仅是编写代码。
但是从上面的列表来看，其中一些任务似乎将来也可以自动化，但目前还不能。我们如何构建这个想法？
自动驾驶汽车的世界提出了一种对自动化水平进行分类的方法。它具有离散的级别，从无自动化到部分自动化再到完全自动化。我发现这非常有用，原因有很多：
- 它清楚地描述了当前技术的能力
- 它阻止了我们非黑即白地思考——这不是关于人类司机与人工智能司机的竞争，人工智能完全取代了人类司机，有可能存在灰色地带，人类司机在紧急制动、车道居中等方面得到人工智能的协助。
这种分类对人工智能驱动的软件开发来说是什么样子的？
- 最低层将是我们以前拥有的 - 没有人工智能参与工作。当然，我们还有其他类型的自动化，如编译器、构建过程等，但这些不是人工智能，这些是人类编写的确定性自动化。
- 下一个层次就是我们现在所拥有的——开发人员使用 ChatGPT 或 GitHub Copilot 来帮助他们。他们用它来编写测试、样板代码、重构、理解代码/错误等。这就像通过聊天与其他开发人员交谈，您可以提出问题并从中获得一些帮助，但他们无法访问您的计算机，因此他们无法创建文件、运行生成命令或部署到生产环境。
- 最高级别就像将项目的一部分或整个项目委托给开发人员。这些“人工智能编码员”将接受需求，编写代码，修复错误并将最终产品部署到生产环境中。我以为距离这种情况发生还有几个月的时间，但 Devin 演示被证明是错误的——尽管它现在只能执行简单的开发任务，但将来有可能有所改进。
除了人工智能模型的能力之外，我们还应该考虑解决方案的准确性。最初，这些模型容易产生幻觉，或者您需要以特定方式提示它们以获得您想要的东西。这增加了采用的摩擦，大多数人在这一点上放弃了人工智能助手。但这也在改进，较新的模型不需要那种程度的提示工程。此外，模型应该能够通过浏览网页来“学习”，而不是依赖它们的训练数据。随着新版本的库和编程语言的引入，这一点很重要。
框架：外包软件开发
现在我们已经建立了能力，这些能力将如何影响团队或组织结构？公司以多种方式进行软件开发：
- 完全内部
- 主要是内部的，供应商很少
- 主要是内部很少的供应商
- 完全供应商
在某种程度上，我们可以将 AI 编码人员视为外包软件供应商/顾问。有些公司经常使用它们，有些则不经常使用。无论组成如何，我相信让内部团队监督他们的工作总是很重要的。这是为了确保供应商的输出与组织的长期目标保持一致。当然，你可以通过合同来解决这个问题，但它们通常只适用于特定的供应商或项目，你不能使用这种方法强制执行长期目标。最好至少有一个小型的内部团队来指导供应商。同样，即使 AI 编码员可以像 EC2 实例一样出租，拥有一个内部软件开发人员团队来监督他们的工作也是有益的。
框架：软件开发正在对复杂性进行建模
如果我们谈论的是解决业务问题，让我们花点时间谈谈房间里的大象 - Excel。众所周知，全世界都在 Excel 上运行，超过 10 亿人使用它。它为想要组织数据、执行数据分析或自动化某些流程的业务用户提供了非常低的进入门槛。但是，我们不能将 Excel 用于复杂的业务工作流，因为它没有精细访问控制、与不受支持的系统集成的能力、可测试性、可重用性或仅供应商锁定等功能。对于Power Automate等“低代码”解决方案也是如此。
回到最初的问题，业务用户是否能够在没有软件开发人员帮助的情况下使用 AI 编码人员创建这些复杂的工作流程？
在没有软件开发人员帮助的情况下，业务用户是否能够使用 AI 编码工具创建这些复杂的工作流程？
如果你仔细想想，Excel和低代码工具已经存在了几十年，那么为什么软件开发这个职业仍然存在呢？它可以追溯到将软件开发视为编写代码。对于复杂的问题，我们需要能够有效管理这些复杂性并将业务问题从现实世界领域转化为数字模型的人。
换句话说，如果你能够在没有土木工程师帮助的情况下从YouTube教程中建造一个木棚，并不意味着你可以/应该为10层的建筑做同样的事情。如果你去学习如何正确地做到这一点，那么你就会慢慢成为一名土木工程师！这只是一个问题，你是否愿意花时间正确地学习这个，或者聘请一个有经验的工程师为你做这件事。
因此，无论这些人使用的是 Excel 还是最新的 AI 编码器，如果他们正在对复杂的逻辑进行建模，在我看来，他们仍然是软件开发人员！他们只是使用不同的工具来表达业务需求 - 电子表格公式、代码和提示。
框架：馅饼的大小
围绕这个话题的大多数焦虑都假设软件开发市场的规模保持不变——人工智能程序员将慢慢从人类手中夺走“市场份额”。
从上一节中，我们知道“解决业务问题”的市场规模远比软件开发大得多。因此，没有理由相信软件开发会很快消失。
框架：正式业务逻辑定义
业务逻辑必须始终以明确的格式定义。这就是为什么编程语言，即使它们使用“if”、“switch”等英语单词，也非常讲究这些单词的含义，如果你用错了单词，它们将不起作用。如果您考虑一下，Excel 公式或低代码流也是如此。
将来，即使人工智能程序员可以从会话英语中给出的指令中生成软件产品，我相信后端生成的业务逻辑仍然会有一个潜在的正式定义。它可能看起来与我们今天使用的语言和框架有很大不同，但业务逻辑的正式定义听起来很像“代码”。
在人工智能编码人员能够开始以确定性的方式从会话英语中生成这些业务逻辑之前，仍然需要能够理解它在后端生成的代码并在必要时进行更改的人。这些人将是软件开发人员。
结论
总而言之，我相信在可预见的未来，软件开发人员仍然会有一个市场，尽管工作的性质会发生变化，我们将使用的工具可能与我们现在拥有的工具大不相同。