What Top AI Labs Are Really Doing With Observability

Datadog 联合创始人 Olivier Pomel 说，AI 让顶级工程师几天能独立重写整个系统，原本要 6 人半年才能做完。

AI把写代码变成小事，重构组织才是大事

Olivier Pomel 是 Datadog 联合创始人。他与 Alexey 在 2010 年创办公司，Datadog 于 2019 年上市，如今约有 8,000 名员工、20—25 个产品。从云基础设施监控切入，到做成覆盖开发、安全和运维协作的平台，Pomel 经历过一家公司怎样从小团队长成大型组织。更重要的是，他现在正面对一个新问题：当 AI 让几个人能做完过去几十个人的活，公司究竟该怎么重新安排人、产品和决策？

这期回答了 7 个问题：

1. 当一个人几天能完成过去六人半年的工作，工程团队还该怎么配置？
2. 为什么再创新的产品，也可能必须先借用一个“老品类”的名字才能卖出去？
3. 企业该追随客户已经显露的需求，还是在需求出现前冒险下注？
4. CEO 怎样绕过层层汇报，看到客户和员工真正经历的问题？
5. 文化不写在墙上，靠什么在 8,000 人规模下持续生效？
6. AI 时代到底需要多少工程师、产品经理、设计师和安全人员？
7. 为什么“更快招聘，也更快解雇”可能比等待完美候选人更理性？

被问到 Datadog 内部使用 AI 后是否已经获得显著投入产出回报时，Pomel 讲了一件足够让工程负责人坐直的事：几个月前，联合创始人 Alexey 站在全体工程团队面前宣布，两季度后，“我们不再写任何代码”。这当然不是让工程师停工，而是给组织定下一个方向：代码生产方式要倒过来。

转折发生在去年 12 月。模型能力跨过一个门槛，又正好赶上假期，不少员工有时间做个人 hack project，也就是不受正式项目流程约束的试验。结果，顶尖开发者开始独自重建完整系统。过去不是不能做，只是通常要六人团队做六个月；现在，一个人几天就能完成。Pomel 的原话是："And we saw, like literally, absolutely excellent developers, like not beginners, but people rebuild whole systems in a couple of days alone that were absolutely amazing."（我们亲眼看到，绝对顶尖的开发者——不是新手——一个人几天内就重建了完整系统，成果极其惊人。）

这意味着，工程部门最稀缺的东西不再只是“能写出多少代码”。当实现成本下降后，真正的约束变成：团队有没有发现足够大的问题，能不能把一个模糊机会拆成值得让机器执行的任务。过去一个方向要押上一支八人团队，现在两三个人就能先试。这会让公司同时探索更多路线。

但 Pomel 也给“再也不写代码”泼了盆冷水。未来仍会写代码，也仍会重写代码。改变的不是代码消失，而是比例翻转：过去主要靠人手写、偶尔做自动化；未来主要靠自动化、必要时再手写。把口号理解成裁掉所有工程判断，反而会错过重点。

被问到 Datadog 怎样从早期产品走到今天的 observability，也就是帮助团队持续看见和理解系统运行状态的产品类别时，Pomel 提到公司最初犯过一个典型的“产品人错误”：他们觉得 monitoring，也就是监控，是 1990 年代遗留下来的老词，又旧又无聊，于是故意不用它。

Datadog 最早把自己称为供 DevSecOps 协作的“data platform”。DevSecOps 指开发、运维和安全团队围绕同一套系统协同工作。这个说法听起来更先进，也更贴近他们的愿景：别再让开发和运维各拿一套工具、互相甩锅。但客户听完并不自然地联想到一笔预算，客户的老板也不知道该把它归到哪项采购里。

后来，Datadog 改称自己做“infrastructure monitoring”，即基础设施监控。产品本身并没有变得保守，变化的是商业语言。Pomel 说："People love the idea of a new thing, but they have no idea why they should pay for it."（人们喜欢新事物的概念，但根本不知道为什么要为它付费。） 一旦挂上基础设施监控这个名字，买方马上知道：这是一类真实存在、必须采购的产品。

这意味着，创新不必连市场语言也从零发明。预算、采购流程和管理者心里的分类法，往往比技术变化慢得多。先进入一个对方已经会买的抽屉，才能把产品送进公司；进门之后，再用不同的能力扩大那个抽屉的边界。Datadog 在 2010 年就优先支持云基础设施，当时不少大公司仍把 Amazon 云服务当“玩具”，后来云市场爆发，才证明这个切口的规模。

