当大语言模型 (LLMs) 能够创作出图像、文本和代码时，它们在创意领域引发了极大的关注。起初，这些创作令人啼笑皆非，比如画出手部奇怪的人物、产生错误的事实和代码的幻觉。然而，随着时间的推移，情况正在逐步且稳定地改善。在这些模型诞生之前，人们常常反对将这些任务自动化，认为机器无法进行创造性思维。但现在，这一论点正变得越来越站不住脚。那么，我们的下一步该往哪里走？
思考如预测未来这样模糊的问题时，我们可能会发现自己的思路变得混乱，难以有条理地思考。因此，我们需要构建一些框架和比喻，帮助我们整理思路。
框架：软件开发的能力层次
软件开发远不止编写代码那么简单。人们常有的程序员形象，是一位独自坐在昏暗的房间里，目不转睛地盯着电脑屏幕，快速敲打键盘。尽管整天沉浸在编码中听起来很有吸引力，但实际上，软件开发的大部分时间都在与人沟通或处理行政工作上，而不只是编写代码：
- 收集业务用户的需求
- 精炼需求，使其可以转化为代码
- 与设计师、产品经理等团队成员讨论，共同描绘解决方案并规划实施步骤
- 与其他开发人员合作设计技术方案并进行优化
- 构建基础设施、进行配置、准备初始代码等
- 真正的编码工作
- 调试、理解他人代码、编写文档等
- 向生产环境部署
- 解决生产环境中的紧急问题
- …以及其他许多任务
因此，声称“AI 将取代开发人员”意味着 AI 必须能够胜任以上所有任务，而不仅是编写代码。
也就是说，要说“AI 将取代开发人员”，就意味着 AI 需要在上述所有方面都能独当一面，不仅仅是写代码。
但是，观察上述任务列表，可以看出未来某些任务有可能实现自动化，尽管目前尚未达到。我们该如何构建这种想法呢？
以自动驾驶汽车为例，人们提出了一种自动化水平的分类方法，该方法设定了从无自动化到部分自动化，再到完全自动化的不同层次。我认为这种分类不仅有助于理解自动化的发展，也为许多领域提供了有价值的参考。
- 它明确展示了现阶段技术的能力
- 它引导我们跳出非此即彼的思维定式 – 这场较量不仅仅是人类司机与 AI 司机之间的，也不是让 AI 完全替代人类司机。实际上，我们可以探索一种灰色地带，在紧急刹车、保持车道中心等方面，AI 能够辅助人类司机。
对于 AI 驱动的软件开发来说，这样的分类意味着什么？
- 最基础的层次是我们过去的状态 – 涉及工作的地方没有 AI 的身影。当然，我们曾经使用过编译器、构建过程等其他类型的自动化工具，但这些并不属于 AI，它们是由人类编写的确定性自动化程序。
- 下一个层次是我们目前的实践 – 开发者借助 ChatGPT 或 GitHub Copilot 来获得帮助。他们利用这些工具编写测试、构造样板代码、重构代码、理解代码及错误等。这有点像是与一位开发者在线交流，你可以向他提问并获得帮助，但由于他们无法访问你的计算机，所以无法创建文件、执行构建命令或部署到生产环境。
- 最高的层次就像是将你的部分项目或整个项目委托给一名开发者。这些“AI 程序员”将根据需求编写代码、修复错误，并将最终产品部署到生产环境。虽然我原本认为这一天还遥遥无期，但Devin 的演示让我大吃一惊 – 尽管目前它只能完成一些简单的开发任务，但未来它有望实现更多功能。
除了 AI 模型的能力外，我们还应当关注其解决方案的准确性。在最初，这些模型往往会做出一些不符合预期的响应，或者需要以特定的方式进行指令输入才能实现预期的效果。这使得人们在尝试采纳 AI 助手时感到困难，许多人因此而放弃。然而，这种状况正在得到改善，新一代模型不再需要如此复杂的指令设计。同时，模型应当能通过网页浏览来进行“学习”，而非仅仅依赖它们的训练数据。这一点对于跟上库和编程语言新版本的更新尤为重要。
框架：外包软件开发
在我们明确了软件开发的多种能力后，这些能力会如何影响到团队或组织架构的形态呢？企业进行软件开发的方式大致可以分为：
- 完全由内部团队负责
- 主要由内部团队负责，辅以少数外部供应商
- 主要依赖外部供应商，内部团队辅助
- 完全依靠外部供应商
我们可以将 AI 编程师比作外包的软件供应商或顾问。不同的公司对这种做法的依赖程度不同，有些频繁利用，有些则较少。不过，不论具体怎样组合，我认为保持一个内部团队来监督这些工作始终是至关重要的。这是为了确保外包供应商的工作成果能够与公司的长期目标保持一致。虽然通过合同来规定具体的供应商或项目是一种做法，但这通常只适用于特定情况，且难以通过此种方式确保长期目标的实现。因此，最佳做法是维持一个规模不大但能够对供应商进行指导的内部团队。同样，即便 AI 编程师可以像租用云服务器一样方便，拥有一个负责监督他们工作的内部软件开发团队也是非常有益的。
框架：软件开发是对复杂性的建模
在讨论解决商业问题时，我们不得不提一个广为人知的事实：Excel。事实上，全球有超过 10 亿的用户依赖 Excel 来管理他们的日常工作。Excel 以其低门槛吸引了大量希望整理数据、进行数据分析或者自动化流程的商业用户。但是，对于复杂的商业流程，Excel 显然力不从心，因为它缺少精细的访问控制、与其他不支持的系统集成的能力、可测试性、可复用性或者说是对特定供应商的依赖等特性。对于“低代码”方案，比如 Power Automate 等，情况也是如此。
那么，回到我们最初的问题：在没有软件开发人员的帮助下，商业用户能否利用 AI 编程工具来构建这些复杂的工作流程呢？
在没有软件开发人员的协助下，商业用户真的能够使用 AI 编程工具来打造这些复杂的工作流程吗？
思考这个问题，我们不禁要问，既然 Excel 和低代码工具已经存在了这么多年，为何软件开发这一职业还依旧存在？这实际上让我们重新思考软件开发的本质：它不仅仅是编码那么简单。对于复杂的问题，我们需要的是那些能够有效管理复杂性，并能将商业问题从现实世界成功转化为数字模型的专业人才。
换而言之，如果你能通过 YouTube 教程自学建造一个木棚，而不需土木工程师的帮助，这并不表示你也能够或应该自己动手建造一个十层高的大楼。如果你决定学习如何正确进行这项工作，那么随着时间的推移，你逐渐就能成为一名土木工程师了！关键在于，你是否愿意投入时间去深入学习这一领域，或者聘请一位经验丰富的工程师来完成这项工作。
因此，不管是使用 Excel 还是最新的 AI 编程工具，只要他们在处理复杂的逻辑问题，那么在我看来，他们都是软件开发者。只不过，他们采用了不同的工具来表述业务需求——无论是通过电子表格的公式、编码，还是命令提示。
对于软件开发市场规模的思考
关于这个议题，许多人担心的是软件开发市场的规模将会保持不变，而 AI 编程将逐渐从人手中夺取市场份额。
但从之前的讨论我们可以明白，解决业务问题的市场规模远不止软件开发那么简单。所以，软件开发不太可能在短期内就消失。
框架：严谨的业务逻辑定义
业务逻辑的定义必须清晰无误。正因如此，即便编程语言采用了如“if”、“switch”等英文单词，它们对这些词汇的含义有着严格的规定，一旦词汇用错，程序就无法运行。其实，Excel 公式或低代码流这样的工具也是同理。
未来，哪怕 AI 程序员能够根据以口语英文形式给出的指令生成软件产品，我认为在后台仍会形成一套业务逻辑的严谨定义。这种定义可能与我们现在使用的语言和框架迥异，但其实质，与“编码”无异。
在 AI 程序员能够确定性地根据口语英文生成业务逻辑之前，我们还需要那些能理解后台生成代码并在必要时对其进行修改的人——软件开发人员。
结论
总的来说，我相信软件开发人员在未来仍有一席之地，虽然他们的工作性质和使用的工具将会发生变化，但这一职业不会消失。
