从代码一线到管理决策：AI 时代的价值重定向

今年以来，我在使用 Coding Agent 方面有一个很大的变化：从 TL（Tech Lead）的角色转变成了 EM（Engineering Manager）的角色。

之前，我更像一个 TL。虽然不是事必躬亲，但系统设计、代码审查之类的工作肯定少不了。说到底，还是对 AI 写的代码不放心。

这样做虽然更能保障质量，但人也会成为 Agent 的瓶颈：很多事情需要人来决策，许多细节需要人去掌握。

转折点：Fable 5 之后，我开始相信结果

转折点出现在 Fable 5 前后。我发现 AI 写出的代码质量已经相当不错，只要稍加验证，就不会出现太大的偏离。因此，我越来越少干预 AI 写代码，而是站在更全局的视角看待整个项目。

这极大地释放了 Agent 的生产力。大多数时候，我想好要做什么功能后，会先和 Agent 一起制定技术方案。确认方案没有问题后，再用 /goal 加上方案，让 Agent 自行执行、编写代码和自动化测试。完成后，我再验收一下功能，基本不会仔细查看代码。

出现 Bug 时，我会把 Bug 描述交给 Agent，让它自行复现并解决，同时要求 Agent 补充相关的测试覆盖。修复完成后，再由人进行验证。

这样做还有一个好处：在进行技术选型时，不会再局限于自己的偏好和擅长领域。

当你处于 TL 的角色时，还是会有些过度关注技术实现。包括技术选型，也容易偏向自己熟悉和喜欢的技术，而不一定选择最适合项目的方案。

当你以 EM 的角色进行技术选型时，就不再关注自己擅长什么，而是关注什么技术最适合这个项目。

因为我熟悉前端，所以最开始开发字幕翻译 App 时，会优先考虑 Electron 这样的技术栈。毕竟自己熟悉，遇到问题能够解决，代码也能写出来。

后来发现 Electron 的性能很难令人满意，于是改用了 Swift + AppKit 原生技术栈。原本我并不熟悉 Swift，但有 AI 辅助后，整个过程毫无压力。

现在，在设计 BaoCut 的下一个大版本时，需要考虑跨平台方案，首选是 Rust。哪怕我从来没有写过一行 Rust 代码，我也知道它是一个很好的跨平台选择。

目前，基于 Rust 的第一个版本已经写完了，整个过程几乎没有遇到任何语言层面的障碍。

通过这种模式，我在开发 BaoCut 时，基本上可以做到每天迭代一个小版本。https://baocut.app/releases/

这两天速度慢了下来，是因为需要构思新的大版本。这时，人又成了瓶颈：如果人没有想清楚应该做什么，Agent 再厉害也帮不上忙。