> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 软件工程师完蛋了吗？ - URL: https://www.hubwiz.com/blog/are-software-engineers-cooked/ - Published: 2026-07-27T16:13:48.000Z - Updated: 2026-07-27T16:13:48.000Z - Description: "软件工程已经解决了。"这是我最近在LinkedIn、X或Reddit上看到的所有信息。信息响亮而清晰：开发者完蛋了，我们都应该立即转型，成为水管工或电工。 - Author: admin - Tags: INDUSTRY, #Import 2026-10-14 14:41 "软件工程已经解决了。"这是我最近在LinkedIn、X或Reddit上看到的所有信息。 信息响亮而清晰：开发者完蛋了，我们都应该立即转型，成为水管工或电工。 这并不是一个*完全*疯狂的想法。AI编程工具的进步速度对软件开发的影响超过了几乎所有其他白领领域。深入使用这些工具的开发者可以快速生成大量可运行的代码，而记住语法和手动编写一切的时代已经结束了。 明显的回应是代码生成只是软件工程这块蛋糕的一小部分。当我这么说时，通常每个人都会点头同意。 但我们很少谈论这块蛋糕的其余部分到底是什么。如果代码生成基本上已经解决，那么问题就是还剩下什么。 目前AI编程工具的结果参差不齐。一些开发者报告了巨大的生产力提升。其他人说它让他们变慢了，除了AI垃圾什么也没产生。 这种差异的很大一部分归结于AI编程工具周围的系统是如何构建和使用的。 软件工程看起来已经解决，因为代码生成正在快速发展。理解原因可以解释我们现在看到的情况以及这将走向何方。 一个很好的起点是一个简单的问题：为什么代码生成是生成式AI的一个成功用例？ ## 1、为什么代码对AI来说很容易 软件开发严重依赖模式。我们处理语言语法、框架约定、数据结构、标准模式、可重用组件和熟悉的结构。 大多数代码遵循既定模式。这些模型的训练数据包括来自真实世界示例和开源项目的大量代码。有数百万种常见模式的实现可以学习。 编写代码主要是将已知模式应用于新问题。你需要一个REST端点？有成千上万的例子。需要验证用户输入？想实现身份验证？这些模式也有很好的文档记录。 这就是为什么大多数常见用例的语法和实现基本上已经解决。模型已经见过这些模式数千次。它们可以可靠地再现它们，并进行微小的更改以适应你的特定上下文。 但模式匹配 alone并不能解释为什么AI编程工具如此有效。还有另一个因素使软件特别适合AI生成。 ## 2、软件是可验证的 大多数非AI相关用例的正确软件有一个简单的属性：相同的输入产生相同的输出。那就是确定性。 实际的实现可能不同。如果你给两个不同的开发者相同的用户故事，他们会产生两个不同的解决方案。 结构、抽象和技术可能不同。但从最终用户的角度来看，必须满足功能需求。 这个属性使软件特别适合AI辅助开发。非确定性系统可以生成许多可能的实现，但我们仍然可以测量结果是否正确。行为要么正确，要么不正确。测试要么通过，要么不通过。 软件的功能是最重要的部分，可以自动测量和测试。 但许多不同的领域都有可测量的输出，可以测试和迭代。为什么软件开发者可能是第一批感受到AI采用全部影响的群体之一？ ## 3、自动化是我们的文化 部分原因是软件工程已经深度机械化，而且我们的文化是自动化一切。 我们有CI/CD管道、自动化测试、自动化安全扫描和随处可见的指标。我们已经了解如何构建反馈循环和自动化流程。现在我们将这些技能和经验教训应用到我们工作的其他方面，这是在生成式AI之前不可能实现的。而它加速如此之快的原因是我们既是领域专家，也是构建系统的人。 这创造了极其快速的迭代，这在其他领域不太可能有机发生。 如果一个开发者在周一发现了一种真正创新的AI工程技术，到周三它就会出现在一篇有数千读者的博客文章中。到周五，已经有多人尝试围绕它构建工具。几周内，如果其他东西没有取代它，这个想法就会集成到主流工作流程中。如此循环往复。 但即使有了所有这些进展，实现仍然只是软件工程这块蛋糕的一小部分。让系统在生产环境中可靠运行需要大量的工作。 ## 4、软件工程这块蛋糕的其余部分 可运行的代码只是正确性的一个维度。生产就绪的软件需要许多维度同时对齐，如安全性、可扩展性、架构、可维护性、集成、性能、稳定性和依赖性。一个在隔离状态下正确运行的系统在忽略任何这些维度时仍然可能失败。 这通常是对话转向开发者都会成为架构师的想法的地方。如果实现变得自动化，人类专注于更高层次的系统设计。 这是有道理的，我认为这就是我们现在所处的位置。理解系统设计的开发者在当今市场中具有优势。但更高层次的设计是否仍然纯粹是人类活动？这个假设已经在被检验了。 ## 5、编码判断 软件工程中许多更难的部分归结为判断。对于一个特定系统，"好"是什么样子的？哪些权衡是可以接受的？复杂性应该存在于哪里？这种判断是将可运行的代码与生产就绪的软件区分开来的东西。 开发者已经在尝试将这种判断编码到自动化系统中的方法。这些系统看起来不太像聊天机器人，更像协调的管道。一个组件生成实现。其他组件通过运行测试验证行为，使用确定性工具扫描问题，并评估架构问题。可以添加更高层次的审查，模型评估权衡、一致性和设计决策。 在许多方面，这看起来像是CI/CD的自然延伸。不是在人类编写代码后验证代码，而是在代码生成时验证系统。反馈循环变得更紧密。 这也是规范驱动开发获得 traction的原因之一。如果模型生成实现，开发者需要精确定义行为，以便正确性可以自动测试。纪律从编写代码转向定义正确代码是什么样子。 这些都没有解决。自动化更高层次关注点（如架构评估和性能验证）的经过验证的模式尚不存在，尽管许多团队正在积极工作（并取得不同程度的成功）。 采用将是渐进的，受监管的行业将移动得更慢，因为可靠性和问责制比速度更重要。但每个编码到验证步骤的工程判断维度都是系统可以处理的另一件事。 对于那些使用最新最好工具的人来说，成为开发者的最困难部分已经从学习语法转向培养判断力。这种转变可能会使软件职业生涯的早期阶段更加艰难，因为判断力需要时间和经验来建立。 ## 6、我们完蛋了吗？ 软件开发完蛋了吗？还没有。 也许在未来。但我认为人类将在我们AI泡沫内部目前相信的更长时间内保持在循环中。只有时间会告诉我是否正确。 然而，这份工作的变化速度超出了我们大多数人的预期。开发者可以在几小时内交付过去需要几天才能完成的功能。小团队可以构建过去需要数十名工程师的产品。 短期内，对于能够构建使AI生成的代码生产就绪的系统的需求正在增长。 我们过去大部分时间都在编写实现。这段时间正在萎缩。增长的是围绕它的一切：弄清楚正确的软件是什么样子，并构建验证来证明它。 --- 原文链接：[Is Software Engineering Cooked? Not Yet. But Maybe.](https://dev.to/aws/is-software-engineering-cooked-not-yet-but-maybe-5e0j?ref=hubwiz.com) 汇智网翻译整理，转载请标明出处