Pragmatic Engineer 刊发获奖文章：工程师在 Tano 月度 PR 产出达 PostHog 时期 11 倍

Pragmatic Engineer· Gergely Orosz·2026-11-04 00:58· 32 分钟前AI 评分69

软件工程正在如何改变：两个时代的故事

AI 导读

The Pragmatic Engineer 全文刊出征文挑战获奖文章，工程师 Neil Kakkar 讲述加入 AI 原生创业公司 Tano 后月度 PR 从 8-20 个升至 200+，约为 PostHog 时期的 11 倍。

正文 · 原文

开始之前：我本周在旧金山，以下现场活动还有少量名额（需注册）：

• 周三（11 月 4 日）：The Pragmatic Engineer Unplugged 在标志性的 SFJAZZ Center 举行。嘉宾为 Diogo Almeida（Jev 的创造者、ChatGPT 的共同发明者）和 Bryan Cantrill（Oxide 联合创始人兼 CTO）。

• 周四（11 月 5 日）：System Update 在 The Howard SF 举行。嘉宾为 Karri Saarinen（Linear）、Kath Korevec（OpenAI）、David Cramer（Sentry）和 Adam Rogal（DoorDash）

另外，本周四 The Pulse 将停更一期。下周恢复正常排期！

今年九月，The Pragmatic Engineer 迎来五周年，我宣布了一项征文挑战，邀请读者撰写科技职场和我们的项目发生了哪些变化，最佳文章将获得 10,000 美元大奖。

我们收到了 125 篇投稿，涵盖了广泛的观点和经历。非常感谢所有参与者。在今天的文章中，我们全文刊发获奖作品。

恭喜软件工程师 Neil Kakkar！我们非常欣赏 Neil 收集的关于他自身产出随时间变化的大量数据。Neil 是一位常驻伦敦的开发者，拥有九年专业经验；他曾在 Google 实习，并先后在 Bloomberg、Posthog 和 Tano 担任软件工程师。他的前东家 PostHog 是一个开源项目，这对收集历史数据想必很有帮助。

在后续文章中，我们将重点介绍亚军作品，并链接那些因展现出的努力和有趣想法而令我们印象深刻的文章。

接下来，交给 Neil。他涵盖的内容包括：

1. 两个交付时代。直到去年，他每月合并 8 到 20 个 PR。但自从加入一家 AI 原生创业公司后，Neil 现在每月交付 200+ 个 PR，大约增长了十倍。

2. 消失的旧约束。不再有沟通开销或代码审查。代价是：行动更快，也更容易出问题。

3. 出现的新约束。过多的上下文切换（thrashing）、失去共享上下文、更难把握节奏、对设计的关注减少，以及对 AI 计划限额的担忧。

4. AI 如何改变软件工程。每个人都需要接受 AI 才能在工作中获益，鼓励实验会带来不同，许多现有技术和流程在变革下不堪重负。

过去八个月，我一直在一家 AI 原生创业公司工作。在加入 Tano 之前，我在 PostHog 工作了四年，那是一家快速发展的前 AI 时代创业公司；我的职业生涯始于 Bloomberg，一家大型金融科技私营公司，我在那里待了三年。这三个工作场所各不相同：Bloomberg 规模庞大，有 20,000 人，流程非常明确。PostHog 规模较小，我加入时约 10 人，现在有 200 人。在 Tano，我是第一位工程师，现在我们总共约 10 人。

在每一份工作中，我都看到了速度和文化的差异所带来的不同，而最近，我也看到了文化需要如何改变才能跟上 AI 的步伐。

为了佐证，我使用了关于我在 PostHog 和 Tano 工作的深入统计数据。我还有一些来自 Bloomberg 的非常粗略的数字。到目前为止，我在 Tano 编写的代码和提交的 PR 比在 PostHog 多得多，而这在很大程度上要归功于 AI。推动这一转变的是工程文化。

