译者 | 刘汪洋
审校 | 重楼
想象一下，完全沉浸在编程氛围中，甚至忘记了代码的存在。不用敲键盘，只需让 Cursor 和 Sonnet 帮你搞定一切。遇到 bug 时，你不去排查问题，而是把错误信息丢给大语言模型（LLM ）然后复制粘贴修复方案。代码已经超出你的理解范围，但它居然还能正常运行。这就是 OpenAI 创始成员 Andrej Karpathy 所说的Vibe Coding（氛围编程）。
Karpathy 把这描述为周末小项目的有趣尝试，但现实中，Vibe Coding——大量依赖 LLM 编写代码——已经大范围出现。谷歌报告 AI 生成了其 25% 的新代码，在行业的许多领域，这个比例可能更高。很多人爆料说，包括 HubSpot 在内的公司里的软件工程师已不能自己写代码，只能通过提示词指导 LLM。我认为，Vibe Coding 是构建软件的未来。
但当 AI 生成的代码在生产环境中出 bug 导致服务中断时会怎样？接下来，我来探讨这个问题，并分享一些让你的工程团队做好准备的想法。
Vibe Coding 很有趣，但遇到服务中断就没那么好玩了
拥有熟悉代码库的技术高手至关重要。强大的工程组织会通过在团队成员间共享知识，确保没有工程师成为单点故障。
故障发生时，通常会找来了解受影响部分的工程师快速解决问题。但随着越来越多的代码由 LLM 生成，深入理解代码库的工程师会越来越少，这会让服务中断更难诊断和修复。
加州大学伯克利分校的博士生 Shreya Shankar 在一条广受关注、浏览量超过 3 亿的推文中一针见血地指出："为啥没人讨论盲目集成 AI 生成的代码，会让值班工程师的工作变得多糟糕？LLM 是出色的代码编写者，但却是糟糕的工程师。"现在服务中断的成本高达每分钟 14,000 美元，团队可不能在解读 LLM 写的代码上浪费时间。
Vibe Coding 遇上Vibe 故障处理
AI 生成的代码不会消失，有 61% 的工程团队正在使用生成式 AI，这一趋势只会更强。下面是如何为未来的故障管理做准备。
先用 AI 驱动的故障管理工具，比如 Rootly 或 PagerDuty Advanced。这些工具负责处理故障的后勤工作——自动创建沟通渠道、为不同相关方起草更新，并管理事后分析。它们也开始用 AI 将当前故障与历史案例匹配，帮你快速找到类似情况及解决人员，从而缩短平均解决时间。
接着，升级你的故障修复方式。如果能用一个工具精确找出根本原因并提出修复方案，会怎样？这正是新一代 LLM 驱动的故障解决工具，也就是 AI-SRE 助手，像 Sentry AI 和 Datadog Bits AI正在做的事情。
这些工具处理 SRE 通常会处理的数据——错误日志、指标、应用跟踪...同时还摄取非结构化的人工生成数据，如 Slack 讨论、操作手册和事后分析。它们能快速自动分析根本原因，突出显示触发问题的提交，可视化其对系统指标的影响，并追踪导致服务中断的故障链。这样，当值班人员接到通知打开电脑时，根本原因分析已经摆在眼前了。
更厉害的工具不仅诊断问题，还提出解决方案。你可以在部署前审查、讨论和批准修复方案，或者让工具自动处理一切。可以理解，一些运维工程师对此持怀疑态度。如果 LLM 出现幻觉给出一个让情况变得更糟的修复方案怎么办？如果没有回滚功能怎么办？灰度部署变更可以降低风险，但这只是众多考虑因素之一。AI 驱动的故障解决方案很有前途，但也带来了一系列新挑战。
不过，自愈工具并不新鲜：它们至少已存在十多年了。Facebook 在 2011 年引入了 FBAR 来自动化机架维护。Dropbox 在 2016 年推出了 Naru 来处理服务器故障、警报和修复。但这些是基于预定义规则的确定性系统，显著降低了出错的可能性。
在 LinkedIn 担任高级 SRE 期间，我共同设计了一个用于分布式基础设施的自愈机制，该机制用机器学习进行根本原因分析和修复，尽管它从未完全实施。随着 LLM 的兴起，这种方法正在成为现实，我很兴奋能亲眼见证。这一领域的公司正在取得实质性进展。竞争越来越激烈。市场上至少有 20 家参与者，风投资金源源不断涌入。进入 Vibe 故障处理时代！没错，这个词是我刚编的。
打不过就加入
随着生成式 AI 给开发人员的工作效率带来显著提升，这一趋势还越发明显。那么为何不拥抱 Vibe 故障处理呢？当服务中断发生时，只需悠闲地喝杯咖啡... 让你的 AI-SRE 助手想办法修复你那些 "Vibe Coding" 同事的 bug 吧。
原文标题：Vibe Coding Is Here — But Are You Ready for Incident Vibing? ，作者：Sylvain Kalache