边界也在于，旧品类名称能帮产品成交，也可能遮住它真正不同的结构。Datadog 最初排斥“monitoring”，并非没有道理：它确实不想做旧式、分工割裂的监控工具。问题不是该不该借旧词，而是借完之后，产品有没有能力长成比旧词更大的东西。

被问到一家拥有约 20—25 个产品的平台公司，怎样决定下一个产品该做什么时，Pomel 给出的答案并不神秘：先看客户已经在做什么。Datadog 是平台型产品，客户会在其上搭建扩展，形成自己的工作流，也会把它接进各种内部系统。那些真实存在的接法，会暴露客户卡在哪里，也会告诉 Datadog：用户认为这个平台下一步该出现在哪个位置。

Pomel 说，公司会大量构建那些“看见客户已经在做”的事。这里的重点不是客户在问卷里说“我想要某功能”，而是他们已经通过绕路、手工流程或自建扩展来解决问题。行为往往比意见更贵，因为行为已经付出了时间和维护成本。

但 AI 打破了这条相对稳妥的规律。技术变化太快时，等客户群体中的需求自己浮现，窗口可能已经过去。Pomel 的表述很直接："you just can't wait to see the demand materialize from the customer base."（你就是不能等着客户群体里的需求自行成形。） 因此，公司必须提前做更多尝试，即使客户还没有明确开口。

这意味着，产品决策会变成双速系统。成熟领域里，客户工作流是最好的导航：它能降低误判概率。技术突变领域里，则要接受没有现成导航，只能用更多小赌注换取学习速度。Pomel 也没有把提前下注说成必胜策略。相反，他明确承认：这种项目是公司自己想出来的，因此更容易错。主动下注的回报可能更大，账单则是更高频地承认判断失误，并及时收手。

被问到他为什么还深度介入细小产品决策，以及怎样避免高层只看到漂亮汇报时，Pomel 说了一套很朴素的做法：持续接触原始材料。不是只看产品负责人总结的“客户反馈”，而是去看真实支持请求；不是只听销售主管说“客户很积极”，而是读销售通话逐字稿；不是只收员工满意度分数，而是看调查评论里的原句。

他现在仍会读完所有员工调查评论。其他材料规模太大，无法全部读完，就抽样。抽样不是为了制造全面监控，而是为了保留一个校准仪：管理层的描述是否和一线现实对得上。Pomel 说，接触这些材料后，"you get a good sense for what the fabric of the universe actually is in the company"（你会真正感知到公司内部这张“现实之网”究竟是什么样。）

如果他在邮件或 Slack 里看到异常，不会先要求一份格式完整的复盘文档，而是直接回一句：“我不明白发生了什么。”这会产生两个效果。收到消息的人先会意识到，CEO 为什么会看到这条具体反馈；更重要的是，整条管理链会开始向下看，而不只是向上猜老板想听什么。因为下一次被问到时，靠包装过的摘要不够用了。

这意味着，高层接触原始信号，不只是让自己“更了解业务”，还会改变中层的注意力分配。管理者的职责不再是把问题修饰成能汇报的版本，而是精确知道自己管辖范围内什么在工作、什么没工作。边界也很明确：谁都不可能读完所有材料。关键不是全知全能，而是不能完全失去被一线事实纠正的机会。

被问到 Datadog 为什么没有像许多公司那样，把文化写成五条价值观、八条原则时，Pomel 的回答有些反潮流：公司从未正式写下文化准则。他们认为文化是从高层往下流动的，不是先写在墙上，再希望员工照着执行。

Datadog 的做法是让管理层通过日常行为示范，并在三个最有分量的节点执行标准：招聘、晋升和解雇。Pomel 总结得很直白："we exemplify the culture, we hire, we promote, we fire based on the culture, and today that still works."（我们以身作则体现文化，并据此招聘、晋升和解雇；直到今天，这套方法仍然有效。）

这句话的分量在于后半句。文化不靠会议里重复，而靠员工观察组织到底奖励谁。一个人因为怎样做事而被提拔，另一个人因为怎样做事而被淘汰，这比墙上的任何词都更像真实规则。如果公司口头说重视坦诚，却总是提拔只会报喜的人；口头说重视客户，却容忍长期无视客户抱怨的负责人，那么文件写得再漂亮，也只会变成装饰。

Datadog 现在约有 8,000 人，还需要招聘和培训约 3,000 人。这正是“不写下来”最受压力测试的时候。Pomel 并没有宣称永远不需要书面化；管理层每年都会重新讨论，今年是否该写。他只是说，截至目前，现有做法仍有效。这意味着文化不是一次性制度选择，而是随着规模变化反复验证的管理问题。文档可以有，但它不能替代真正的用人决定。

