驾驶舱里的程序员
tech午饭前我把需求交代给 agent。回来时，几千行代码静静躺摆在那里，像一桌不记得什么时候点过的菜。
这不能全怪我的勤奋。订阅制的 coding plan 自有一套朴素的经济学：按月付费，agent 停摆一分钟，我就亏一分钟。于是 claude 一闲着，倒显得是我在偷懒。如今午餐前要给它交代点什么，如厕前也要交代点什么，否则饭吃得不香，拉屎也难以顺畅。有几次实在挤不出需求，我竟坐在工位前发愁。
《人月神话》说”人月”是危险的计量单位：人和月不可互换，因为新增人手的沟通成本会吞掉并行的收益。Brooks 若看到今天，大概会觉得自己被同时证明和证伪了：执行的”人”果然无限便宜了，而沟通成本却一分没少，只是塞进了同一个人的脑子里。
在《没有银弹》里，他把软件的困难分为「偶然复杂度」和「本质复杂度」。AI 消灭的几乎全是前者——翻文档、搭脚手架、敲键盘；后者原样奉还——设计、决策、发现问题。于是决策密度大大提高，决策疲劳不可避免地成了新的质量风险。
我闲暇时间爱看《空中浩劫》，在其中接触到过 CRM（驾驶舱资源管理）这个概念。当今程序员正在经历同 1980 年代的民航飞行员类似的转型：从亲手操纵执行，变成监督一个大部分时间都正确的自动化系统。他们的经验是用坠机换来的，理论上比我们的贵一些。看看我们能学到些什么。
一、无菌驾驶舱（Sterile Flight Deck Rule）
万英尺以下，驾驶舱内禁止一切与飞行安全无关的活动。古法编程时代，我们面对复杂需求会给自己挂上免打扰，用一两个小时全身心投入方案设计。现在这样的时段在我身上濒临灭绝——我贪婪地并行了更多事项，Agent 的弹窗不断撕咬着我的注意力，而我像博爱的上帝，平等地回应每一次祈祷。我想，即便是 Agent 辅助设计，也该保留一段只做一件事的时间。
二、自动化偏信（Automation Bias）
Bainbridge 在《自动化的讽刺》里指出：自动化越可靠，人的监控就越退化，而留给人的恰恰是最难的部分——捕捉失误。AI Coding 95% 正确，比 50% 正确时更危险，因为人会被规训到轻信 agent 的总结陈述，不再看 diff 本身。我要自首：出于对 agent 的信任（主要成分是懒惰），我已无法保证读过自己产出的全部代码。
机场安检的解法很有想象力：不定时往旅客行李的 X 光图像里叠加一把假刀，专门测试安检员醒着没有。研发流程里是不是也该埋几把假刀？我还没想好埋在哪，先把问题留在这里。
三、保持手飞（Manual Flight Operations Proficiency）
航空管理机构鼓励飞行员在低负载阶段关掉自动化、亲手操纵。因为检测偏差的前提是：脑子里知道「对的长什么样」。手动飞行技能萎缩的人，失去了比对基准，同样做不好监控。
如果我们每天都依赖 agent 完成 oncall 排查修复，那在恰巧 agent 无法使用的某天，我们还有能力把系统从宕机中拯救回来吗？
编程技能好像真的会退化——前几天想”古法”写点什么，发现自己对编辑器已经有些陌生。不知道三年后的我，还能不能看懂 python 游标卡尺的笑话。写完这篇文章，我要去跟 js 的 date 斗智斗勇一会儿。不问 agent，你知道 new Date("2") 会返回什么吗？
四、告警分级（Alert Prioritization）
人在高负荷阶段认知带宽急剧收窄，如果所有告警平权地同时闪、同时响，机组反而不知道先处理哪个。刚开始并行多项目时，我在窗口间频繁切换，后来发现很多次切过去，只是庄重地回复一个「继续」。
这种不需要决策输入的打断，就是典型的低优先级告警。后来我把能自动化的部分全部串联：修改、commit、push、部署、验证，让 agent 的每一次弹窗都在需要我动脑决策，而非只是动手的时候。
五、机长和他顺从的副驾（Trans-cockpit Authority Gradient）
Brooks 曾借外科手术队伍设想理想的开发组织：一个主刀，其余人为主刀服务。今天这个设想实现了，每个人都可以带一队听话的 agent。可民航在特内里费空难学到的教训恰恰相反：如果没有人质疑机长的决策，那错误的决定会被坚持到出事为止。而 agent 又正是一位理想到可疑的副驾：不知疲倦，永远顺从，从不质疑机长。
我们是否也应该允许、甚至鼓励 agent 拥有产生质疑的能力？
ending
AI Coding 流行之前，决策是被执行能力限流的：一个迭代两周，能做的事情只有那么多，即便是错误的方案，也有足够的时间被发现。执行速度的限制是决策的隐性刹车。现在刹车被拆了，但没人通知我。
所以我想，执行层面省下来的时间，不应该全部投进需求吞吐里。应当分一部分给决策，给每个决策多一点思考，把刹车手动装回去。
祝你起降顺利。