软件工程如何改变：两个时代的对比

深度解析软件工程如何改变：两个时代的故事

我们在一项征文挑战中邀请读者撰文讲述软件开发方式发生了怎样的变化。许多人参与其中，今天我们分享的是从一批优秀来稿中脱颖而出的获奖作品。Gergely Orosz、Jessica Salmon 和 Ivan Klaric，2026年11月3日

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

周三（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。他谈到：

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

消失的旧约束。不再有沟通开销或代码评审。代价是：推进更快，也更容易出错。

出现的新约束。上下文切换过多（抖动）、共享上下文丢失、自我调节节奏更难、对设计的关注减少，以及对 AI 用量上限的担忧。

AI 如何改变软件工程。每个人都必须接纳 AI 才能在工作中获益，鼓励实验会带来改变，许多现有技术和流程在这种变化下不堪重负。

过去八个月，我一直在一家 AI 原生创业公司工作。在加入 Tano 之前，我在 PostHog 工作了四年，那是一家快速发展的前 AI 时代创业公司；我的职业生涯始于 Bloomberg，一家大型金融科技私营公司，我在那里待了三年。这三个工作场所各不相同：Bloomberg 规模庞大，有两万人，流程非常明确。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 时又是 Bloomberg 时的 2.4 倍。

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

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

Bloomberg、PostHog 和 Tano 每月合并的 PR 数

PostHog 和 Tano 的累计合并 PR 数。查看 Neil 的交互式图表

PostHog 和 Tano 每月合并的 PR 数。查看 Neil 的交互式图表

PR 是一个容易被操纵的指标，但我并没有试图操纵数字，因此它们如实反映了所做的工作。以下是我参与的所有工作的详情，用以佐证 11 倍的 PR 倍数。

我参与的工作

我以全栈软件工程师的身份加入 PostHog，工作横跨整个产品，从数据摄取管道，到为了优化漏斗和留存分析而在 ClickHouse 上优化分析查询、将其扩展到能处理十亿级以上事件规模，最终从零构建出实验产品。后来我领导 Feature Success 团队，期间我们打造了两个新产品：问卷（surveys）和抢先体验功能（early access features），同时改进了实验和功能开关。

我以创始工程师的身份加入 Tano，工作重点与在 PostHog 时类似，同样覆盖广泛的产品领域，但全部压缩在八个月内完成，而不是 45 个月。我搭建了新的联盟营销平台，大幅提升了内容监控系统的效率，还做了一些大规模迁移，比如把整个智能体架构迁移到新系统，具备持久记忆、更好的工具和更出色的可观测性。

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

我在 PostHog 四年、在 Tano 一年期间所做的工作

我如今的工作方式

在 PostHog 直到 2024 年底，AI 的应用程度仅限于自动补全。它很适合自动化重复性测试用例之类的琐碎工作，但距离如今无需人工输入就能构建完整功能的自主智能体还差得很远。

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

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

Claude 随每个 PR 生成的 HTML 摘要

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

规模更大的公司已经投入建设自己的云端智能体，并具备这些集成。这对他们来说合理，但在我们的规模下——目前还不太合适。2. 消失的旧约束

Tano 每月 PR 数量是原来的十一倍，没有 AI 就不可能做到；我不可能手写每月 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构建了一个代码评审智能体，它在每个PR上运行，现在已是整个代码库的标准配置，并在持续集成（CI）中运行。我们还有一个更深入、更强大的智能体，可以在出现风险变更时按需运行。

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

一个PR代码评审示例

有时，事情会出问题。例如，在一次报表更新中，我们需要处理最小货币单位，比如美元中的美分。智能体决定把这些最小单位当作浮点数解析，然后乘以100。

你看出错误了吗？

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

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

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

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

我们确保把任何新的出错方式都添加到评审智能体中。现在，它有一个最大表的列表，并且不允许在这些表上执行阻塞迁移。

代码评审提示中的迁移安全防护

鉴于没有代码评审、只有智能体编写代码，这如何改变了速度、PR回滚率和PR的中位大小？我有一些有趣的数据。Tano的回滚率低了6倍，因为我们大多数时候是前向修复，而不是回滚。但另一部分原因是，随着模型改进，自动代码评审和智能体编写的代码越来越没有bug。

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

PostHog与Tano的吞吐量和PR大小统计

PostHog（2021年5月–2025年1月）与Tano（2026年1月–9月）的速度和评审统计

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

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

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

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

CEO和CTO为待办事项提供最多的背景信息，通常也更清楚优先级。他们会向工程师说明客户流失风险、为促成新交易所需的功能等背景。我们一起决定哪些事情值得做，然后在工程师之间分配工作。通常，每位工程师会各自认领一项独立的工作。

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

快速行动，打破常规

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

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

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

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

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

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

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

当然，AI原生的工作文化并非一切都很理想。我已经讲了它所能实现的事情，现在我要聚焦它的代价。瓶颈并没有消失，它们只是转移到了我身上。快节奏工作的真实代价是让我迅速精疲力竭、脑子里要装更多事情、新事物很容易让我分心，以及我对其他人在做什么知之甚少。

并行构建

