Jad Naous 与 Martin Casado：AI 编码与生产运维

a16z 普通合伙人 Martin Casado 邀请 Grepr CEO Jad Naous 讨论 AI 编码，以及更困难的生产系统运维问题。两人曾在 Stanford 同一个研究组学习。

Naous 回忆自己曾在 Stanford 研究 OpenFlow、硬件安全和 SHA-3 实现，之后在 MIT 研究应用安全。他早期创办的一家公司尝试回滚受攻击应用的状态，再在修补后的版本上重放；他说这个问题非常困难。

后来他在 AppDynamics 工作，曾与 Casado 一起从事风险投资，又在 Apply 担任首席产品官。离开后，他采访了工程负责人，了解他们面临的成本和问题。

2023 年，许多负责人试图降低基础设施支出，其中包括可观测性。Naous 说，客户将基础设施支出的约 5% 至 20% 用在可观测性上，以此换取可靠性。

据他描述，随着微服务和遥测数据增多，数据量与成本不断上升，而每多花一美元带来的可靠性提升趋于平缓。Grepr 最初尝试在上游提取有用信号，降低下游遥测成本。

Naous 说，Grepr 起初帮助客户减少遥测支出，声称在他描述的配置下最高可降低 90%。公司现在正在构建另一层，把提取出的信号交给 AI 系统，用于故障排查和可靠性工作。

Casado 问，在一家约十人的公司里，AI 给工程工作带来了什么变化。Naous 回忆了从自动补全到 agent 的转变，并说高效的工程师学会了如何使用不同模型和框架。

不同工具管理上下文、子 agent 和提示词的方式不同。Naous 举例说，需要限制某些编码 agent 启动大量昂贵的研究 agent；了解工具的行为也成为工作流的一部分。

Naous 说，他的小团队里，优秀工程师变得更加高效，因为他们能够理解复杂性、拆分工作并评估结果。他提醒说，这是他在小规模分布式系统团队中的经验，并非针对数百名工程师的研究。

例如，查询转换层需要先理解查询的含义，再向模型解释需要什么转换。Casado 和 Naous 区分了代码语法与系统行为，后者的一些细节取决于配置和数据。

Naous 介绍自己的配置：通过 Windows Subsystem for Linux 在 Linux 中运行 Claude Code。他通常同时使用三四个会话；再多就容易跟丢上下文。

他的团队现在审查的 pull request 多了很多。Naous 说，审查过程更加关注测试和预期输出，工程师也继续互相审查工作。

他使用具有持久会话的命令行 agent，并让另一个审查者质疑设计和改动。实施前，他会亲自检查产品和设计文档、算法以及拟议的分工。

设计合理后，他让 agent 在适当的地方并行实施。他说，最终必须把工作整理成有序的变更序列，让人可以逐项审查，否则改动会变得难以管理。

Naous 给出一个生产代码的例子：自动将半结构化日志事件中的字段提升为数据湖中的列，以便高效查询。这需要理解元数据提交和多个写入者之间的协调。

他说，这项近期工作大约花了他十天，而过去一个人可能需要六个月。这是他对特定项目的估计，并非受控的生产率测量。

Casado 问，能写代码是否意味着理解代码在真实流量下的行为。可用性、正确性和性能取决于访问模式、数据和设计选择，而这些未必能仅从源代码看出来。

Naous 将问题描述为：能否把运维信息转换成 AI 可以推理的形式。Casado 进一步问，生成的代码能多好地预测行为，agent 又能否调查一个正在运行的系统。

Naous 说，团队为流处理器定义了性能基准和约束。在查询优化中，agent 最初漏掉了一个重复表达式；他指出问题后，agent 提出假设，并结合代表性查询和基准进行改进。

另一些问题，例如应分配多少内存，则需要在生产环境中实验，而不能只根据代码猜测。Naous 说，agent 可以识别不确定性并寻找信息，但生产系统仍会出现意外行为。