在开始之前先声明一点：PostHog 的统计数据来自前 AI 时代。我一直在关注他们的发展历程，PostHog 现在可以说是最“AI 化”的公司了，产出正在显著增加。在本文中，我将其视为卓越工程工作的“前 AI 基线”。Tano 是一家快速发展的 AI 原生初创公司，在 AI 智能体出现之后创立。

1. 两个交付时代

让我们从一些原始数据开始。我在 Tano 提交的 PR 数量是在 PostHog 的 11 倍，而在 PostHog 提交的 PR 数量是我在 Bloomberg 的 2.4 倍。

在 Bloomberg 时，我刚刚开始职业生涯，所以我不是最快的，而转到 PostHog 让我大开眼界，真正见识到了快速发展的初创公司文化是什么样子：我们被鼓励承担责任、快速交付、倾听客户意见，并尽快解决他们的问题。

在 Bloomberg 和 PostHog，代码的标准都很高：所有代码都必须经过同行评审，而随着我成为高级工程师，我花了很大一部分时间评审代码。

PR 是一个很容易被操纵的指标，但我并没有试图操纵数字，所以它们是对所完成工作的诚实反映。以下是我所做的所有工作的详细信息，以证明 11 倍 PR 倍数的合理性。

我做过的工作

我作为全栈软件工程师加入 PostHog，在产品各环节工作，从数据摄取管道到为 ClickHouse 上的漏斗和留存优化分析查询，将其扩展到处理十亿级以上事件规模，最终从零开始构建实验产品。后来我领导 Feature Success 团队，在那里我们构建了两个新产品：调查和早期访问功能，同时改进了实验和功能标志。

我作为创始工程师加入 Tano，专注于与 PostHog 类似广度的产品，但全部压缩在八个月内完成，而不是 45 个月。我构建了我们的新联盟平台，使我们的内容监控系统效率大大提高，并完成了一些大型迁移，比如将整个智能体架构迁移到一个具有持久记忆、更好的工具和卓越可观测性的新系统。

以下是我在两家公司所做工作的总结：

我如今的工作方式

在 PostHog 直到 2024 年底，AI 的应用程度仅限于标签补全。它非常适合自动化重复性测试用例等琐碎工作，但距离今天无需人工输入即可构建整个功能的自主智能体还有很长的路要走。

今年我加入 Tano 时，Claude Code Desktop 已经存在，并且拥有非常好的智能体支持，几乎不需要太多人工干预就能构建出完整的功能。我一直没能习惯命令行界面（CLI），所以坚持使用 Claude Code Desktop。我非常喜欢它集成的浏览器，并让 Claude 控制它，而不是用我自己的浏览器——如果 Claude 接管并阻止我工作，那会非常烦人。在过去一年里，桌面版在功能上已经赶上了 CLI，并且拥有一些 CLI 不直接具备的功能，比如浏览器。

在任何时候，我都在同时处理 3-5 件不同的事情。我会先过一遍计划，但大多数时候会让智能体一直运行，直到它准备好一个 PR 并处理完评论。然后我会通过一个易于理解的 HTML 产物来检查它做了什么——Claude 被指示在每个 PR 中都生成这样的产物。它看起来像这样：

我的智能体可能需要运行 1-2 小时。这是为了端到端地构建一个完整功能，考虑到评审、验证和截图等所有机制，我的智能体通常需要这么长时间。如果我正在做一项需要调查大量数据、处理图像和视频，或者朝着某个目标迭代的研究任务，运行时间甚至会更长。我还没有使用云端智能体，因为原生的 Claude 智能体似乎太有限，无法像在本地那样运行任务。

大公司已经投资构建自己的云端智能体，这些集成已经存在。这对他们来说合理，但在我们的规模下——目前还不太适用。

2. 消失的旧约束

