Instacart CTO：AI 让我们不再为技术债焦虑

Instacart 提出了一个颇具挑衅性的问题：假如你工程师团队今天所做的大部分工作，实际上本应由机器来完成呢？

在 VB Transform 2026 大会上，首席技术官 Anirban Kundu 指出，开发团队仍在将时间浪费在令人疲惫、重复性高、工作量巨大的任务上；这些任务理应由 AI 代理承担，从而让人类专注于需要判断力、意图理解与异常处理的问题。 

事实上，在 97% 的情况下，Instacart 的开发者甚至不再阅读代码。 

Kundu 表示：“过去，战术层面的工作是编写代码。而未来最底层的战术工作，将变成‘你如何在 AI 系统中导航，以获得你想要的结果？’”

AI 生成代码，执行“相当严肃的评估（evals）” 

这并不意味着人类永远不查看代码；AI 代理承担了绝大部分代码生成与样板代码编写工作，尤其是在新项目中——这些项目的代码每周都会被生成或重新生成。 

Kundu 表示：“这样做的好处在于，我们不再关心技术债了。那些未被激活的组件会被直接剔除，然后重建，其方式类似于我们过去编写汇编代码或目标代码的方式。”

那么为何不是 100%？剩余的 3% 涉及遗留系统、合规性要求以及对延迟高度敏感的系统和工作流，或者源于大量“已死亡”、非活跃或半活跃的代码。这些情况仍需人类细致关注。 

不过，Instacart 正逐步“平滑化”这些部分，通过一个恰如其名的项目 Atoms 将系统拆解，再以更清洁、更模块化的方式重建。Kundu 的团队从“单体架构（monoliths）”入手，正转向以远程过程调用（RPC）驱动的架构。 

但评估仍是整体面临的重大挑战之一。当代码由 AI 生成时，人工代码审查的相关性便大幅降低——正如 Kundu 所指出的，“代码行本身将是正确的，语法也将符合你的预期”——因此目标是转向一种“意图模型（intent model）”，即培训开发者，使其能从意图角度向不同模型提出恰当问题。 

随后，评估独立进行：每月运行约 7,000 次自动化评估，该系统每月响应 8,000 多次实时开发者查询，准确率约为 99.9%。

识别出人类直觉可能遗漏的“卡顿（hiccups）”

与此相辅相成的是，Instacart 构建了一套基于自身多年事故记录与根本原因分析训练而成的代理式站点可靠性工程（SRE）系统，而非依赖通用故障数据。该团队并未抽象地教导模型生产环境中断如何发生，而是向其输入 Instacart 系统随时间推移实际崩溃的具体方式，以及人类诊断与修复这些问题的具体方法。

结果，该公司在检测与缓解生产问题方面的准确率从约 60% 提升至超过 90%。 

Kundu 举了一个 Instacart 内部工具 Blueberry 的例子。这款 AI SRE 同事监控着约 200 个 Slack 频道，跟踪各类信号，并在人类对话与告警之间寻找模式。 

在一次事故中，一个由 EBS 卷支撑的数据库分片在一段时间内出现了“卡顿”。人类团队并未立即怀疑是 AWS 磁盘问题，而是“显然手忙脚乱”，试图弄清为何该特定分片出现异常行为。 

但事故发生约 20 分钟后，Blueberry 在 Slack 上发帖，指出某一具体波动，并将其关联至一个名为“roulette”的类特性开关（feature-flag-like）系统——该系统当时配置不当。“它本应按此节奏逐步上线，[但] 实际上线量过大，”Kundu 表示。

Blueberry 找出了问题根源，团队随即解决了该事故。“人类是否能同样迅速地解决？我认为问题在于人类直觉反而会略微拖慢我们的速度，”Kundu 表示。 

人类倾向于默认采用以往见过的模式，继而转向调试；Kundu 将此称为“第一大脑—第二大脑式思维”。但 Instacart 的代理式 SRE 实际上“在全面审视所有信息并判断何者重要、何者不重要方面，能力更为全面。”

重新定义工程师的职责

展望未来，工程师最底层的战术性工作将是驾驭 AI 系统：设计并监督评估流程；协调多个同时进行的实验与功能；管理测试所受限制（例如前端流量有限）；判断何时升级问题；识别边缘案例及潜在故障点。

在 AI 时代，领域专业知识也在被重新思考。Instacart 不再将变更通过单一“负责人”团队（即唯一可触达并修改代码的团队）进行瓶颈式管控，而是将领域知识嵌入定义与规格说明中，供任何团队使用。 

Kundu 表示：“我们曾生活在一个世界里，某个小组或某支工程团队是唯一能触达代码并进行修改的团队。我们正努力迈向一个代码完全在各团队间实现民主化的世界。”