从 TL 转向 EM：使用 Coding Agent 不再盯紧代码细节后的开发范式转变

从 TL 转向 EM：使用 Coding Agent 不再盯紧代码细节后的开发范式转变 作者分享了使用 Coding Agent 的角色转变：从像 Tech Lead 一样事必躬亲把控代码细节，转向像 Engineering Manager 一样侧重全局规划与结果验收。这一转变释放了 Agent 的生产力，拓宽了技术选型边界，并将核心瓶颈转移到了前期的思考与规划上。 转变前人会成为 Agent 的瓶颈，需要盯紧系统设计和代码审查；Fable 5 后由于代码质量提升，工作模式变为先定方案，再由 Agent 自行编写代码、自动化测试和修复 Bug，人仅负责验收结果。 技术选型摆脱了个人的技能树限制，作者在开发应用时从熟悉的 Electron 转向原生 Swift + AppKit，随后即使零基础也能直接采用 Rust 开发跨平台版本。 开发流程的瓶颈由编码转移至需求构思与方案决策，若人没有想清楚要做什么，Agent 便无法发挥效能。 管理角色的转变与工作流重塑 作者此前担任 TL 角色，因对 AI 代码不放心而深度介入代码审查与决策，导致人成为生产力瓶颈。在 Fable 5 之后，AI 代码质量显著提升，作者转向 EM 角色，不再细看代码。新流程通常是由人与 Agent 共同制定技术方案，通过指令让 Agent 执行编码与自动化测试；遇到 Bug 时仅需向 Agent 描述问题让其重现、补充测试覆盖并修复，人只在最终阶段进行功能验收。 突破个人技能限制的技术选型 处于 EM 视角后，技术选型不再依赖个人擅长或喜欢的工具，而是选择最适合项目的技术栈。作者在开发字幕翻译应用时，先是从熟悉的 Electron 换成并不熟悉的 Swift + AppKit 以解决性能问题；在设计 BaoCut 新版本时，更在没有写过一行 Rust 代码的前提下选用 Rust 作为跨平台方案，且在 AI 辅助下顺利完成了首个版本开发。 生产力瓶颈的转移 在全权交由 Agent 编写代码的模式下，BaoCut 能够实现每天一个小版本的快速迭代。在此背景下，开发速度受阻往往不是因为编码效率，而是因为需要构思新版本规划。真正的瓶颈从写代码转变为人能否想清楚业务需求与产品方向。

从 TL 转向 EM：使用 Coding Agent 不再盯紧代码细节后的开发范式转变 作者分享了使用 Coding Agent 的角色转变：从像 Tech Lead 一样事必躬亲把控代码细节，转向像 Engineering Manager 一样侧重全局规划与结果验收。这一转变释放了 Agent 的生产力，拓宽了技术选型边界，并将核心瓶颈转移到了前期的思考与规划上。 转变前人会成为 Agent 的瓶颈，需要盯紧系统设计和代码审查；Fable 5 后由于代码质量提升，工作模式变为先定方案，再由 Agent 自行编写代码、自动化测试和修复 Bug，人仅负责验收结果。 技术选型摆脱了个人的技能树限制，作者在开发应用时从熟悉的 Electron 转向原生 Swift + AppKit，随后即使零基础也能直接采用 Rust 开发跨平台版本。 开发流程的瓶颈由编码转移至需求构思与方案决策，若人没有想清楚要做什么，Agent 便无法发挥效能。 管理角色的转变与工作流重塑 作者此前担任 TL 角色，因对 AI 代码不放心而深度介入代码审查与决策，导致人成为生产力瓶颈。在 Fable 5 之后，AI 代码质量显著提升，作者转向 EM 角色，不再细看代码。新流程通常是由人与 Agent 共同制定技术方案，通过指令让 Agent 执行编码与自动化测试；遇到 Bug 时仅需向 Agent 描述问题让其重现、补充测试覆盖并修复，人只在最终阶段进行功能验收。 突破个人技能限制的技术选型 处于 EM 视角后，技术选型不再依赖个人擅长或喜欢的工具，而是选择最适合项目的技术栈。作者在开发字幕翻译应用时，先是从熟悉的 Electron 换成并不熟悉的 Swift + AppKit 以解决性能问题；在设计 BaoCut 新版本时，更在没有写过一行 Rust 代码的前提下选用 Rust 作为跨平台方案，且在 AI 辅助下顺利完成了首个版本开发。 生产力瓶颈的转移 在全权交由 Agent 编写代码的模式下，BaoCut 能够实现每天一个小版本的快速迭代。在此背景下，开发速度受阻往往不是因为编码效率，而是因为需要构思新版本规划。真正的瓶颈从写代码转变为人能否想清楚业务需求与产品方向。

今年以来，我在使用 Coding Agent 方面有一个很大的变化，就是从 TL（Tech Lead）的角色变成了 EM（Engineering Manager）的角色。 这两个角色主要差别在技术参与深度多少。 以前：AI 写代码，我必须盯到代码层 之前我更像一个 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 再厉害也帮不上。