如果没有 AI，Tano 每月多出十一倍的 PR 是不可能的；我不可能一个月手写 10 万+ 行代码，更不用说思考那么多事情了。此外，正常工作日的干扰——比如新 bug、小的功能请求、紧急事件——会打断心流并降低生产力。有了 AI，这些可以交给并行的工作线程，不再占据注意力和前台。

除了 AI 之外，其他所有因素能让 11 倍乘数叠加多少？想象一下，你作为来自 2026 年的时间旅行者，访问一个 AI 之前的 PostHog，那里评审是强制性的，而你是那里唯一一个秘密拥有未来 AI 技术的工程师。充其量，我认为你会获得 1-2 倍的生产力提升，因为瓶颈从编写代码转移到了 PR 审批——但只对你而言。其他人仍然无法自由地评审你完成的 PR，而你 PR 产出快得多会让评审队列更长。

在 Tano，我们的交付量是 10 倍，像这样的瓶颈和其他瓶颈会出现，比如与同事沟通你在做什么、评审代码，以及弄清楚接下来要构建什么。让我们谈谈其中一些。

沟通开销：工程团队如何协作

Tano 的工程师尽可能独立工作。我们会聚在一起讨论影响整个产品的重大架构决策，但对于大多数事情，公司有足够的信任，我可以去做我认为最好的事情。他们也相信，如果我不确定该做什么，或者涉及风险，我会标记风险并考虑权衡。

快速行动的一个重要部分是让一个人对事情负责。当然，这假设他们能够自己弄清楚如何去做，并把它交付出去。

在 PostHog，构建问卷功能时，两名工程师和一名设计师合作，在一个月内交付了 V1。我们三个人都在设计、后端和前端上迭代。当我发现后端需要改动时，往往意味着另一位工程师也需要在前端做相应改动。这就是沟通开销。即便如此，一起合作的工程师还是比我更快——我会先搞定后端，然后构建前端，再然后针对任何新约束进行迭代。

既然写代码变快了，沟通开销就没什么意义了。如果我设想今天要构建同样的问卷功能，由一个人端到端负责整个技术栈——设计、前端、后端——效率会高得多。借助 Claude Code，一个工程师就能做到。

与其他工程师讨论未知的未知和我不确定的事情仍然有价值，但当产出基本已知、且是一个直接明了的功能或产品时，我认为一个人单干更有效率。

代码审查

在 Tano，代码审查是可选的。也就是说，一旦你熟悉了代码库，它们就是可选的。达到可信状态所需的时间因人而异，取决于你多快能上手，以及人工 PR 审查意见多快降到零。我入职三周后就觉得足够自在了，但根据经验不同，这个时间会有所变化，最长可达八周。

我通过 Claude Code Github Actions 构建了一个代码审查 agent，它在每个 PR 上运行，现在已是整个代码库的标准配置，并在持续集成（CI）中运行。如果出现有风险的改动，我们还可以按需运行一个更深入、更强大的 agent。

大多数情况下，这个自动审查器是 PR 上唯一的审查。没有人工 PR 审查。

有时，事情会出错。例如，在一次报表更新中，我们需要处理最小货币单位，比如美元中的美分。该 agent 决定取这些最小单位，将它们解析为浮点数，然后乘以 100。

你看出错误了吗？

如果你处理过金融系统，你可能遇到过这种情况。假设每种货币都有 100 个最小单位是个愚蠢的错误。例如，巴林第纳尔的最小单位是 fulūs，1 第纳尔等于 1,000 fulūs。但生成的代码假设是 100，这引发了问题！

此外，我们已经有处理所有货币计算的工具函数，人工审查者会发现生成的代码没有使用它。

我们愿意在自动 agent 审查与快速推进、出问题再修复之间做出权衡。我们做出这个权衡的代价是不对每个 PR 进行扎实的人工审查，因为我们可以快速对这些问题进行前向修复。在这个案例中，我们在部署后不久就注意到报表数字对不上，并在一小时内修复了它们。