我几乎总是同时处理多个项目。同时做不止一件事涉及相当多的上下文切换，我发现很难跟上我的智能体生成的所有PR。我限制自己同时处理的事情数量，但即便如此，它仍然比有AI智能体之前感觉更耗费脑力、更让人疲惫。

我在PostHog做过的项目，以及它们如何重叠。查看交互式图表

我在Tano做过的项目，以及它们如何重叠。查看交互式图表

在上面的图表中，注意代表一个月内触及的多个事项的列在Tano比在PostHog满得多。我每天结束时比以前感到更精神疲惫。

反复折腾

既然现在修复和构建都这么容易，我注意到工程工作正变得被动得多。新问题一出现，我立刻启动一个 Claude 会话去修复它，因为我知道端到端不会超过一小时，而且几乎不需要我真正主动参与。

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

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

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

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

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

失去共享上下文

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

代码评审曾经是我在 PostHog 最喜欢的事情之一。我订阅了每个进来的 PR，并且全部阅读。阅读帮助我保持对每个人在做什么的上下文，我可以在需要的地方介入帮忙，比如建议代码库其他部分可能已经存在的东西。随着 PostHog 从 20 人增长到约 100 人，每个工作日的新 PR 数量也从 15 个增长到 30 个。不可能继续阅读每一个 PR。

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

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

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

更多合并，更少评审：Tano 每月合并和评审的 PR 数量

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

已评审/已合并 PR 比率。在 Tano 它几乎为零

调整自己的节奏

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

PostHog 最忙的 PR 月份：我大多数在上午 10 点到下午 3 点之间开 PR。查看交互式图表

我在 Tano 最忙月份的 PR：PR 多得多，通常在上午 10 点到下午 6 点之间开。查看交互式图表

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

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

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

工作习惯

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

按小时统计的已开 PR 占比。查看交互式图表

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

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

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

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

设计

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

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

左：PostHog 手工打造的品牌；中：Tano 由 AI 生成的新粗野主义网站；右：现成的新粗野主义组件套件

触及 AI 上限

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

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

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

我的 Claude Max 套餐触及上限的情况仍然会发生。在尝试把 AI 当作自主队友、运行循环并根据日志修复它发现的任何错误时，这种情况更频繁。触及上限迫使我专注于最重要的事情。

奇怪的是，我想从我的工具中获得更多。多亏了 AI，我的产出已经提高了 11 倍，但为什么止步于此？我想探索如果没有 token 限制会怎样：Claude 自主运行、监控日志和 PostHog 上的会话录制，并根据这些信息自行开 PR，效果如何？它能否监控 Tano 的智能体行为，阅读与每位创作者的每一次对话，并在我们因为迁移中的 bug 而向某位创作者重复付款时告诉我们？

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

总的来说，世界似乎正在非常快速地变化，而能身处这一切之中，我超级兴奋。4. AI 如何改变软件工程

那么，这些变化中有多少是 AI 带来的，又有多少是周围其他因素带来的？

AI 是速度的倍增器。速度是初创企业的决定性特征，也是它们通过快速试验和适应市场需求、在功能上追赶老牌企业，从而在竞争中胜出的方式。PostHog 并不是第一个产品分析平台——事实上，它比同行晚了十年才入场。但 PostHog 的员工执行迅速，追上了竞争对手，如今产品已扩展到多个不同类别，比如实验、数据仓库、错误跟踪和会话录制。

我们是在 AI 出现之前构建这些产品的。如今，一家使用 AI 的初创企业可以比另一家不使用 AI 的企业执行得更快，而既然速度是决定性特征，那么不使用 AI 的初创企业将会举步维艰。

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

鼓励在工作方式上进行实验可能会带来回报。我见过采取这种方法的团队最终状况更好。像 Tano 这样的团队就鼓励实验，不会因为我下班时把笔记本电脑留在公司、让智能体整夜运行而对我皱眉。

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

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

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

又是我，Gergely。

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

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

自 1 月以来，行业开始更多地采用 AI 编码智能体。正如我们在关于 PR 频率和 AI 成本的深度分析中所提到的，整个行业的 PR 产出平均大约增长了两倍。

Neil 从一家在 AI 出现之前就行动迅速的初创企业（PostHog）转到了一家更年轻、真正“AI 原生”的初创企业，在那里，快速行动不会让任何事情面临风险。

我很欣赏这种对比。

从一家 AI 出现之前的初创企业转到一家 AI 原生企业时，交付节奏的突然变化很难被忽视。当然，我们知道，如果不看找到产品市场契合度、创造收入或拥有健康的单位经济效益等方面，迭代速度本身是相当没有意义的。

PR 只是一个指标，但“AI 原生”初创企业与“AI 出现之前”的初创企业之间的这种对比仍然很大。请看 Neil 的交互式图表。

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

我也喜欢 Neil 大量谈到使用 AI 所带来的压力。他觉得有必要设置几道防护栏，以便自己有个人时间放松，然后精神焕发、专注地回来。这是积极的，因为很容易过度使用 AI 而永不停歇地工作：今年 3 月，我们和 Steve Yegge 谈到了这种“德古拉效应”，包括使用 AI 智能体似乎会消耗工程师的精力。

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