软件工程正在如何变化：两个时代的对比
过去八个月，我一直在一家AI原生创业公司工作。加入 Tano 之前，我在 PostHog 待了四年——那是一家发展很快的前AI时代创业公司。而我的职业生涯起步于 Bloomberg，一家大型金融科技私企，在那里干了三年。
这三个地方截然不同：Bloomberg 规模庞大，有两万人，流程非常明确；PostHog 小得多，我加入时大概十个人，现在到了两百人；在 Tano，我是第一个工程师，如今全公司也就十人左右。每一份工作都让我看到速度和文化的差异有多大，而最近这段经历更让我意识到，文化本身也得跟着AI一起变。
为了佐证，我用了一些关于我在 PostHog 和 Tano 工作的详细统计数据，另外还有 Bloomberg 的一些粗略数字。到目前为止，我在 Tano 写的代码、提交的 PR 都比在 PostHog 多得多，而这很大程度上要归功于AI。
推动这一转变的，是工程文化。
先说一句免责声明：PostHog 的数据来自前AI时代。我一直在关注他们的进展，PostHog 现在对AI的拥抱程度可以说是拉满了，产出也在显著增长。在本文中，我把它当作优秀工程工作的“前AI基准线”。Tano 则是一家快速迭代的AI原生创业公司，成立于AI智能体（agent）出现之后。
1. 两个时代的交付节奏
先从原始数据说起。我在 Tano 提交的 PR 数量是在 PostHog 的 11 倍，而在 PostHog 又是在 Bloomberg 的 2.4 倍。
在 Bloomberg 时我刚刚起步，所以不算最快的那批人。转到 PostHog 后，我才真正见识到快节奏的创业文化是什么样：公司鼓励我们承担责任、快速交付、倾听客户、尽快解决问题。在 Bloomberg 和 PostHog，对代码的要求都很高：所有代码都必须经过同行评审，等我做到高级工程师后，很大一部分时间都花在了审代码上。
Bloomberg、PostHog 和 Tano 每月合并的拉取请求数量。
PostHog 和 Tano 累计合并的拉取请求。查看 Neil 的交互式图表。
PostHog 和 Tano 每月合并的拉取请求。查看 Neil 的交互式图表。
PR 数量容易被刷，但我并没有刻意去刷数据，所以它真实反映了我的工作量。下面是我做过的所有事情的细节，用来支撑 11 倍的 PR 倍数。
我做的工作
我以全栈工程师的身份加入 PostHog，工作横跨整个产品：从数据摄取管道，到优化 ClickHouse 上漏斗和留存的分析查询，把系统扩展到每天处理十亿级以上的事件，最后从零搭建了实验产品。后来我带领 Feature Success 团队，期间我们开发了两个新产品——问卷和抢先体验功能，同时持续改进实验和功能开关。
我作为创始工程师加入 Tano，负责的产品范围和 PostHog 类似，但全部压缩在 8 个月内完成，而不是 45 个月。我搭建了新的联盟平台，大幅提升了内容监控系统的效率，还做了几次大规模迁移，比如把整个 Agent 架构迁移到新系统，支持持久记忆、更好的工具和更强的可观测性。
以下是我在两家公司工作的汇总：
在 PostHog 四年、在 Tano 一年期间做过的事情。
我现在的工作方式
2024 年底之前，我在 PostHog 用到的 AI 能力仅限于代码补全。它对自动化重复性工作很有帮助，比如生成重复的测试用例，但距离今天能自主构建完整功能的 AI Agent 还差得远——那些 Agent 不需要人工干预就能把整个功能做出来。
今年加入 Tano 时，Claude Code 桌面版已经存在，Agent 支持相当好，稍微引导一下就能构建完整功能。我一直没习惯命令行界面（CLI），所以坚持用 Claude Code 桌面版。我很喜欢它内置的浏览器，让 Claude 在里面操作，而不是用我自己的浏览器——如果 Claude 接管我的浏览器、把我挡在外面没法工作，那就太烦人了。过去一年，桌面版在功能上已经追平了 CLI，而且还有一些 CLI 没有直接提供的功能，比如浏览器。
任何时候，我手上都有 3-5 件不同的事同时在推进。我会先过一遍计划，但大多数时候就让代理自己跑，直到它把 PR 准备好、评论也处理完。然后我会通过一份易读的 HTML 产物来回顾它做了什么——Claude 被设定每次提交 PR 都生成这样一份文件。大概长这样：
Claude 每次提交 PR 都会生成的 HTML 摘要
我的代理跑一次要 1-2 小时。这是为了端到端构建一个完整功能。考虑到审查、验证、截图这一整套流程，代理通常确实需要这么久。如果我在做研究任务，需要调查大量数据、处理图片和视频，或者反复迭代逼近一个目标，运行时间还会更长。我还没用云端代理，因为原生的 Claude 代理似乎太受限，没法像在本地那样跑任务。大公司投入资源自建云代理，把这些集成都做了进去。这对他们来说合理，但以我们的规模还不太值得——至少现在不是。
2. 消失的旧约束
没有 AI，Tano 每月多出 11 倍的 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 做了一个代码审查代理，每个 PR 都会自动跑，现在整个代码库都默认使用，并且集成在持续集成（CI）流程里。另外还有一个更深度、更强的代理，遇到有风险的改动时可以按需调用。大多数情况下，这个自动审查者就是 PR 上唯一的审查者。没有人工 PR 审查。
一个 PR 代码审查的示例
有时候也会出问题。比如有一次更新报表功能，需要处理次要货币单位，比如美元的美分。代理把这些次要单位当浮点数解析，然后乘以 100。大家看出问题了吗？如果你做过金融系统，大概率踩过这个坑。想当然地认为每种货币都有 100 个次要单位，这是个低级错误。比如巴林第纳尔的次要单位是 fulūs，1 第纳尔等于 1000 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 有两张大表：事件表存储了超过 200 亿条记录，记录某个匿名 ID 做了什么；人员表存储用户及其属性。构建漏斗或去重用户查询时，需要关联这两张表，再按人员聚合。这些查询非常慢，对大客户来说几乎不可用。人员事件化迁移把人员标识和属性直接写到事件上，与匿名 ID 并列。这是一项全公司的大工程，要更新所有查询，不再使用关联。这次迁移非常痛苦，所有代码更新都是手写的。我们花时间确保它面向未来，因为在事件表上再做一次类似迁移是不可行的。
在 Tano，我们几周内就完成了两次复杂的迁移。Tano 是一家网红营销机构，构建 AI 代理与创作者沟通、谈判、进行内容审核，然后交给品牌最终审批，让内容上线。这个代理的第一版是一份自由形式的清单，列出我们希望代理做什么，以及大量工具来帮它完成这些事。这个系统缺乏良好的可观测性，代理时不时会犯迷糊，用错工具。解决方案是转向工作流模式，每个任务定义清晰，配有自己有限的工具集。Tano 的迁移把每个创作者都切换到新工作流，将现有清单项映射为工作流任务，并为每个工作流构建新的代理工具。随着系统规模扩大，我们意识到代理在处理同一创作者的多个对话线程时经常缺乏上下文。下一次迁移解决了这些缺陷。这两次迁移都只花了几周，而不是一年。
推进速度多快，现在是我们有意识的决定。第二次迁移时，我漏掉了一些防护措施，导致创作者同一份工作被付了两次钱。重复付款当然不好，但“快速行动、打破常规”是我们非常愿意接受的取舍，因为新架构上线意味着我们能扩展得更快。在 PostHog，我们没有快速迁移的选项。我们的产品架构从基本不可逆的决定变成了可逆的决定，这改变了你能做哪些实验、能构建什么产品、以及它们能为特定客户做到多专门的算计。我们不需要一开始就把每个细节做对，可以为了在生产中获取更多信息而优化，然后根据这些信息快速迭代。
3. 出现的新限制
当然，AI 原生的工作文化并非一切都是理想的。我已经讲了它能带来什么可能，现在我要聚焦它的代价。
瓶颈没有消失，只是转移到了我身上。快节奏工作的真实代价是：我很快把自己耗尽，脑子里同时装更多事情，新事物很容易让我分心，而我对其他人正在做什么了解得很少。
并行开发
我几乎总是在同时做多个项目。同时做不止一个项目意味着相当多的上下文切换，我发现很难跟上我的智能体生成的所有 PR。我限制了自己同时做的事情数量，但即便如此，它仍然比有 AI 智能体之前更耗费脑力、更让人疲惫。
我在 PostHog 做过的项目，以及它们如何重叠。查看交互式图表
我在 Tano 做过的项目，以及它们如何重叠。查看交互式图表
在上面的图表中，注意代表一个月内触及多个事项的列，在 Tano 比在 PostHog 满得多。我每天结束时都比以前更累。
抖动
现在修东西、搭东西都太容易了，我注意到工程工作变得越来越被动。新问题一来，我立马开一个 Claude 会话去修，因为我知道从头到尾不超过一小时，而且几乎不用我真正动手。以前我决定要不要做一件新事会谨慎得多。比如在 PostHog，我会根据问题有多严重、以及它和我 sprint 目标的优先级怎么竞争，来权衡着决定。而在 Bloomberg，不等到 sprint 规划会，我根本听不到有什么新活要干。
计算机科学里有个词叫抖动（thrashing），指的是系统把大部分时间都花在任务之间来回切换，而不是真正干活。解决办法是限制并发，先把优先级最高的任务做完。由于我同时在做太多事，被拉向各个方向，结果对什么都做出反应、去修日常冒出来的新 bug，而不是做我本该做的事。就像一台计算机，我花在切换任务、修 bug 上的时间，比专注自己的 sprint 目标还多。有时候 bug 很严重，调整优先级是合理也有用的。但如果我只是因为每个任务都不长就去切换，那对推动公司前进并没多大帮助。难怪抖动问题会让 context-maxxing 变得更糟。我最后会更心力交瘁，因为我接下了更多修快 bug 的活，而本来该做的是 sprint 目标。
失去共享上下文
既然不再有代码评审了，我也基本不再评审大部分代码。当然，我们会评审自己的代码和新成员的代码，但很少评审资深同事的。代码评审以前是我在 PostHog 最喜欢的事情之一。我有一个信息流，能看到进来的每个 PR，每一个都会读。阅读让我保持对每个人在做什么的了解，也能在需要的地方插把手，比如提示某些东西可能代码库别处早就有了。
PostHog 从 20 人增长到约 100 人时，每个工作日新增的 PR 数量也从 15 个涨到了 30 个。想每一条都读完已经不可能了。在 Tano，我们每天也大概合并 30 个 PR，而我不算特别突出的个例。Tano 还有一位工程师的产出跟我差不多，新加入的工程师和 CTO 大概是这个量的三分之一，因为他们要么刚来，要么还兼着其他职责。
没时间读所有 PR，意味着会错过整个业务的上下文。以前代码审查是我跟进其他工程师在做什么、产品怎么演进的方式之一。而且上下文彼此隔离会影响团队文化，大家最后各干各的，协作意愿被削弱。好处是一个人可以负责产品的一大块，推进得快；坏处是只有这一个人掌握那部分上下文。
软件工程里有个概念叫“巴士因子”（bus factor），指的是一个项目要因为多少人离开才会停摆。如果只有一个⼈掌握项目的上下文，巴士因子就是 1。在我待过的每个团队，巴士因子过低都是个没解决的问题。有了 AI，我一个人就能干完以前整个团队的活，这让巴士因子问题变得更尖锐。
我认为 AI 提供了解决办法：如果我能把产品领域的上下文好好写进 AGENTS.md 文件，任何人都能快速上手，借助 AI 边学边干，做出贡献。
合并更多，审查更少：Tano 每月合并与审查的 PR 数量
把它换成“已审查 PR 数 ÷ 已合并 PR 数”的比例来画，差异更明显：
已审查/已合并的 PR 比例。在 Tano 这个数字接近零
安排自己的节奏
写代码曾经定义了我的一天在 Bloomberg 和 PostHog 是什么样子。上午写代码，下午开 PR，拿到批准后就合并。从下图可以看到，在 PostHog 我大多数 PR 是在上午 10 点到下午 3 点之间开的，然后等审批，当天晚些时候再合并。
PostHog 的 PR 最忙月份：大多数在上午 10 点到下午 3 点之间开的。
Tano 最忙月份的 PR：数量多得多，通常在上午 10 点到下午 6 点之间开。
在 Tano，这张图就分散得多。智能体什么时候干完活，PR 就什么时候提交，然后我再根据风险高低和上下文来审查代码。我给智能体下指令，跟它讨论要做什么，读的代码也更多了，一天里合并代码的次数频繁得多，所以我得好好安排节奏。
Tano 的核心工作时间是上午 9 点到下午 6 点，很多人会干得更久。刚加入 Tano 那会儿，我想尽可能多出活，就把任务都堆到上午，同时推进好几条工作线，多任务并行。结果一到下午 3 点，脑子就累垮了，一点余力都不剩。在 Tano 之前，我的产出受限于写代码的速度，而我又没法同时写两行不同的代码，所以根本没法多任务。我慢慢学会了控制节奏：把最重要的任务排在前面，不一次干十件事，也不硬要把所有事都在上午做完。如果等到晚上精神耗尽时再去改重要的地方，我就会出错，该发现的问题也发现不了。
工作习惯
每天晚上，我把笔记本电脑留在公司，让智能体在本地继续跑。它们通常一两个小时后就会停下，所以第二天早上我到公司时，PR 已经准备好了。早上 PR 数量的差异，在下面这张图里看得最清楚。
在 Tano，上午 9 点到 11 点这段时间，我提交的 PR 占全天的 18%，而在 PostHog 时只有 9%。除了清早和午休，Tano 每小时提交 PR 的比例基本稳定在 11% 左右，因为智能体整天都在跑。PostHog 则在午饭前后达到高峰，一天里的波动也略大一些，因为越到傍晚，我写代码的效率越低，于是我会留出一些时间做别的事，比如审查代码、处理杂务、补看 Slack 里的梗图。
按小时统计的 PR 提交占比。
PostHog 是全员远程办公，所以我在家工作，没有明确的收工时间。笔记本电脑从不离身，有些晚上我会干到很晚，只因为我想把某件事做完，而不是整晚都在惦记它。
在 Tano，我上班时总是让笔记本电脑一直开着，回家就关掉。把笔记本留在公司这件事，同事们起初觉得有点奇怪，但对我来说效果很好：一方面，我的 AI 代理能按我的意愿持续运行；更重要的是，我有了一个明确的“下班切换点”。我立下这条规矩，是为了不被 AI 压得喘不过气。
有时候我确实会觉得，自己没有把 AI 的潜力用足——它就在那里，等着被使用，等着被拿来构建更多东西，等着我给它方向，而我却在睡觉？明明已经比以往任何时候都更努力，却还是觉得做得不够，这种压力让人难以承受。我的这些防线——比如工作笔记本不带回家——把我从过度投入中拉了回来。像每天固定 6 点结束工作这样的习惯，帮我保持脚踏实地。
接受“没有把潜力用足”这种感觉花了我一段时间，但现在我已经接受并重新理解了它：生活不止是构建东西。我可以对自己想做的项目更有野心，也应该优先选择做什么，而不是因为现在一切皆有可能就什么都做。比如，我最近开了一个半匿名的 Instagram AI 动画频道，把我博客里的想法转成有意思的动画。我一直想做动画，但以前觉得太耗时间。我现在把精力放在这个副业上，而不是我也想要的音乐生成器、短视频编辑器、播客应用和电视流媒体应用。
设计
PostHog 最早十名员工里，有一位艺术家，一位设计师。这个古怪又设计精良、漂亮的品牌，很大程度上要归功于他们俩。
观察 AI 时代，我看到一些早期创业公司在削减设计工作。我猜他们这么做，是因为 AI 已经能把东西做得“足够好看”。但与此同时，AI 设计出来的东西和市面上很多其他设计非常相似。新粗野主义（neo-brutalist）设计试图脱颖而出，但大多数 AI 生成的新粗野主义设计仍然相当雷同。
在 Tano，我们最终就是这么做的，也在通过招聘一位设计师作为下一位团队成员来解决这个问题。小团队里，AI 一下午就能产出勉强能用的东西，设计看起来是最容易省掉一个招聘名额的地方。但设计恰恰也是差异会不断放大的地方：品牌、插画风格，那些让 PostHog 之所以像 PostHog 的奇特小细节。AI 能帮你做到及格，但做不到让人记住。
我牺牲了什么
我不想把旧时代浪漫化。慢慢写代码不是美德，等两天才拿到评审也不是。但有些东西当时是承重墙，我那时没意识到。
在 PostHog，读每一个 PR 是我了解代码库的方式。不是读文档，也不是结对编程——只是看别人用和我略有不同的方式解决问题。这种事以前是被动发生的，是干活的副产品。现在除非我主动去做，它根本不会发生。
更广泛的共享上下文也是一样。当一个人拥有产品的一大块，并带着 agent 快速推进，产品确实跑得快。但“为什么这么建”的知识只活在一个脑袋里，外加一些写进 AGENTS.md 文件的内容。巴士系数是一，而且是刻意设计成了一。
我不认为答案是回到强制评审。吞吐量太宝贵了，而且那些评审大多本来也很浅。答案是刻意去做那些曾经自然发生的事：把上下文写下来，让 agent 解释你不拥有的子系统，即使没人要你批准，也去读那些重要的 diff。
招聘
招聘是我觉得两个时代差异最大的地方。旧时代，我评估的是一个人能不能写出好代码，面试基本是这件事的代理指标。现在代码是容易的部分。我真正想搞清楚的是：这个人有没有品味、对风险的判断力，以及在 agent 负责打字时，能不能在心里清晰地握住自己在建的东西。
有些能力很难在面试里考察，我也不认为有人已经想出了办法。但失败的后果很明显：按照旧标准招人，招来的人写代码很快，但写出来的东西——包括他们自己在内——没人能完全看懂。
两个时代的故事
第一个时代：我的产出受限于双手。一次只能写一行代码，其他一切——上下文、质量、影响力——都是这个限制带来的下游结果。这种限制令人烦恼，但它让我保持诚实。我无法构建超出自己理解范围的东西。
第二个时代：我的产出受限于判断力。双手不再是瓶颈，注意力才是。无论我是否想清楚值不值得做，智能体都会继续工作，诱惑在于把任务同时指派给所有方向。真正的自律是把任务指向更少的事情，并诚实地判断其中哪些真正需要构建。
我不认为哪个时代更好。但它们奖励不同的人，也对同一个人提出不同的要求。如今脱颖而出的工程师不是打字最快的——而是那些能决定不构建什么、并留下足够上下文让别人在没有自己的情况下也能构建的人。
这正是我还在学习的地方。智能体变快的速度，远比我变聪明的速度快。
左：PostHog 手工打造的品牌风格；中：Tano 用 AI 生成的新粗野主义网站；右：现成的新粗野主义组件库
撞上 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 已经在替我写代码了。但有些 agent 在 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 产出从年初开始增长了十倍，这个故事很有意思。背后有两个力量在起作用：举个例子，假如你是一位时间旅行者，回到 AI 出现之前的 PostHog，即便带着今天所有的 AI 工具，你的产出也不会高到哪去。因为代码审查必须由同伴工程师来做，而我们的产出速度远超审查速度，审查队列就会无限增长。
鼓励大家尝试不同的工作方式，往往能带来回报。我见过采用这种做法的团队，最终状态都更好。像 Tano 这样的团队，鼓励实验的方式就是不因为我下班把笔记本留在工位、让智能体跑一整晚而皱眉头。更进一步，一家灵活的公司能在新瓶颈出现时识别它们，并努力消除瓶颈以便跑得更快，这样的公司似乎比那些固守单一工作方式的公司表现更好。
比如，Anthropic 也把代码审查自动化了，但随后又受限于持续集成（CI）流水线。他们解决了 CI 这个新瓶颈，接着发现源代码管理跟不上了。为了继续提速，他们重新设计了源代码管理。当你用 AI 来加速时，很多现在还能正常运转的技术和团队流程会出现问题，至少会在更大的工作量下不堪重负。很多初创公司可能不会发展到需要重新设计源代码管理的地步，但道理是一样的：你可以限制 AI 的使用——我认为这样做效果并不理想——也可以拥抱它，找出新出现的瓶颈在哪里（比如代码审查），然后通过自动化这些环节来消除瓶颈，从而继续保持高速前进。
我看重这样的团队文化：鼓励实验，愿意接受被证明是错的，保持谦逊和好奇，尽力用好手上的工具。在 Tano，这种文化是我们成功落地 AI 的关键因素。我相信，对每一家 AI 时代的初创公司来说，文化是成功的必要条件，也是充分条件。
要点总结
又是我，Gergely。感谢 Neil 这篇数据驱动的文章，他分享了自己对行业变化的观察，以及这些变化发生得有多快。
Neil 讲到他的 PR 产出从年初开始增长了十倍，这个故事很有意思。背后有两个力量在起作用：
- 自今年一月以来，业界采用 AI 编码智能体（AI coding agent）的情况越来越多。整个行业的 PR（拉取请求）产出平均大约翻了一番——这一点我们在「PR 频率与 AI 成本」的深度分析里详细讲过。
- Neil 从一家「前 AI 时代」、节奏飞快的创业公司（PostHog），跳到了一家更年轻、真正「AI 原生」的创业公司。在那家公司，哪怕走得太快，也不会有什么会被搞砸。
我很欣赏这种对比。从一家前 AI 时代的创业公司，转到一家 AI 原生的公司，交付节奏的突变很难被忽视。当然，我们都明白，单看迭代速度本身其实没什么意义，还得看是否找到产品市场契合（PMF）、是否做出收入、单位经济模型是否健康。PR 只是众多指标之一，但「AI 原生」和「前 AI 时代」创业公司之间的这个反差，依然相当悬殊。
可以看看 Neil 做的交互式图表。
不过我也在想，这一代新的「AI 原生」创业公司，或许拥有一项暂时的优势：它们的迭代速度远快于只比自己早成立几年的公司。我毫不怀疑，「前 AI 时代」的创业公司最终会追上来——但当一门生意运转良好时，你想在改动流程和工具时更谨慎、更有章法。最不该做的，就是因为粗心大意把生意搞砸！
我还很欣赏 Neil 花了很多篇幅谈使用 AI 带来的压力。他觉得有必要设立几道防护线，好让自己有个人时间放松，然后精神饱满、专注地回来。这是好事，因为人太容易过度使用 AI，永远停不下来：三月时我们和 Steve Yegge 聊过这种「德古拉效应」（Dracula effect），其中包括使用 AI 智能体似乎会耗尽工程师精力这件事。
再次祝贺 Neil，他非常个人化、极为细致地记录了自己工作中的变化。也感谢每一位参与此次征文活动的读者！后续还会有更多文章，敬请期待。
我们邀请读者参加征文活动，写下构建软件的方式发生了哪些变化。很多人参与其中，今天我们分享……
从一批强劲的投稿中，分享脱颖而出的获奖作品。