【CSDN 编者按】大模型快速发展的近两年时间里，不少程序员担心自己开发的工作不保，有被替代的风险。不过，本文作者并不如此看待，接下来，他将从软件开发的能力级别、外包开发、建模的复杂性、市场规模、业务逻辑定义等角度进行剖析，旨在说明软件开发为什么不会立刻消失。
原文链接：https://www.sheshbabu.com/posts/thoughts-on-the-future-of-software-development/
未经允许，禁止转载！
作者 | Shesh babu Chinnakonda 译者 | 弯月
责编 | 夏蒙
出品 | CSDN（ID：CSDNnews）
大型语言模型（LLM）能够生成图像、文本和代码，在创意界引起了巨大的轰动。 这些模型最初的产物非常荒诞，画出的人物手脚变形，生成的资料和代码也不准确。 但这些模型正在慢慢进步。 在这些模型出现之前，人们认为机器不具有创造性思维。 但如今这种观点的底气越来越弱。 接下来，我们该怎么做呢？
思考未来会怎样往往很难理清思路，所以我们需要依赖框架和类比。
框架：软件开发能力级别
软件开发不仅仅是写代码。人们对程序员的刻板印象是：一个人坐在黑暗的房间里盯着电脑，疯狂敲代码。虽然整天写代码听起来非常吸引人，但软件开发的大 部分时间都花在了与其他人沟通或其他管理工作上，而不仅仅是编写代码：
收集业务用户的需求。
提炼需求，以便将其建模成代码。
与其他团队成员（如设计师和产品经理）交流，可视化解决方案，并制定计划。
与其他开发人员合作，制定技术设计并进一步细化。
设置基础设施、配置、样板等等。
实际编写代码。
调试代码，理解其他人的代码、编写文档等等。
部署到生产环境。
处理生产问题。
以及其他任务……
因此，「AI取代开发人员」就需要胜任以上所有任务，而不仅仅是编写代码。
但是，仔细观察上面的列表，你会发现有些任务也许将来可以自动化，而有些则不可以。我们如何通过框架呈现这个想法呢？
自动驾驶汽车提出了一种分类自动化程度的方法，从无自动化、到部分自动化、再到全自动化。我发现这种方法有很多优点：
清楚地描述了当前技术的能力。
防止我们以非黑即白的方式思考，并非 AI驾驶员完全取代人类驾驶员，而是可能存在灰色地带，AI可以在紧急制动、车道居中等方面辅助人类驾驶员。
那么，对于AI驱动软件开发，又该如何分类呢？
低级：旧时代，AI不参与软件开发的工作。当然，我们之前也有其他类型的自动化，如编译器、构建流程等，但这些不是AI，这些是人类编写的确定性自动化。
中级：当前，开发人员使用ChatGPT或GitHub Copilot来辅助工作，使用AI来编写测试、样板代码、重构、理解代码/错误等。这就像与其他开发人员聊天，你可以提问并获得一些帮助，但他们无法访问你的机器，因此无法创建文件、运行构建命令或部署到生产环境。
高级： 将项目的一部分或整个项目委托给开发人员。 这些 「AI编程人员」将接受需求，编写代码，修复错误，并将最终产品部署到生产环境。 我认为，我们还需要付出大量努力，虽然目前AI只能执行一些简单的开发任务，但未来可能会有所改善。
除了 AI模型可以做些什么之外，我们还应该思考解决方案的准确性。 刚开始的时候，这些模型容易产生一些不太准确的答案，或者需要通过特定的提示才能得到想要的结果。 这会导致采用AI的阻力过大，大多数人因为这个问题而放弃了AI助手。 但这也在改善，更新后的模型不再需要那种程度的提示工程。 此外，AI模型应该能够通过浏览网络来「学习」，而不仅仅是依赖训练数据。 这一点很重要，因为新版本的库和编程语言会不断引入。
框架：外包软件开发
既然我们已经确定了这些能力，那么如何利用这些能力影响团队或组织结构呢？各个公司开发软件的方式多种多样：
完全内部开发。
大部分内部开发，少量供应商。
大部分供应商，少量内部开发。
完全委托给供应商。
某种程度上，我们可以将 AI视为外包软件供应商/顾问。 一些公司大量使用AI，而有些则不怎么使用。 无论项目的组成如何，我认为始终有必要通过一个内部团队监督这些工作。 这是为了确保供应商的产出与组织的长期目标保持一致。 当然，你可以通过合同解决这个问题，但通常仅限于特定的供应商或项目，你无法通过这种方法执行长期目标。 通过一个小型内部团队来指导供应商更好。 同样，即便AI可以像EC2实例一样出租，通过一个内部软件开发团队来监督AI的工作会更好。
框架：软件开发是建模复杂性
谈到如何解决业务问题，让我们花点时间来谈谈庞然大物： Excel 。众所周知，Excel的全球用户超过10亿。Excel为组织数据、分析数据或自动化某些流程的业务用户提供了非常低的门槛。然而，我们无法利用Excel梳理复杂的业务工作流程，因为它没有提供细粒度的访问控制、与不受支持的系统集成、可测试性、可重用性或仅仅是供应商锁定等功能。「低代码」解决方案也有同样的问题，如Power Automate等。
回到最初的问题， 业务用户能否在没有软件开发人员的帮助下使用AI来创建复杂的工作流程？
想一想，Excel和低代码工具问世已经几十年了，为什么软件开发行业仍然存在呢？归根结底是因为这些解决方案认为软件开发仅仅是编写代码。然而，对于复杂的问题，我们需要能够有效地管理这些复杂性并将业务问题从现实世界领域转换为数字模型的人。
举个例子，观看短视频，无需土木工程师的帮助，就能建造一个小木屋，但这并不意味着你就可以建造一座10层高楼。只有认真学习如何建造10层的建筑，慢慢地你才能成为一名土木工程师。这就要看你是愿意花时间认真学习，还是聘请一位经验丰富的工程师来替你完成。
因此，无论这些人使用Excel还是最新的AI，如果他们正在对复杂的逻辑进行建模，那么在我看来，他们就是软件开发人员。只不过，他们使用不同的工具来表达业务需求：电子表格公式、代码还有AI提示。
框架：市场规模
围绕这个话题的大部分焦虑都假定软件开发市场的规模保持不变，AI将逐步从人类手中夺走「市场份额」。
通过前面的讨论，我们了解到「解决业务问题」的市场规模远远大于软件开发。因此，
框架：正式的业务逻辑定义
业务逻辑必须通过某种明确的格式定义。这就是为什么虽然编程语言使用「if」、「switch」等英语单词，但依然对这些单词的含义进行了严格的规定，如果使用错误的单词，代码就无法运行。仔细想一想，Excel公式或低代码流程也是如此。
将来，即使AI能够通过以对话的形式给出的指令生成软件产品，我仍然相信后端生成的业务逻辑会有一个底层的正式定义。有可能这种正式的业务逻辑定义不同于我们今天使用的语言和框架，看起来很像「代码」。
也许将来AI能够以确定性的方式根据对话生成这些业务逻辑，但在这之前，我们仍然需要能够理解AI在后端生成的代码并根据需要修改这些代码的人。而这些人正是软件开发人员。
总结
总的来说，我相信在可预见的未来，软件开发人员仍然有市场，只不过工作性质将发生变化，使用的工具也有可能与现在大不相同。
推荐阅读：
