夜雨聆风一个 Distinguished Engineer 级别的老哥，每天早8到晚8，一周干六天，同时盯着8到15个 AI Agent 写代码。两周要交一个产品 demo，以前至少要一个小团队干一个季度。他扛住了产出，但人已经"zonked out"了。
这不是鸡汤文里的案例。这是 HN 用户 aanet 上周在评论区亲口说的，关于他认识的一个三十年经验的嵌入式工程师。
77% 的 AI 用户说工作量反而增加了。88% 产出最高的那批人，正在以最快的速度燃尽。
机器速度 vs 人类带宽
事情的起因是一篇叫"The Human Cost of 10x"的文章，作者 Denis Stetskov 丢出了一组数据，我觉得最扎心的是这个对比。
人类大脑处理有意识思考的带宽，大约 10 bit/s。而 GitHub 2025 年的数据显示，每个开发者的代码行数在八个月内从 4,450 涨到了 7,839，涨了 76%。AI 用户多合并了 98% 的 PR。
代码在以机器速度生成，但审查它的，还是那个 10 bit/s 的人脑。
Stetskov 引用了一个很直观的研究结论，PR 在 100 行以下时，缺陷检出率是 87%。超过 1,000 行，直接掉到 28%。审查超过 60 分钟之后，质量就崩了。
所以资深工程师每天面对的选择其实只有两个，信 AI 的输出直接合并，赌它最近表现还行；或者逐行验证每一行代码，直到身体和精神双重耗尽。
无论选哪个，凌晨三点生产环境炸了，背锅的都是你。
HN 评论区才是正片
坦率讲，文章本身的数据虽然扎实，但真正让我停下来反复看的是那 70 条评论。因为里面全是"正在经历这一切"的人。
用户 zthrowaway 说，自从引入 Agentic 开发流程以后，他们公司的故障频率"drastically increased"。团队里有人一天推 15 到 30 个 PR，根本审不过来。管理层的态度是"feature 上得快，你们自己想办法"。
用户 mynameisash 的描述更具体，他的经理要求团队持续使用 AI Agent，每周专门开一个"AI wins"的站会，绩效考核直接挂钩 AI 使用率。
你想想看，当你的 pace 不是自己定的，而是管理层替你定的，burnout 就不是个人意志力的问题了。
用户 strange_quark 说了一句很重的话，"Management doesn't care. The solution is always more AI. If you're still shipping bugs, it's because you didn't use the AI correctly."
出了问题是你没用好工具。不是工具有问题。
这逻辑是不是很眼熟？
一个被忽略的悖论
评论区里我觉得最有价值的一个线程，是关于"code review 在 Agent 时代是不是已经不可持续"的讨论。
用户 bensyverson 提了一个激进的观点，与其审查每一个 PR，不如依赖测试覆盖率，让开发者为自己 ship 的东西负责。
用户 palmotea 立刻反驳，"你这是在让人类当 fall guy"。如果老板逼你用 AI 生成代码的速度快过你审查的速度，你就被卡在了中间。短期为了不被骂你会放松审查，但出了事，责任全是你的。
用户 jart 则更直接，"LLM 对代码没有 skin in the game，它们连 skin 都没有。让机器人写你的单元测试和 dashboard，别让它写生产代码，否则 delete yourself。"
说真的，这段对话揭示了一个被行业集体忽略的悖论。AI 把代码生产速度提了上去，但审查能力的供给没有增长。培养资深工程师的 pipeline，恰恰被同样的 AI 工具掏空了，因为 junior 不再需要从零写代码，也就更难积累那种"被坑过才有"的直觉。
供需缺口只会越来越大。
身体在发出信号
文章里引用的健康数据我不想全列一遍，但有几个数字值得记住。
久坐程序员的代谢综合征发病率是 32%，是普通人群的两倍。burnout 最严重的那 20% 人群，冠心病风险高出 79%。AI 生成的代码每个 PR 的 bug 数量是人写代码的 1.7 倍，逻辑缺陷多 75%，性能问题多 8 倍。
代码量暴增 76% 到 98%，但组织级的交付效率，没有可衡量的提升。
我认为这才是最荒诞的地方。我们付出了更多的工时、更多的身体代价、更多的认知负荷，换来的是更多的代码，但不是更多的价值。
我的判断
可能有些想法还不成熟，但我还是想说。
我认为"10x 工程师"这个叙事本身就是有毒的。它把一个系统性的生产力问题，包装成了个人英雄主义。AI 确实能让你产出更多代码，但如果组织没有同步升级审查流程、测试基础设施和工作节奏的预期，那所谓的 10x 就只是把压力 10x 了。
评论区用户 TuringNYC 说了一个我觉得很务实的思路，你需要两套体系。一套是可以"play fast and loose"的系统，用 AI 10x 地干；一套是质量真正重要的系统，老老实实 1.5x 到 2x。这已经很多了。
用户 Incipient 作为 solo dev 也分享了经验，让 AI 独自跑完整个功能然后你来审，效果很差。把 AI 当 pair，边写边审，小块小块来，效果显著更好。
用户 cadamsdotcom 的建议最实操，给每一种常见的 AI 犯错模式写 linter，加到 pre-commit hook 里。AI 写的 linter 检查 AI 写的代码，非零退出码就自动修，循环到通过为止。
你能做的三件事
第一，如果你的公司正在推 AI Agent 开发流程，主动跟管理层对齐预期。把 Stetskov 文章里"代码量增加 76% 但交付效率没有可衡量提升"这个数据甩出去，用数据说话。
第二，给自己设一个硬性的审查时间上限。研究说 60 分钟之后质量就崩了，那就别硬撑。把大 PR 拆成小的再审。
第三，如果你发现自己每天盯屏幕超过 10 小时还觉得"这是正常的"，这篇文章和那 70 条评论就是你的镜子。
开头那个盯 15 个 Agent 干到 zonked out 的 Distinguished Engineer，他有三十年经验、二十多项专利。如果连他都扛不住，你凭什么觉得自己可以？