有时，问题会以新的方式出现。例如，我们 Postgres 中的 posts 表变得越来越大，大约 25 GB、600 万行。我们想给这张表加一个新的部分索引，而在 500 万行以上的表上做迁移并不简单。我们后来才意识到这一点：当时我们做了一次阻塞式迁移，阻塞了写入，结果我们的摄取流水线停止保存新帖子。它还超时了，导致新部署无法运行。现在，每次这样的迁移都必须以 concurrently 方式执行，以确保它不会阻塞部署或对表的写入。

我们确保把任何新的出错方式都加入审查代理。现在，它有一份最大表的列表，并且不允许在这些表上执行阻塞式迁移。

既然没有代码审查、只有代理在写代码，那它如何改变了开发速度、PR 回滚率和 PR 的中位大小？我有一些有趣的数据。Tano 的回滚率低 6 倍，因为我们大多数时候是向前修复，而不是回滚。但另一部分原因是，随着模型改进，自动代码审查和代理写出的代码 bug 更少。

因为我不必等任何人合并我的 PR，合并的中位时间不到一小时。

“上下文最大化”要构建什么

在 Bloomberg，我被保护起来，不直接接触客户，只与我们的产品经理互动，由他帮助我们确定工作优先级。在超大型公司工作时，工程师和产品经理之间界限分明是好事，但随着工作场所变小，这些角色会合并。在 Bloomberg，每个工程师团队都有一名专职产品经理。在 PostHog，几名团队共用一名产品经理。在 Tano，则一个都没有。

PostHog 的产品经理帮助做了大量研究并设定产品方向，但工程师也被期望深入参与、与客户交谈、自己做研究，并在需要时对产品方向形成自己的看法。我在那种环境中如鱼得水。

在我目前的角色中，我也是产品经理。我们每周一都有路线图会议，每个人都会提出他们遇到的问题、我们需要修复的事情、很快会成为问题的事情，比如每位客户的支持工单数量在增加——这意味着随着客户增多，人力可能跟不上需要解决的工单数量。

CEO 和 CTO 提供关于待办事项最多的上下文，通常也更清楚优先级。他们向工程师提供诸如客户流失风险、完成新销售所需功能等上下文。我们一起决定哪些事情值得处理，然后在工程师之间分配工作。通常，每位工程师会各自挑一件不同的事情来做。

过去需要一个月的事情，现在往往一周就能完成。这是因为代理构建东西快得多，而且我通常同时处理多个项目，不再需要等产品经理给我派活。因此，我们只需共享上下文和优先级，然后就去构建东西以实现我们的每周目标。

快速行动，打破常规

在我的职业生涯中，我参与过五次大型迁移；一次在 Bloomberg，一次在 PostHog，我还在 Tano 领导了三次。

在 PostHog，这次大迁移花了一年时间。它围绕的是person-on-events。PostHog 有两张巨大的表：events 表，存有 200 多亿条事件，记录某个匿名 id 做了什么；persons 表，存储 person 及其属性。在构建漏斗或唯一用户查询时，我们需要 join 这两张表，然后按 person 聚合。这些查询非常慢，对较大的客户来说完全不可用。person-on-events 迁移把 person 标识符和属性移到了 events 上，与匿名 id 并列。这是一次全公司范围的巨大努力，要更新每一个查询，使其不再使用 join。

这次 person-on-events 迁移非常痛苦，所有代码更新都是手写的。我们花时间确保它面向未来，因为在 events 上再做一次类似的迁移是不可行的。

在 Tano，我们仅用几周就完成了两次复杂的迁移。Tano 是一家网红营销机构，它构建 AI agent 来与创作者交谈、与他们谈判、与他们一起进行内容审核，然后将其交给品牌做最终批准，以便内容可以上线。这个 agent 的第一个版本是一份自由形式的清单，列出我们希望 agent 做什么，以及大量供它完成这些事的工具。我们在这个系统中没有良好的可观测性，agent 时不时会相当困惑，用错工具。解决方案是转向一种工作流，其中每个任务都有明确定义，并配有自己有限的一组工具。

