你的工程师不是问题。问题是你交给他们的工作。
诚实地看看最后的冲刺。其中有多少是在构建新的东西，有多少是在监督已经部署的东西？
值班轮班。分类轮换。调查以缺少空检查而结束。一年内对同一回归进行三次事后分析。一个平台团队在技术上是一个平台团队，但在实践中存在是为了保持正常运转。一个 Slack 频道称为 #消防 没有人愿意静音，因为静音让人感觉不负责任。
我们确信这是工程。
事实并非如此。就是监督。
昂贵的作品并不总是令人印象深刻的作品
从表面上看，生产维护可能看起来很严肃。仪表板已打开。线程正在移动。日志正在滚动。工程师们在压力下做出判断。
其中一些工作是必要的。其中很多只是组织要求人类成为不完全自动化的备份系统。
您团队中最好的工程师不会加入刷新事件通道、比较相同的部署窗口两次或维护管道直到出现红色事件。他们联合起来构建产品、改进架构、消除限制并创造影响力。
当每周三分之一的时间用于生产监督时，公司损失的不仅仅是时间。它失去了高级工程师思考未来的复合效应。
该模式会重复，因为循环是手动的
大多数重复性生产工作都遵循熟悉的路径：
- 有些事情失败了。
- 警报到达人类。
- 人类打开跟踪、日志、部署历史记录和最近的提交。
- 有人问谁拥有该服务。
- 团队争论这是否是一个错误、部署不当、上游问题或数据边缘情况。
- 实际的修复效果很小。
修复并不总是困难的。解决问题是整个下午的重点。
这种差距就是团队失去产品动力的地方。这也是人工智能代理可以在不夺走工程师控制权的情况下提供帮助的地方。
到2026年，这是一个可以解决的问题
自我修复软件并不意味着模型默默地改变生产。这并不是认真的工程团队想要的。
更好的模型更窄且更有用：
- 读取痕迹
- 总结失败
- 比较部署
- 找到可能的回归
- 识别所有者
- 起草拉取请求
- 出示证据
- 等待批准
这为工程师节省了时间，同时又不消除工程判断力。人类仍然会审查诊断、编辑补丁、检查测试并决定是否合并。
代理人办理监督工作。工程师负责做出决定。
CTO 的问题正在发生变化
本季度每位 CTO 面临的问题不仅仅是“我们有足够的工程师吗？”
这也是“为什么我们的工程师要做代理可以在 90 秒内准备好的工作，同时还要等待人工批准来交付修复程序？”
如果答案是合规性、所有权或安全性，那就是有效的。这些限制很重要。但他们并不要求审查前的每一步都保持手动。
团队可以保持控制并仍然自动化从生产信号到审查拉取请求的重复路径。
把设计时间还给工程师
您最强大的工程师不应该错过产品工作，因为他们正在读取 40,127 行日志输出。
它们不应该成为 CI/CD 的冗余层。
他们不应该在周二下午再次证明同样的回归又回来了。
他们应该建造公司实际筹集资金建造的东西。
目标不是消除运营责任。目标是停止将人类注意力视为系统中最便宜的监控原语。
你的工程师应该负责建造，而不是照看孩子。给他们时间去建设。
