“我不再是代码的实现者，而是管理者——管理一群AI Agent替我干活。”
这句话出自一个刚加入公司6周的开发者Neil Kakkar之口。
上面这张commit图，是他在Tano工作6周后的提交记录。
说实话，看到这个曲线我惊了。 不是因为数字有多夸张，而是因为曲线背后藏着一个细思极恐的事实：他变懒了，但产出却变多了。
他到底做了什么？
第一个转变：我不做苦力了
刚进公司时，Neil跟所有开发者一样——手动创建PR。
Stage changes → 写commit message → 写PR描述 → push → 创建PR。标准流程，没毛病。但他突然意识到：这不就是纯体力劳动吗？
于是他写了第一个Claude Code技能：/git-pr。
这个脚本帮他干了以前所有琐碎的事，而且干得更好。PR描述比他自己写的还详细——因为AI会读取完整的diff并准确总结变更内容。
“我以前根本没注意到这些工作是负担，直到AI帮我分担了，我才意识到以前有多少时间浪费在'描述代码'这件事上。”
每次创建PR，从之前的几分钟变成了几秒钟。
更重要的是，心理负担没了。 以前每次提交都意味着一次context switch：停止思考代码，开始组织语言描述代码。现在？/git-pr一敲，完事。
第二个转变：杀死等待
开发过程中最烦人的环节：等。
本地预览 → 切换分支 → 关掉dev server → 重启到新分支 → 验证功能 → 审查代码。
服务器构建大概需要一分钟。
一分钟，说长不长，说短不短。刚好够打断专注，也刚好不够干点别的。
Neil干了一件看起来很小的事：把构建工具换成SWC。
服务器重启时间从一分钟降到1秒以下。
“这听起来是小改变。其实不是。亚秒级重启意味着你永远不会离开心流状态。保存文件，服务器已经ready，直接预览。没有注意力漂移的间隙。”
这感觉，就像对话里没有尴尬的沉默。
第三个转变：让AI长眼睛
以前，每个UI改动他都要亲自检查。
本地预览 → 肉眼看 → 判断是否符合预期。
这没问题，但问题在于——他成了每个功能的瓶颈。
后来他换成Claude Code的preview功能。这个功能允许agent自己搭建预览环境，保留session数据，看到UI实际长什么样。
他把这一步接进工作流：一个改动不算"完成"，直到agent自己验证了UI。
这意味着他可以把验证工作委托出去，只在最后阶段介入审核。
“agent能自己catch错误。这件事我一开始没意识到有多重要。”
第四个转变：并行一切
快速重建 + 自动预览，让他发现了一个新问题：
他一次只能舒服地干一件事。
要review其他agent或同事的PR？流程是这样的：checkout PR分支到main → rebuild → test。但这样会搞乱他当前未提交的改动。
所以他得：stash → checkout → rebuild → test → 切回来 → pop stash。
或者手动创建worktree，搭建环境，运行预览——然后发现端口跟正在运行的服务器冲突。
“我们app有前端和后端，各需要自己的端口。每个worktree共享同样的环境变量，所以它们全都想绑定到相同端口。同时运行两个东西就是一场架。”
他为此建了一整套系统。
每当创建worktree，每个服务器都从独立端口范围分配。十路并行同时预览？没问题。
从“同时处理两个分支就崩溃”，到“五个worktree同时跑”。
工作方式变了：先深度参与规划，然后消失，直到code review。Agent自己catch错误的能力，在同时跑五个的时候变得格外重要。
“review也顺畅了。没有繁琐的搭建，没有rebuild，没有端口冲突。只有：读、验证、merge。下一个。”
是基础设施，不是AI
“我的角色变了。以前从解决复杂问题中获得快感，花几个小时打磨完美的UI。现在还是偶尔会做这些事，但少多了。更有趣的是构建让agent生效的基础设施。 管理十个人的团队 vs 一个人单干。就像任何好老板一样，你可以'抢'所有功劳。”
这些不是光鲜的问题。是管道工的工作。
但管道决定了你是处于心流状态，还是跟环境较劲。
“我在Tano做的最高杠杆的工作，不是写功能。而是构建把涓涓细流变成洪水的基础设施。”
循环
每个阶段移除了一种摩擦：
- /git-pr 移除了格式化的摩擦——把代码变更变成一个像样的PR
- SWC 移除了等待的摩擦——做改动和看到结果之间的死时间
- preview移除了验证的摩擦——快速看到发生了什么
- worktree系统移除了context-switching的摩擦——多线程工作不冲突
每移除一个，下一个就变得可见。
当PR不费劲时，他注意到时间浪费在rebuild上。当rebuild瞬间完成时，他发现自己没法并行运行。
经典的约束理论——修一个，系统立刻给你看下一个。
工作性质变了。他不是“用一个工具写代码”。而是进入一个紧凑循环：发起任务 → agent写代码 → 检查preview → 读diff → 给反馈或merge → 发起下一个任务。
“反馈循环太紧了，注意力没有漏出去的空间。建变成了一种不同的乐趣——快到游戏变成了'还能多快'。当循环足够紧，工程变成了娱乐。”
争议
文章发出来以后，评论区炸了。
有人直接开炮：
“这是90年代的'每周代码行数'指标换了个包装。'我做了更多PR'不是AI工作的证据，只是你合并了更多东西。质量、bug、维护负担呢？这就是以前管理层提出来时开发者反对的思维。”
有人质疑agent的实际能力：
“我不信AI能'读取完整diff并准确总结变更'。我同事用了3个月，AI只会生成公式化的垃圾总结。重要的实现细节反而没记录。”
有人担心多线程的代价：
“一方面我喜欢这种高效的感觉。但另一方面——我的大脑被榨干了。我觉得这是主要原因。”
也有人说出了大实话：
“如果每个人都用LLM，生产力基线只是整体上移了。跟吹嘘用现代编译器而不是手写汇编一样——是快了，但大家都快了呀。”
结尾
看完Neil的故事，我一直在想一个问题：
当AI接管了"写代码"本身，那程序员还剩什么？
Neil的答案是：建管道。成为manager。claim credit。
但评论区的质疑同样尖锐：没有质量把控的throughput，还是生产力吗？
当"快"变成唯一衡量标准，那些藏在代码里的bug、那些没人注意的技术债务、那些AI生成的你都看不懂的逻辑——谁来买单？
也许，AI时代最稀缺的已经不是能写代码的人，而是能判断代码好坏的人。
你觉得呢？
【MiniMax-M2.5锐评】：commit数翻倍不代表代码质量翻倍，AI可以替你跑，但锅还得自己背。
参考链接：
https://neilkakkar.com/productive-with-claude-code.html