Tano 的迁移把每一位创作者都转移到新工作流，将现有清单项映射为工作流任务，并为每个工作流构建新的 agent 工具。随着我们随时间扩展这个系统，我们意识到 agent 常常缺乏与同一创作者多个线程相关的上下文。下一次迁移解决了这些缺陷。这两次迁移都只花了几周，而不是一年。

我们想以多快的速度前进，现在是一个有意识的决定。在第二次迁移中，我漏掉了一些防护措施，导致创作者因同一项工作被支付了两次。重复付款不太好，但快速行动、打破常规是我们非常愿意做出的权衡，因为让新架构到位意味着我们可以更快扩展。在 PostHog，我们没有快速迁移的选项。

我们的产品架构从一个基本不可逆的决定变成了一个可逆的决定，这改变了你能进行何种实验、能构建何种产品，以及它们能为特定客户做到多专门的计算。我们不需要一开始就把每个细节都做对，可以针对生产环境中的更多信息进行优化，然后基于这些信息快速迭代。

3. 出现的新约束

当然，AI 原生的工作文化并非一切都很理想。我已经讲了它可能带来什么，现在我要关注它的成本。瓶颈并没有消失，它们只是转移到了我身上。快节奏的工作伴随着真实的代价：我很快筋疲力尽，脑子里要装更多事情，新事物很容易让我分心，而且我对其他人正在做什么知之甚少。

并行构建

我几乎总是同时处理多个项目。同时处理多个项目会涉及相当多的上下文切换，我发现很难跟上我的智能体生成的所有 PR。我限制了自己同时处理的事情数量，但相比 AI 智能体出现之前，这仍然让人感觉精神上更加疲惫和耗竭。

在上面的图表中，注意代表一个月内触及多个事项的列在 Tano 比在 PostHog 要满得多。我每天结束时比过去感觉精神上更累。

抖动

既然现在修复和构建东西都如此容易，我注意到工程工作变得反应性强了很多。一个新问题出现，我立刻启动一个 Claude 会话去修复它，因为我知道端到端不会超过一个小时，而且不需要我真正主动参与。

我以前在选择做新事情时要谨慎得多。例如，在 PostHog，我会根据问题的关键程度以及它与我冲刺目标的优先级竞争情况做出审慎的决定。而在 Bloomberg，直到冲刺规划会议之前，我根本不会听说有新的工作要做。

在计算机科学中，抖动发生在系统大部分时间都在任务之间切换、而不是执行任务的时候。解决办法是限制并发，并优先完成最高优先级的任务。

由于同时做更多事情，我被拉向许多不同的方向，以至于我对一切都在做出反应，修复日常出现的新 bug，而不是做我本该做的事。就像计算机一样，我花在切换任务和修复 bug 上的时间，比专注于自己的冲刺目标还多。

有时，当 bug 很关键时，改变优先级是合理且有用的。但当我仅仅因为每个单独任务耗时都不长而这样做时，这对推动公司前进并不好。

难怪抖动问题会让上下文最大化变得更糟。我最终精神上更加疲惫，因为我在修复快速 bug 上接了更多工作，而我本应专注于冲刺目标。

失去共享上下文

既然不再有代码审查，我也停止审查大部分代码了。当然，我们会审查自己的代码和新团队成员的代码，但很少审查经验丰富的同事的代码。

代码审查曾经是我在 PostHog 最喜欢的事情之一。我有一个所有进来的 PR 的信息流，并且全部阅读。阅读帮助我保持对每个人在做什么的上下文，我可以随时介入提供帮助，例如建议代码库另一部分可能已经存在的东西。随着 PostHog 从 20 人增长到约 100 人，每个工作日的新 PR 数量也从 15 个增长到 30 个。不可能继续阅读每一个 PR。