被问到 AI 会不会改变团队领导方式和招聘结构时，Pomel 没有给出一个乐观的“效率提升百分比”，而是承认组织正在经历痛苦调整。过去一年里，“写代码或不写代码”的方式已经变了三次。今天看起来合理的协作流程，可能几个月后就显得笨重。

他已经看到小团队可以做得更多。以前要八个人探索的方向，现在可能两三个人就能启动。这让公司可以承担更多尝试，也能更快发现一条路走不通。但真正棘手的问题紧随其后：如果工程师借助 AI 的产出陡增，一个产品团队还需要多少产品经理、设计师、安全人员和工程师？管理者应该管更大团队，还是更小团队？安全检查应当嵌入开发过程，还是留在独立环节？

Pomel 的回答是："nobody knows what the process looks like a year from now."（没有人知道一年后的工作流程会是什么样。） 这不是谦虚，而是对现实的描述。他明确说，公司正在调整组织，这件事会痛苦，而且已经痛苦地发生。

这意味着，AI 转型首先不是采购几个工具、要求员工多用一点的问题，而是组织设计实验。岗位比例、交接方式、审批环节、管理跨度，都可能要反复重估。过去公司常先画出目标组织图，再按图招人；眼下更合理的顺序可能相反：先让不同配置的团队跑起来，看哪里速度提高、哪里质量下滑、哪里责任变模糊，再调整结构。

边界在于，没人知道终局团队长什么样，并不等于可以不做调整。Pomel 的态度是方向已经清楚：自动化比例会更高，小团队的能力会更强；但具体配方尚未被发现。任何把一年后组织图说得过于确定的人，可能只是把未知画成了方框。

被问到如果回到 15 年前，最想提醒自己什么时，Pomel 给出的不是融资技巧，也不是产品方法，而是“招聘和解雇都该更快行动”。他反复看到创始人卡在同一种状态里：知道自己需要销售负责人，却因为还没遇到“完美画像”，于是拖几个月甚至更久。

Pomel 的建议听上去很硬：找到一个看起来不错的人，就尽快雇；如果后来证明不合适，就解雇，再开始下一轮。原因不是他认为用人可以草率，而是事前信息天然有限。尤其是销售负责人这类角色，简历、面试和推荐信能说明一部分能力，却很难替代一个人在具体公司、具体产品和具体市场里的实际表现。正如他说的："It's too hard to know anyway before you've tried."（反正不亲自试过，事前根本太难判断。）

他承认自己早期就犯过相反的错：为了做出完美招聘决定而陷入瘫痪。第一次解雇时，创始人又常常担心全公司会反感自己。但 Pomel 观察到，其他员工更常见的反应是：“你为什么拖这么久？”这说明，不匹配的人选不会因为管理者迟疑而自动变得匹配，团队反而会长期承担成本。

这意味着，人才决策应被设计成提高学习轮次的机制。更快做出一个可纠正的判断，往往比无限延长判断期更有机会找到合适的人。这里的前提不是盲目扩招，更不是把人当成随时可替换的数字。它要求管理者同时具备两种能力：在证据尚不完整时敢于下注；当事实已证明不匹配时，也敢于承担结束关系的责任。Pomel 早期在招聘和解雇两端都慢，正是因为只做前者而回避后者，快速试验才会变成空话。

“编码不再是瓶颈，团队的野心才是”和“AI 的真实难题不是提效，而是没人知道团队配方”，说的是同一件事：AI 提高的不是某个岗位的局部效率，而是组织提出问题、分配责任和调整协作方式的速度。一个人几天重建过去六人半年的系统，并不自动等于公司变强；如果管理者仍按旧的团队配置、旧的审批链和旧的目标管理来运转，新增产能只会堵在组织里。

Datadog 的方法也不是试图提前算准未来。它先用“infrastructure monitoring”这种客户已经会购买的语言进入市场，再通过客户工作流判断成熟领域该做什么；当 AI 让需求尚未来得及显形时，则接受更频繁地下注和犯错。与此同时，Pomel 让管理层读支持请求、销售逐字稿和员工评论，是为了不让公司只根据修饰过的汇报做判断。

这也解释了为什么“把招聘当作可逆试验”并不只是人事建议。产品、组织和用人其实都面对同一个约束：事前不可能获得完美信息。你能做的是让自己尽量接近真实材料，让一次决定的学习成本更低，并在证据变化时及时调整。对正在带团队、做产品或推动 AI 落地的人来说，最该盘点的或许不是“我们有没有用上 AI”，而是：一线问题能不能抵达决策者，团队能不能在小范围内快速验证，以及那些已经不适配现实的流程和人，是否仍被“再等等看”拖着往前走。