【编者按】当 Devin 此类能够独立完成项目的 AI 程序员横空出世之时，AI 取代程序员之说愈演愈烈，本文作者 Sheshbabu Chinnakonda 撰文分享了自己对于软件开发未来的一些思考。尽管 AI 程序员未来有望实现更复杂的功能，但作者坚信，无论技术如何进步，对于软件开发的需求都不会消失。
特别注明：本文翻译经过我使用 GPT-4 不断尝试 Prompt 翻译所得，欢迎大家指正。原文链接：https://www.sheshbabu.com/posts/thoughts-on-the-future-of-software-development/
作者 | Sheshbabu Chinnakonda
责编 | 沭七
当大型语言模型（LLMs）开始能够创造图像、文本和代码时，它们在创新领域引起了巨大的波澜。最开始，这些尝试带来了许多有趣的成果，例如画出的人物手部扭曲不自然，生成的文本充满幻想错误，以及产出的代码也经常出错。但随着时间的推移，这些问题正在逐步得到改善。在这些模型出现之前，人们普遍认为机器无法进行创造性思考，这一观点随着每一天的推移变得越来越站不住脚。那么，我们接下来会走向何方？
图源：DALL·E考虑诸如预测未来这样模糊不清的问题时，我们往往会发现自己的思维变得模糊，难以清晰地思考。因此，我们需要构建一些框架和比喻来帮助我们理解和推进。
软件开发能力层次
软件开发远不止编写代码。人们常常将程序员想象成一个孤独地坐在昏暗房间里，对着电脑屏幕疯狂敲打键盘的人。虽然对一些人来说，整天编码似乎很有吸引力，但实际上大部分软件开发的时间都花在了其他事务上，而不仅是编写代码：
从业务用户处收集需求
精炼这些需求，使之能够转化为代码
与设计师、产品经理等团队成员沟通，共同构想解决方案并制定实施计划
与其他开发者合作，设计技术方案并不断优化
配置基础设施、设置环境、准备初始代码等
真正地编写一部分代码
调试、阅读他人代码、编写文档等
将成果部署到生产环境
解决生产环境中的问题
以及许多其他任务
因此，当人们说“AI 将取代开发者”时，所指的“AI”必须在上述所有方面都能胜任，而不仅仅是编写代码。
但从以上列出的任务来看，虽然有些工作在未来可能被自动化，但目前还没有实现。我们该如何思考这一问题？
自动驾驶汽车的研究给我们提供了一个思考自动化层次的方法。这种分类方法定义了从无自动化到完全自动化的不同级别。这种分类方式非常有用，因为：
它明确描述了当前技术能实现的功能。
它避免了我们陷入非黑即白的思考模式——并不是要在人类驾驶员与 AI 驾驶员之间进行选择，而是可以在例如紧急刹车、车道保持等方面，让人类驾驶员得到 AI 的辅助。
将这种分类应用到 AI 驱动的软件开发中：
最初级别是之前的状态——开发工作中不涉及 AI。当然，我们已经有了诸如编译器、构建流程等其他自动化工具，但这些不是 AI，而是人类编写的确定性自动化程序。
现在的水平是开发者利用 ChatGPT 或 GitHub Copilot 等工具进行辅助。他们利用这些工具进行测试编写、准备初始代码、重构、理解代码或错误等任务。这就像与一位开发伙伴通过聊天进行交流，你可以向他提问并得到一些帮助，但他们不能直接操作你的机器，无法直接创建文件、执行构建命令或部署到生产环境。
最高级别将是将项目的一部分或全部委托给“AI 开发者”。这些 AI 程序员将根据需求编写代码、修复错误并将最终产品部署到生产环境。我曾以为我们距离实现这一点还有很长一段时间，但 Devin 的示范让我意识到自己的预判有误——尽管它目前只能执行简单的开发任务，但未来有望实现更复杂的功能。
除了考虑 AI 模型能做什么，我们还应该考虑解决方案的准确性。一开始，这些模型容易出现错误，或者需要以特定的方式来提示它们才能得到想要的结果。这种情况增加了使用上的障碍，许多人因此放弃了 AI 助手。但这个情况也在改善，新一代的模型不再需要如此复杂的提示技巧。此外，这些模型应该能够通过浏览网络而不仅仅是依赖其训练数据来“学习”。这一点尤其重要，因为随着新版本的库和编程语言的推出，技术领域总是在不断变化。
外包软件开发
既然我们已经明确了 AI 的能力，这会如何影响团队或组织结构？公司有多种软件开发模式：
完全内部开发
主要内部开发，少部分外包
主要外包，少部分内部开发
完全外包
某种程度上，我们可以将 AI 开发者看作是外包软件供应商或顾问。有些公司大量依赖他们，而有些则较少。不管组织结构如何，重要的是保持一个内部团队来监督工作。这是为了确保外包输出与组织的长期目标一致。虽然通过合同可以解决一些问题，但合同通常只适用于特定的供应商或项目，并不能保证实现长期目标。因此，拥有一个能够指导外包工作的内部团队总是更好的选择。同样，即使 AI 开发者可以像云服务一样被租用，仍然需要一个内部的软件开发团队来监督他们的工作。
软件开发 = 复杂性建模
如果我们从解决商业问题的角度来看，不得不提 Excel。Excel 是众所周知的秘密，全球有超过 10 亿的用户。它为那些希望组织数据、进行数据分析或自动化某些流程的商业用户提供了一个极低的入门门槛。然而，对于复杂的商业工作流，Excel 因为缺乏如细粒度访问控制、与不受支持的系统集成、测试性、可重用性或供应商锁定等功能而不够使用。对于如 Power Automate 这类的“低代码”解决方案也是如此。
那么，回到最初的问题，商业用户是否能够在没有软件开发者帮助的情况下，使用 AI 开发者来创建这些复杂的工作流？
如果深入思考，Excel 和低代码工具已经存在了几十年，但软件开发职业仍然存在并且兴旺发展。这是因为软件开发不仅仅关于编码。对于复杂的问题，我们需要那些能够有效管理这些复杂性，并将商业问题从现实世界转化为数字模型的人才。
换言之，如果你能够通过观看 YouTube 教程建造一个小木屋而无需土木工程师的帮助，并不意味着你也可以自己建造一个十层楼的建筑。如果你愿意投入时间和精力去学习如何正确地完成，那么你最终会变得像土木工程师一样。问题在于你是否愿意为此投入时间，或者选择聘请一位有经验的工程师来完成这项工作。
因此，无论是使用 Excel 还是最新的 AI 开发工具，只要他们在处理复杂的逻辑问题，实际上都在进行软件开发。只是选择了不同的工具来表达业务需求——无论是通过电子表格公式、编码还是命令提示。
开发者市场的规模
关于这个主题的大多数担忧都假设了软件开发市场的规模是固定的——AI 开发者将逐步从人类手中夺取“市场份额”。
但是，从上一节我们可以知道，“解决商业问题”的市场规模远大于软件开发本身。因此，没有理由认为软件开发会在短期内消失。
商业逻辑的正式定义
商业逻辑必须始终以一种明确无误的格式定义。这就是为什么即使编程语言使用了像“IF”、“switch”这样的英语单词，它们也非常严格地定义了这些单词的含义，并且如果使用错误，程序就无法运行。实际上，这同样适用于 Excel 公式或低代码流程。
未来，即使 AI 开发者能够根据口头英语指令生成软件产品，我相信在后端仍然会生成商业逻辑的正式定义。这可能与我们今天使用的语言和框架截然不同，但商业逻辑的正式定义听起来很像是“代码”。
直到 AI 开发者能够以一种确定性的方式从口头英语中生成这些商业逻辑，仍然需要那些能够理解后端生成的代码并在必要时进行修改的人。这些人是软件开发者。
结论
总的来说，我相信在可预见的未来，即便工作性质和我们使用的工具将发生变化，软件开发者的市场仍将存在。软件开发不仅仅是编写代码；它是关于理解和转换复杂性，以及如何将商业需求转化为数字解决方案。无论技术如何进步，这种能力的需求都不会消失。