在 Tano，我们每天也合并大约 30 个 PR，而我并不是很大的异常值。Tano 的另一位工程师产出非常相似，而较新的工程师 + CTO 大约是这个数字的三分之一，因为他们要么是新人，要么有其他职责。

没有时间阅读所有 PR 意味着会缺失整个业务的上下文。做代码审查曾是我了解其他工程师在做什么以及产品如何成长的一种方式。此外，孤立的上下文会影响团队文化，因为我们最终会在孤岛中工作，这会阻碍协作。好的一面是，一个人拥有产品的大片区域，可以快速推进。不好的一面是，这也意味着只有一个人拥有那份上下文。

在软件工程中，“巴士系数”指的是一个项目需要有多少人消失才会停滞。如果只有一个人拥有项目的上下文，巴士系数就是一。低巴士系数是我合作过的每个团队都面临的未解问题。有了 AI，我一个人就能完成过去整个团队做的事，这让巴士系数问题更加尖锐。我认为 AI 提供了解决方案：如果我擅长在我的产品领域的 AGENTS.md 文件中写下上下文，任何人都能快速上手，借助 AI 学习并做出贡献。

当我把它可视化为已审查 PR 数除以已合并 PR 数的比率时，差异更加惊人：

调整自己的节奏

写代码曾经定义了我在 Bloomberg 和 PostHog 的一天是什么样子。我会在上午花时间写代码，下午开 PR，一旦获得批准就把它们合并。正如你在下面的图表中看到的，我在 PostHog 的大多数 PR 是在上午 10 点到下午 3 点之间开的，然后等待批准，之后在当天晚些时候合并。

在 Tano，这张图要分散得多。PR 随着智能体完成工作而随时增加，然后我根据风险状况和上下文审查代码。我指示智能体，与它讨论要构建什么，阅读更多代码，并在一天中更频繁地合并，我需要很好地调整自己的节奏。

在 Tano，我们的核心工作时间是上午 9 点到下午 6 点，许多人工作更久。刚加入 Tano 时，我想尽可能多完成工作，这导致我把任务前置到上午，同时运行多个工作流，并多任务处理。到下午 3 点我就精神疲惫，油箱里没油了。在 Tano 之前，我受限于写代码的速度，而我不能同时写两行不同的代码，所以我无法多任务处理。

我学会了调整自己的节奏。这是为了优先处理最重要的任务，而不是同时做十件事，也不是试图在上午做完所有事。如果我试图在精神疲惫的晚上做重要更改，我会犯错，并且会漏掉本来能发现的问题。

工作习惯

每天傍晚，我把笔记本电脑留在公司，让我的智能体在本地运行。它们通常在一两个小时后停止，所以早上我到公司时，PR 已经准备好了。早晨 PR 的差异在下图中最为明显。在 Tano，上午 9 点到 11 点之间，我打开了 18% 的 PR，而在 PostHog，这一比例只有 9%。除了清晨和午餐时间，Tano 每小时打开的 PR 百分比相当稳定，约为每小时 11%，因为智能体全天都在运行。PostHog 在午餐时间前后达到峰值，全天的波动也略大一些，因为随着傍晚临近，我写代码的效率下降，所以我会留出一些时间做其他任务，比如审查代码、行政工作和补看 Slack 表情包。

PostHog 是完全远程办公，所以我会在家工作，没有固定的下班时间。我的笔记本电脑总是带在身边，有些晚上我会工作到很晚，因为我想把某件事做完，而不是整晚都在想它。在 Tano，我总是把笔记本电脑留在公司，回家后就关机。把笔记本电脑留在公司对同事来说有点奇怪，但对我来说非常好：不仅我的智能体可以按我希望的方式继续运行，更重要的是，我有了一个明确的收工切换点。

