简介
软件开发者 Shesh 这个对软件开发未来的思考有点意思，描述了一下为什么他认为 AI 不会取代“软件开发人员”。
他认为：
软件开发的核心在于管理复杂性，将业务问题从现实世界转化为数字模型。尽管Excel和低代码工具为业务用户提供了低门槛的数据组织、数据分析和流程自动化手段，但它们无法处理复杂的业务工作流程。
业务逻辑必须以明确无误的格式定义，这是编程语言、Excel公式或低代码流程的共同特点。即使未来的AI编码者能够根据对话英语指令生成软件产品，后台仍然需要一个正式的业务逻辑定义，这在本质上类似于“代码”。
即使AI编码者能够从对话英语中生成业务逻辑，仍然需要人们理解后台生成的代码，并在必要时进行修改。因此，直到AI编码者能够以确定性的方式生成这些业务逻辑，软件开发者的需求仍将存在。
正文
大语言模型 (LLMs) 在创意领域引起了轰动，因为它们能够生成图像、文本和代码。一开始，这些生成的内容常常让人啼笑皆非，比如那些手部结构怪异的人物画像，以及一些错误的事实和代码。但随着时间的推移，这些模型的表现正在稳步提升。在这些模型出现之前，人们普遍认为机器无法进行创造性思考，因此反对自动化这些任务。然而，这种观点正逐渐削弱。我们未来的路在何方？
在尝试预测未来这样的模糊问题时，我们的思路往往会变得混乱，难以清晰。因此，我们需要构建一些框架和类比，以便有所依据。
软件开发能力级别
软件开发并不仅仅是编写代码。人们通常认为程序员就是在昏暗的房间里，盯着电脑屏幕，不停地敲击键盘。虽然整天编程听起来很有吸引力，但实际上，软件开发的大部分时间都花在了与人沟通或其他行政事务上，而非纯粹的编程：
- 向业务用户收集需求
- 细化这些需求，使其能够转化为代码模型
- 与设计师和产品经理等团队成员讨论，以形象化解决方案并制定实施计划
- 与其他开发人员合作，制定并完善技术设计方案
- 搭建基础设施、配置环境、准备模板等
- 编写代码
- 调试程序，理解他人的代码，编写文档等
- 将软件部署到生产环境
- 解决生产环境中的问题
- ……还有许多其他任务
因此，如果说“AI将取代软件开发人员”，那么就意味着“AI”必须能够在上述所有任务中胜任，而不仅仅是编写代码。
因此，如果说“AI将取代软件开发人员”，那么就意味着“AI”必须能够在上述所有任务中胜任，而不仅仅是编写代码。
但从上面的列表来看，似乎这些任务中的一些将来也有可能实现自动化，尽管目前还没有。我们应该如何构建这个概念？
自动驾驶汽车领域已经提出了一种自动化水平分类的方法。它设定了从无自动化到部分自动化，再到完全自动化的明确等级。我觉得这种方法非常有用，原因有很多：
- 它清晰地描述了当前技术所能实现的功能
- 它避免了我们陷入非黑即白的思考模式——并不是说AI驾驶员将完全取代人类驾驶员，而是可能存在灰色地带，比如在紧急制动、车道保持等功能上，人类驾驶员可以得到AI的辅助。
那么，这种分类在AI驱动的软件开发中又是如何呢？
- 最低等级就是我们之前的状态——工作中没有AI的参与。当然，我们有其他类型的自动化工具，比如编译器、构建流程等，但这些并不是AI，而是人类编写的确定性自动化工具。
- 接下来是我们目前所处的阶段——开发人员使用ChatGPT或GitHub Copilot等工具来辅助工作。他们用这些工具来编写测试、生成模板代码、进行重构、理解代码错误等。这就像是和一个能通过聊天提供帮助的开发人员交流，但他们无法访问你的计算机，所以不能创建文件、执行构建命令或将软件部署到生产环境。
- 最高等级则像是将项目的一部分或全部委托给一个开发人员。这些“AI编程师”将根据需求编写代码，修复错误，并将最终产品部署到生产环境。我原本以为这还需要很多个月才能实现，但Devin演示证明了我错了——尽管目前它只能完成一些简单的开发任务，但未来有可能得到改进。
除了AI模型本身的能力，我们还应该考虑解决方案的准确性。最初，这些模型容易出现幻觉，或者需要以特定方式引导它们才能得到想要的结果。这增加了人们采用AI助手的难度，大多数人在这个阶段就会放弃。但这种情况也在改善，新模型不再需要那么复杂的引导。此外，模型应该能够通过浏览网络来“学习”，而不是仅仅依赖于训练数据。这一点非常重要，因为随着库和编程语言版本的更新，这一点变得尤为重要。
外包软件开发
现在我们已经了解了AI的能力，那么这些将如何影响团队或组织结构呢？公司以多种方式进行软件开发：
- 完全内部开发
- 主要内部开发，辅以少数外部供应商
- 主要依赖外部供应商，辅以少数内部开发
- 完全依赖外部供应商
从某种意义上说，我们可以将AI编程师视为外包的软件供应商或顾问。有些公司大量使用它们，有些则较少。无论团队组成如何，我认为始终需要一个内部团队来监督这些外包工作。这是为了确保外包供应商的产出与组织的长期目标保持一致。当然，你也可以通过合同来解决这个问题，但合同通常只适用于特定的供应商或项目，无法用来执行长期目标。因此，最好至少有一个小型的内部团队来指导供应商。同样，即使AI编程师可以像EC2实例那样租用，拥有一个内部的软件开发团队来监督他们的工作也是非常有益的。
软件开发是建模复杂性
如果我们在讨论解决业务问题，那么让我们来谈谈一个不容忽视的话题——Excel。众所周知，Excel是全球运行的重要工具，超过10亿人 使用它。它为那些希望组织数据、进行数据分析或自动化某些流程的业务用户提供了极低的门槛。然而，Excel并不适用于处理复杂的业务流程，因为它缺乏细粒度的访问控制、与不支持的系统集成的能力、可测试性、可重用性或供应商锁定等特性。同样的情况也适用于“低代码”解决方案，如Power Automate等。
回到最初的问题，业务用户能否在没有软件开发人员的帮助下，使用AI编程工具来创建这些复杂的工作流程？
业务用户能否在没有软件开发人员的帮助下，使用AI编程工具来创建这些复杂的工作流程？
如果你仔细思考，Excel和低代码工具已经存在了几十年，那么为什么软件开发这个职业仍然存在？这归根结底是因为软件开发不仅仅是编写代码。对于复杂的问题，我们需要那些能够有效管理复杂性并将业务问题转化为数字模型的人。
换句话说，如果你能够通过YouTube教程在没有土木工程师的帮助下建造一个木制棚屋，并不意味着你可以或应该在没有土木工程师的帮助下建造一个十层的大楼。如果你愿意投入时间来正确学习如何做到这一点，那么你最终会成为一名土木工程师！这实际上取决于你是否愿意投入时间来正确学习，或者雇佣一位经验丰富的工程师来为你完成这项工作。
所以，无论这些人是使用Excel还是最新的AI编程工具，如果他们正在处理复杂的逻辑建模，那么在我看来，他们仍然是
软件开发人员！他们只是使用不同的工具来表达业务需求——无论是电子表格公式、代码还是指令。
蛋糕的大小
围绕这个话题的大部分焦虑都基于一个假设，即软件开发市场的规模保持不变——AI编程工具将逐渐从人类手中夺走市场份额。
从前面的部分我们知道，“解决业务问题”的市场规模远远大于单纯的软件开发。因此，没有理由认为软件开发会很快消失。
正式业务逻辑定义
业务逻辑必须以一种明确无误的格式来定义。这就是为什么编程语言，尽管它们使用像“if”、“switch”这样的英文单词，但对这些单词的含义有严格的规定，如果使用不当，程序就不会运行。Excel公式或低代码流程也是如此。
在未来，即使AI编程工具能够根据用日常英语给出的指令生成软件产品，我相信在后端生成的业务逻辑仍然需要一个正式的定义。它可能与我们今天使用的语言和框架大不相同，但正式的业务逻辑定义听起来很像“代码”。
在AI编程工具能够以确定性的方式从日常英语中生成这些业务逻辑之前，我们仍然需要那些能够理解并必要时修改它生成的代码的人。这些人将是软件开发人员。
结论
总结来说，我相信在可预见的未来，软件开发人员仍将有其市场，尽管工作的性质将发生变化，我们将使用的工具也可能与现在大相径庭。
原文地址：https://www.sheshbabu.com/posts/thoughts-on-the-future-of-software-development/