Casado 问到把日志交给 AI 做运维。Naous 说，Grepr 的方法是先检测变化或早期信号，而不是让模型从一个滞后的告警出发，在整个复杂系统中反向寻找原因。

新的错误消息、耗尽的连接或空的资源缓冲区，都可能是值得调查的早期迹象。信号仍需评估：流量模式变化并不自动意味着生产事故。

Naous 说，这种方法已经在公司内部和少数客户环境中试用。他称，有几次被忽略的早期警告后来发展成事故；他没有提供全面评估结果。

被问及 AI 是否能运行分布式集群时，Naous 说它可以开始参与部分调查流程，但还不能完全接管。人类运维人员常常掌握遥测数据中不可见的上下文。

他的目标是让系统和相关变化更加可观测。Casado 确认，识别异常模式的是一个独立检测系统，随后 AI 才进行调查，而不是依赖生成模型预测每一种变化。

AI 可以检查新消息出现在代码的什么位置、此前是否发生过，并验证关于其重要性的假设。Naous 认为查询优化可能接近自动化，但完全运行分布式集群还没有做到。

Casado 仍不确定运维是否像代码生成一样有界：罕见异常和工作负载变化会产生极其庞大的可能状态空间。他指出，运维人员往往宁可超额配置资源，也不单纯依赖巧妙的预测。

Naous 更为乐观，他假设能够收集到足够的遥测数据。他并不主张把原始日志扔给模型要答案，而是希望它规划调查、运行实验，并用证据比较可能的因果链。

Casado 重新概括这个提议：即使故障种类繁多且罕见，用于调试的步骤可能更容易管理。Agent 将遵循调查流程、利用信号缩小范围，而不是提前预测所有可能的故障。

Naous 说，团队也在安全领域测试类似方法，利用行为变化生成并验证可能的因果链。Casado 认为安全可能更难，因为攻击者会有意寻找罕见且可利用的状态。

Casado 用固定长度音乐文件的庞大可能数量说明，有限状态空间也会迅速变得难以实际处理。他说，试图解决运维问题的公司似乎比做代码生成的公司遇到更多困难。

Naous 同意运维更难：工作负载会变化，软件可能在无人通知时部署，故障还可能涉及隐藏状态或死锁。知识也分散在许多人那里。尽管如此，他希望 AI 系统能逐步处理更复杂的层次。

Casado 认为，训练数据是对世界的一种有用简化，而不是世界本身。代码描述一个系统，但系统运行时可能出现需要实验或模拟才能发现的行为。

Naous 回应说，agent 不必立即给出答案：它可以规划步骤、收集信息、编写代码或模拟问题的一部分。他们没有确定这种方法能在重要维度尚未建模的问题上走多远。

被问到风险投资时，Casado 说，人际关系、获得投资机会以及帮助创始人招聘是工作的核心。他见过 AI 做出出色的分析，但认为人际关系部分更难替代。

两人回到 AI 的数字训练环境与物理或运维世界之间的差距。Naous 乐观地认为系统最终能处理更多领域；Casado 则预计现实复杂性和经济成本会拖慢进展。

Casado 以自动驾驶为例，说明应对真实世界变化需要多少时间和投资。他预计 AI 在受限领域会迅速普及，而在解决方案必须应对现实世界各种变化的领域进展会更慢。

Naous 提出另一种可能：人们可能改变环境，让自动化切实可行，例如高度自动化的仓库。Casado 同意，限制环境可以改善通用但成本高昂的工具的经济性。

Naous 最后分享一个客户故事。Grepr 介绍 AI 可靠性工作时，一些买家马上关注的却是它宣称的遥测账单节省，因为这是他们今天就能定价和购买的收益。

两人都认为，编码工具的价值格外容易看见，而 AI 运维仍处早期。对话结束时，核心问题尚无定论：agent 能从编写代码走多远，进而调查和运行复杂系统？