我设置这道护栏，是为了不被 AI 压垮。有时我确实觉得自己没有充分发挥 AI 的潜力；它就在那里，等着被使用，等着用来构建更多东西，等着方向，而我却在睡觉？一边比以往更努力地工作，一边又觉得做得不够，这种感觉让人不堪重负。

我的护栏——比如不把工作笔记本电脑带回家——让我不至于忘乎所以。像总是在下午 6 点结束工作日这样的习惯帮助我保持脚踏实地。我花了一段时间才接受那种没有充分发挥潜力的感觉，但我已经接受并重新诠释了这种感觉：生活不只是构建。

我可以对我想构建的东西更有野心，而且我应该优先决定构建什么，而不是仅仅因为现在有可能就构建所有东西。例如，我最近开设了一个新的伪匿名 Instagram AI 动画频道，它从我的博客中获取想法，并将其转换成很酷的动画。我一直想制作动画，但觉得太耗时。我现在专注于这个副业项目，而不是我也想要的音乐生成器、短视频编辑器、播客应用和电视流媒体应用。

设计

在 PostHog 的前十名员工中，有一位是艺术家，一位是设计师。两人都对 PostHog 这个古怪、设计精良、美丽的品牌负有重要责任。

有了 AI，我观察到早期初创公司正在轻视设计工作。我猜他们这样做是因为 AI 可以把东西做得足够好看。但与此同时，AI 设计与市面上许多其他设计非常相似。新粗野主义设计试图脱颖而出，但大多数 AI 生成的新粗野主义设计仍然相当相似。在 Tano，我们最终得到的就是这样的设计，我们正在采取措施弄清楚我们的品牌应该是什么样子。

触及 AI 极限

Tokenmaxxing 指的是尽可能多地使用 AI token，往往不顾这样做是否真的带来了生产力提升。

在 Tano，没有“无限”的 AI 预算。每个人都只有一个 20x Claude Max 套餐订阅，仅此而已。

我们没有无限的资金，我们把 AI 当作帮助我们更快前进的工具，而不是一个自主的队友。如果我们按 API 费率付费，我的用量每月会达到 8000 美元以上。

我的 Claude Max 套餐仍然会触及用量上限。在尝试把 AI 当作自主队友、让它循环运行并修复它从我们日志中发现的所有错误时，触及上限会更频繁。触及上限迫使我专注于最重要的事情。

说来奇怪，我还想从我的工具中得到更多。得益于 AI，我的产出已经提升了 11 倍，但为什么要止步于此？我想探索在没有 token 限制的情况下什么是可能的：Claude 自主运行、监控日志和 PostHog 上的会话录制，并根据这些信息自行提交 PR，效果会有多好？它能否监控 Tano 中 agent 的行为，读取与每一位创作者的每一次对话，并在我们因为迁移中的一个 bug 而向同一位创作者重复付款时告诉我们？

AI agent 已经在为我写代码了。但如果你有足够的 token 可花，有些 agent 似乎能力要强得多。我还能把它们推到多远？我目前还不知道答案，但这是我非常想进一步实验的事情。

总的来说，世界似乎正在非常快速地变化，而能身处这一切之中，我无比兴奋。

4. AI 正在如何改变软件工程

那么，这些变化中有多少是 AI 带来的，又有多少来自它周围的其他一切？

AI 是速度的倍增器。速度是初创公司的决定性特征，也是它们通过快速实验和适应市场需求来战胜 incumbent、并在功能上追赶 incumbent 的方式。PostHog 并不是第一个产品分析平台——事实上，它比先行者晚了十年。但 PostHog 的人执行得很快，追上了竞争对手，产品如今已扩展到多个不同类别，比如实验、数据仓库、错误跟踪和会话录制。

我们在 AI 之前就构建了这些产品。今天，一家使用 AI 的初创公司可以比一家不使用 AI 的公司执行得更好，而既然速度是决定性特征，不使用 AI 的初创公司将会非常艰难。

