软件工程，AI改变了剧情
有些人称之为生存危机，我称之为美丽新世界……
目标对我来说很重要。没有目标，我就没有方向，如果我没有方向，我究竟是谁？我最不希望的就是生存危机。我通过搭建乐高泰坦尼克号成功度过了中年危机。解决那个问题很容易，但对于2026年，我有一个更雄心勃勃的目标：一本关于软件工程的书。从我出版第一本书的那一刻起，人们就问我是否还有另一本书的灵感。我有。不是小说。但也是一本书。关于软件工程，因为那就是我。自从我21岁写下第一行HTML以来，我就一直是这样。现在我又回到了起点。因为AI。因为在AI时代成为一名软件工程师是完全不同的话题。
这不再是 fad 了。AI 是一个即将破裂的泡沫也无关紧要。别忘了，互联网泡沫破裂后，迎来了我们今天所拥有的互联网，并且已经存在了二十多年。如果让我评价的话，作为一个技术泡沫，这还算不错。所以，如果你还在思考 AI 的可行性，不要再想了。这正在发生，软件开发已经发生了翻天覆地的变化。永远改变了。随之而来的是，我书中原本要涉及的很多内容也发生了变化。
Attila，我相信你过去写的一半文章如果现在考虑到 AI 的话，都需要大幅修改。—— B，工程高级副总裁
作为 Prezi 工程组织中知名的作家，在伊斯坦布尔我们最新的异地午餐上，我的高级副总裁在两口鸡肉之间提出这个建议时，我并不感到惊讶。他没有错，而且我有一种挥之不去的怀疑，一旦我完成书的第一稿，我也会得出同样的结论。听到这是一个有点不舒服的事实，但这无论如何就是我们所有人都在软件开发的现实中面临的。两年前，我已经在考虑增加一章关于 AI 的内容。一章！事后看来，我那时候太天真了，事实上 AI 触及了几乎所有软件工程的内容，为了找出有多少，我回到了我的初稿，并写下了可能成为下一稿基础的内容——前提是会有下一稿。
1、所有改变的东西
敏捷已经存在了25年，至少以目前的形式，尽管迭代开发可以追溯到70年代初。要的是我们已经习惯了它。当然，我们绝大多数人实施的是一种相当 bastardised 的版本，sagas、epics 和 stories 往往比从 Temu 买的小饰品更没有描述性，但我们正在做某种敏捷。我们推送的 bug 比以往任何时候都多，但至少我们是在 sprints 中做的，而且我们可以像发布它们一样快地回滚它们。敏捷并不完美，我们就此打住。但 AI 把它颠覆了。你的云端代理在后台运行任务，Sentry 问题在你吃午饭时变成了 Pull Requests，而且你一半的 Scrum 仪式一夜之间变得无用。就目前而言，我还没有看到过一个连贯的敏捷实现，其中 AI 驱动的开发是软件工程的主要风味。
说到我们发布的 bug，让我们不要忘记经常被忽视的开发、测试和 UX 的中间孩子：无障碍性。通常，你必须进行艰苦的战斗才能让你的团队中有人考虑将无障碍性作为一项要求。VPAT 就像根管治疗一样自愿，而测试通常只是快速检查一下 alt 文本和一个跳过链接。当然，如果这些都已实现并有效，那么整个应用程序对残障用户来说就是可访问的。然而，AI 将一个漫长而艰巨的过程改变成了我实际上看到很大潜力的东西。AI 可能正是让我们在本世纪结束前拥有一个无障碍网络的东西。 这并非无足轻重，但这如何运作，以及我们如何充分利用 AI 来实现它，尚未定义。但至少我们从没有希望变成了真正的希望。
虽然测试驱动开发（TDD）并不新鲜，但它也是最具争议的话题之一。纯粹从理论角度来看，它是有道理的。你正在构建应该满足某些要求的东西。把它想象成汽车。测试和测试工具在汽车甚至存在之前就已经到位了。为了让它可以上路，它需要通过测试。然而，在实践中，软件开发并不那么 rigid——尽管在 numerous 情况下它应该是——随之而来的 TDD 在实践中变得更难推销。有了 AI，我想我们又要用规范驱动开发再试一次，而且我发现当与代理工程结合使用时，TDD 确实能提高结果的质量。
本质上，我是一名前端开发人员。后端开发本身没有什么错，我只是更喜欢我能看到的东西。因此，你可以想象我从原生 JavaScript 到 jQuery、Angular、React、Svelte 等等都做过。这就是为什么我也喜欢 SSG。但我认为 AI 在很大程度上改变了我们开发 UI 和 UX 流程的方式。前几周，我们的客户成功总监正在研究使用 Retool 重新开发他们的主要客户支持工具。30分钟的会议后，安全主管和我得出结论，我们需要别的东西。所以我教 CS 总监如何使用 Cursor，并向他展示如何为他们的工具构建新的 UI。几天之内，他开发出了我所见过的零技术背景的人构建的最惊人的 UI。这让我想知道像 Tailwind 或 Material UI 这样的库还能存在多久。前者已经陷入困境， 后者……我们拭目以待。
当你退后一步，看看软件开发在短短两年内发生了多大的变化，这真是令人难以置信。
说到完全由 AI 生成的 UI，不能不提到代码质量——每个软件工程师在某个时候都会遇到的祸根。这甚至是一个很难提起的话题。仅代码质量就有无数的书籍，每个人都喜欢提出自己的解释。在软件工程聚会上提起设计原则，你就会聊到午夜。代码质量还引出了编程中另一个有趣的做法——结对编程。我在这里提到它，因为我认为这就是许多工程师获得关于代码质量的某些信念的方式。但结对编程是一种需要两个人类的做法。AI 也改变了这一点。想象一下，当你真正做的只是盯着代理做事时，试图进行结对编程。事实上，代理已经成为了你的结对编程伙伴。 那是好是坏？我从来不喜欢结对编程，所以如果你问我，我很高兴 AI 让它变得多余，但我也知道无数优秀的工程师正是因为结对编程而变得优秀。
但是。但是。但是……我的 IDE。我的 IDE 在哪里？我的代码编辑器在哪里？
2017年，我写了一篇关于编程已经成为流行文化的文章，互联网为之疯狂。那是我第一次体验病毒式传播。那是十年前的事了。至少在那之前的另一个十年，直到最近，我们都称自己为 coder。让计算机做我们想做的事情的主要 UX 是我们把东西输入文本编辑器或 IDE，然后编译和/或运行所说的代码。尽管编写代码可能并不是工作中最重要的部分——尤其是你越资深——这足以定义我们软件工程师，以至于我们俗称自己为 coder。今天，这种情况越来越少，如果你阅读 Cursor 3 的更新公告，你会看到重点是代理编排而不是代码本身。说实话，如今，很多时候我第一次看到我提交的代码是在 PR 中，在那里我查看我所做的更改，并决定它们是否都合格。那是一种非常不同的 UX，它真的改变了你如何看待你作为软件工程师的工作。在不到一年的时间里，我从 Webstorm 粉丝变成了 Cursor 粉丝。
但我知道你在想什么："太好了，所以你现在提交了一堆垃圾代码，有人必须重写"。让我说清楚。在为 Web 开发时——我在那里度过了我职业生涯的大部分时间——任何声称他们编写过企业级代码且从不需要更改的人都在说两件事之一：足够好变成了永远足够好；因此它永远不需要被 touch，或者他们过早优化，这意味着它的成本远高于所需。其他人都在撒谎。我们，人类工程师已经写了如此多的"烂代码"，以至于现在这是一个预期的经验法则，即软件每4年就要重写一次——无论是重大重构还是完全重写。声称 AI 只会使情况恶化的观点，忽略了 AI 带给我们的最明显的变化：无承诺的代码。十年前，重构或重写花费了我们数月的人力，可能是数年。而且都是手写的。今天代码生成得很快，它也会被重构和重写。也许一个月几次。这没关系，因为成本可以忽略不计。
说到重构成本，这里有一些总是 ends up at the very bottom of the backlog，永远不会被完成的事情：任何工程需求。在2024年的某个时候，我曾争辩说，如果向产品部门推销得好，工程需求可以被优先考虑，所有那些*"我们需要做这个和这个和这个，才能更好更快地做那件事"*都可以完成。我发现自己不再需要为了做到这一点而进行"政治杂技"了。不再是了，有了 AI 作为我的伙伴，因为就目前而言，对于涉及 AI 与不涉及 AI 的任务需要多长时间，还没有真正的定义或量化。这意味着如果一项任务用 AI 只需五分之一的时间，我就找回了很多时间来解决所有这些工程需求，甚至不必请求许可。我完成了所有与产品相关的工作，加上工程弹性工作，而且仍然比以前更快。每个人都是赢家。见鬼，我甚至可能并行做它们，在后台用几个代理，或者在吃午饭的时候。
我坚信，有了 AI，工作会做得更好更快，但前提是你必须有策略地使用它。
老实说，我可以继续列举 AI 改变软件开发的许多领域。虽然像 Tiobe 这样的语言流行度指数即使在几年前还有意义，AI 也使它变得几乎无关紧要。我经常看到人们用他们从未写过的语言构建应用程序，因此语言使用的多样性将会增加。那些已经在排名中占据既定位置的，将会变得更加强大，因为 AI 代理会倾向于默认使用它们。Python、Java、JavaScript 和 R 是其中少数几个，但很快我们可能会看到专门为 AI 代理创建的语言 boom——人类甚至不会阅读和审查的语言。代码审查已经在许多地方由像 CodeRabbit 这样的工具完成，所以这也是。忘掉代码审查礼仪吧。我很不情愿地说，但我发现 AI 审查比那些我以前看到的工程师写的要客观和温和得多。这应该让我们都 pause，不是吗？
2、所有没有改变的东西
但不要一秒钟就认为软件开发背后的所有基本真理都改变了。我发现我们都太急于对技术做出全面的陈述，而且在过去几年里，我们 certainly 对 AI 做了很多陈述，如果你在 LinkedIn 上花十分钟，你会以为你在2121年。但我们不是。差得远呢。
目前至少，我们编写的代码是一样的，区别更多在于谁编写的。但编码标准都是由我们工程师设定的。语言在很大程度上是由我们工程师选择的。这都是关于做我们做过的事情，至少做得和我们做过的一样好，但更快、更可靠、更可预测，但付出的努力更少。工业革命并没有导致质量更差的机器。恰恰相反。Mustang Mach-E 在每个方面都比 Ford Model T 好得多，而且它主要由机器人制造。软件也是如此，或者至少，同样的应该适用。
你认为在软件工程中吹毛求疵没有价值了吗？再想想。你与代理的对话非常需要正确的词汇、正确的技术细节。你越偏离它，产生的代码质量就越低，整体软件构建体验就越令人沮丧。
软件工程的希波克拉底誓言也并非更不相干了。如果有的话，它更加相关，而且坦率地说，它应该是每个agents.md文件的一部分。我们根本不能让软件退化成一堆不可靠的烂摊子。除非你过去三十年一直生活在 rock 下，否则软件无处不在，以至于你根本无法在没有它的情况下在社会上运作。无论年龄大小，人们在越来越多的国家需要使用应用程序来完成事情，而且这种趋势不会放缓。事实上，它只会加速。
这就是为什么，我仍然坚信简单是神圣的，保持软件简单对人类来说是伟大的，对 AI 来说更是如此。KISS 是我们应该在 AI 生成的代码中强制执行的核心软件设计原则。AI 既不是阿拉丁，也不是某种神奇的金鱼。它不能把过于复杂的烂摊子变成有效的东西。相信我，我试过，失败了。惨败。正如我之前所说：垃圾进，垃圾出。
3、我们还能写软件工程的书吗？
我已经休假一周了，在罗马尼亚各地旅行，试图回答自己这个确切的问题。我有几十本关于软件工程的书。其中许多已经过时了，有些需要 countless 附录，我想知道我是否想为那些活不过它们所制成的树的生命的书单做出贡献。
我觉得我们"还没到那里"。这是一场正在发生的转变，而且仅仅在两三年前才开始。我认为我们还没有达到稳定点。可能还需要五年左右，那又何必麻烦呢，对吧？
我们生活在软件工程前所未有的短暂状态中。我想记录它，但它值得写一本书吗？
拭目以待。有一点是肯定的。我们不会回到原来的地方。我们唯一能做的就是拥抱变化，充分利用它，乘风破浪，希望能在另一个稳定的周期中着陆，这个周期大约20年，以非常不同的、非常值得为下一代记录的方式完成软件开发。
原文链接: I Started a Software Engineering Book, but AI Changed the Plot
汇智网翻译整理，转载请标明出处