夜雨聆风
软件工程行业走到尽头了吗?还没,但或许未来会
好文翻译，原文链接
https://dev.to/aws/is-software-engineering-cooked-not-yet-but-maybe-5e0j
“软件工程的问题已经被解决了。”最近我在领英、X平台或者红迪网上浏览内容时，满眼都是这种论调。
这种观点传递的信号清晰又直白：程序员们已经没有发展空间了，我们都该立刻转行，去从事水管工或者电工这类工作。
这个想法倒也并非完全荒诞。AI编程工具（AI coding tools）的发展速度极为迅猛，它对软件开发领域的冲击，几乎超过了其他所有白领行业。熟练运用这些工具的开发者，能够快速生成大量可正常运行的代码，死记硬背代码语法、手动编写所有代码的时代，已经彻底成为过去。
对此最直观的回应是，代码生成仅仅是软件工程工作中的一小部分。我说出这个观点时，通常在场的人都会点头表示认同。
但我们很少去深入探究，软件工程的其余工作内容究竟是什么。如果代码生成的问题基本已经被攻克，那么核心问题就变成了：软件工程还剩下哪些工作需要人类去完成？
目前AI编程工具的产出效果相差极大。有的开发者表示自己的工作效率得到了大幅提升，也有人称这些工具只会拖慢工作进度，生成的全是毫无用处的AI垃圾代码（AI slop）。
造成这种巨大差异的关键原因，在于围绕AI编程工具所搭建和使用的配套体系。
软件工程看似已经被AI完全解决，是因为代码生成技术在飞速进步。理清这背后的缘由，就能明白当下行业的现状，也能预判行业未来的发展走向。
我们不妨从一个简单的问题开始思考：为什么代码生成会成为生成式AI（generative AI）的核心应用场景？
为什么代码对AI来说极易生成
软件开发工作高度依赖模式化设计。我们在工作中会运用到编程语言语法、框架规范、数据结构（data structures）、标准设计模式、可复用组件以及各类常见的架构结构。
大部分代码都遵循着既定的模式。这类AI模型的训练数据，包含了海量来自真实开发场景和开源项目（open source projects）的代码，有数百万种常见模式的实现案例可供模型学习。
编写代码本质上就是把已知的模式应用到新的问题当中。需要搭建REST接口（REST endpoint）？有成千上万个参考案例。需要验证用户输入？想要实现身份验证（authentication）功能？这些模式都有着十分完善的文档说明。
这也是绝大多数常见场景下的代码语法和实现方式基本被AI攻克的原因。AI模型已经见过无数次这类模式，能够根据具体的使用场景做出细微调整，可靠地复写出对应的代码。
但仅靠模式匹配，还不足以解释AI编程工具为何能有如此出色的表现。还有一个关键因素，让软件开发工作格外适合AI进行代码生成。
软件具备可验证性
除AI相关场景外，大多数场景下的合格软件都有一个简单的特性：相同的输入会产生相同的输出，这就是确定性（determinism）。
代码的具体实现方式可以各不相同。把同一个用户需求交给两位不同的开发者，他们会给出两套完全不同的解决方案。
代码的结构、抽象设计和所用技术或许存在差异，但从终端用户的角度来看，软件必须满足对应的功能需求。
这一特性让软件开发工作格外适配AI辅助开发模式。非确定性系统可以生成多种可行的代码实现方案，而我们依旧能够判断最终成果是否合格——软件的运行效果要么符合要求，要么不符合；测试用例要么能顺利通过，要么无法通过。
软件的功能是核心部分，这部分内容可以通过自动化的方式进行检测和验证。
不过很多行业的工作成果都可以量化、检测并反复迭代优化，为什么程序员会成为最先全面感受到AI普及带来冲击的群体呢？
自动化是行业的核心文化
原因之一在于，软件工程本就已经高度流程化，而且将一切可自动化的内容实现自动化，早已是这个行业的文化内核。
我们拥有持续集成/持续交付流水线（CI/CD pipelines，Continuous Integration/Continuous Deployment）、自动化测试工具、自动化安全扫描工具，各类数据指标遍布开发全流程。我们早已掌握搭建反馈循环、实现流程自动化的方法。如今，我们正把这些经验和技能，应用到生成式AI出现前无法实现的工作环节中。而这种变革推进得如此迅速，是因为我们既是行业领域专家，也是这些AI系统的搭建者。
这就形成了极快的迭代速度，这种迭代效率在其他行业很难自然形成。
如果一名开发者在周一发现了一项创新的AI工程技术，周三就会写成博客文章获得数千读者阅读，周五就会有多人尝试围绕这项技术开发工具。几周之内，若没有新的技术取代它，这个思路就会融入主流开发流程。如此循环往复，不断推动行业发展。
但即便取得了这些进展，代码实现依旧只是软件工程工作的一小部分。要让系统在生产环境（production）中稳定可靠地运行，还需要付出大量的工作。
软件工程的其余工作内容
可运行的代码只是衡量软件合格的一个维度。能投入生产环境使用的软件，需要同时满足多个维度的要求，比如安全性（security）、可扩展性（scalability）、架构设计（architecture）、可维护性（maintainability）、系统集成（integration）、性能（performance）、稳定性（stability）以及依赖管理（dependencies）。一个独立运行正常的系统，一旦忽略上述任何一个维度，在实际应用中都可能出现故障。
聊到这里，大家通常会认为，未来所有开发者都会转型成为架构师。如果代码实现工作被自动化替代，人类就会专注于更高级别的系统设计工作。
这种说法有一定的道理，我认为当下行业也正朝着这个方向发展。精通系统设计的开发者，在如今的就业市场中更具竞争优势。但高级别的系统设计工作，会一直由人类专属完成吗？这个假设已经开始受到挑战。
将判断逻辑编码化
软件工程中很多更具难度的工作，核心都在于专业判断。对于一个特定系统来说，怎样才算“优质”？哪些技术取舍是可以接受的？系统的复杂度该如何分配？这种专业判断，正是区分普通可运行代码和生产级可用软件的关键。
开发者们已经开始尝试，把这类专业判断逻辑融入自动化系统中。这类系统不再是简单的聊天机器人，更像是协同工作的流水线。一个组件负责生成代码实现方案，其他组件通过运行测试验证代码行为、用确定性工具检测问题、评估架构相关问题。还可以加入更高级别的审核环节，让AI模型权衡技术取舍、校验一致性并评估设计决策。
从很多方面来看，这都是持续集成/持续交付流程的自然延伸。不再是人类编写完代码后再进行校验，而是系统在代码生成的同时就完成验证，反馈循环变得更加紧密。
这也是规范驱动开发（specification-driven development）逐渐流行的原因之一。如果由AI模型生成代码实现方案，开发者就需要精准定义软件行为，确保能通过自动化方式验证代码是否合格。行业的工作重心，也从编写代码转变为定义合格代码的标准。
这些工作目前都还未完全成熟。针对架构评估、性能验证等高级别工作的自动化成熟模式尚未出现，不过已有多个团队在积极研发，取得的成果也参差不齐。
技术的普及会循序渐进，受监管行业的推进速度会更慢，因为对这些行业来说，可靠性和责任追溯比开发速度更重要。但每一项被编码成验证步骤的工程判断能力，都会成为系统可以自主处理的工作。
对于使用最新顶尖工具的开发者来说，工作中最难的部分，已经从学习代码语法转变为培养专业判断能力。这种转变可能会让软件工程从业者的职业初期变得更艰难，因为专业判断需要时间和经验才能积累形成。
我们的行业走到尽头了吗？
软件开发行业走到尽头了吗？还没有。
或许未来会有这么一天。但我认为，人类在软件开发流程中参与的时间，会比AI行业圈内人士目前预想的更久。我的判断是否正确，只有时间能给出答案。
不过，这份职业的变化速度，比我们大多数人预想的都要快。过去需要几天才能完成的功能开发，如今开发者几小时就能上线；小团队也能打造出原本需要数十名工程师才能完成的产品。
短期来看，市场对能够搭建系统、让AI生成代码适配生产环境的开发者需求正在不断增长。
我们过去把大部分时间都花在编写代码实现上，如今这部分耗时正在不断减少。而增长的是周边的所有工作：明确合格软件的标准，搭建验证体系来证明软件达标。