如果公司其他部分不接纳 AI，你的生产力提升是有限的。很明显，AI 是必要的，但并不充分。例如，如果你是一位穿越到 AI 时代之前的 PostHog 的访客，即便拥有今天所有的 AI 工具，你的生产力也不会高到哪里去。这是因为有同事工程师强制进行的代码审查，审查队列会无休止地增长，因为我们产出的速度快于我们审查的速度。

鼓励在工作方式上进行实验可以带来回报。我见过采取这种做法的团队最终境况更好。像 Tano 这样的团队鼓励实验，不会因为我把笔记本电脑留在公司、让 agent 通宵运行而皱眉头。

此外，一家灵活、能在新约束出现时识别它们，并努力消除这些约束以便更快前进的公司，似乎比那些采用一种工作方式并固守不变的公司表现更好。例如，Anthropic 也自动化了代码审查，但最终却受限于持续集成（CI）流水线。他们将 CI 作为新的约束解除阻塞，随后发现他们的源代码控制无法跟上。为了继续更快前进，他们重新设计了源代码控制。

当你采用 AI 以更快前进时，许多工作技术和团队流程将会出现裂痕。至少，它们会在完成更多工作的压力下不堪重负。许多初创公司可能最终不会达到需要重新设计源代码控制的规模，但总体原则依然成立：你可以限制 AI，我认为这会导致次优结果；或者你可以拥抱它，找出新的约束最终出现在哪里——比如代码审查——并通过自动化这些审查来放松这些约束，以便你能继续更快前进。

我重视这样一种团队文化：我们进行实验，愿意被证明是错的，保持谦逊、好奇，并努力充分利用我们拥有的工具。在 Tano，这种文化是我们成功采用 AI 的决定性因素，我相信文化是每个 AI 时代初创公司成功的必要——也是充分——条件。

要点

又是 Gergely。

感谢 Neil 这篇以数据驱动的文章，讲述了他如何看待行业正在发生的变化，以及变化的速度有多快。

Neil 关于他的 PR 产出从年初开始增长了十倍的故事很有意思。有两股力量在起作用：

• 自一月以来，行业开始更多地采用 AI 编码代理。正如我们在关于 PR 频率和 AI 成本的深度分析中所涵盖的，我们看到整个行业的 PR 产出平均增加了约两倍

• Neil 从一家在 AI 前时代快速发展的初创公司（PostHog）转到了一家更年轻、真正“AI 原生”的初创公司，在那里，快速前进不会让任何事情面临风险

我很欣赏这种对比。

从 AI 前初创公司转到 AI 原生初创公司时，交付节奏的突然变化很难被忽视。当然，我们知道，如果不考虑找到产品市场契合度、创造收入或拥有健康的单位经济效益等因素，迭代速度本身是毫无意义的。

不过，我仍然想知道，这一代新的“AI 原生”初创公司是否拥有这种暂时优势，即比只比它们早成立几年的公司迭代得快得多。我毫不怀疑“AI 前”初创公司最终会赶上，但当你拥有一项运转良好的业务时，你会希望更谨慎、更深思熟虑地改变流程和工具。你最不想做的事情就是因为粗心大意而毁掉你的业务！

我也很喜欢 Neil 大量谈到使用 AI 所带来的压力。他觉得有必要设置几道防护栏，这样他才有个人时间来放松，然后精神饱满、专注地回来。这是积极的，因为人很容易过度使用 AI 而永不停歇地工作：三月份，我们和 Steve Yegge 一起讨论过这种“德古拉效应”，包括使用 AI 代理似乎会耗尽工程师的精力。

再次祝贺 Neil，感谢他个人化、极为详尽地讲述了自己工作中发生的变化。感谢所有参与这次征文挑战的人！敬请期待更多文章。

来源：Pragmatic Engineer · newsletter.pragmaticengineer.com