宝玉从TL到EM的实战经验,告诉你什么时候可以放心让AI写代码,连Rust都能零基础用起来。
宝玉分享了他使用Coding Agent时从技术主管(TL)转向工程经理(EM)的角色变化。此前他需深度参与系统设计与代码审查,成为Agent的瓶颈。转折点在Fable 5之后,他发现AI代码质量足以信任,转而更多关注全局规划与结果验收。通过这种模式,开发BaoCut时实现每天一个小版本迭代。技术选型上,他从熟悉的Electron转向不熟悉的Swift+AppKit,甚至用从未写过的Rust完成跨平台版本。
今年以来,我在使用 Coding Agent 方面有一个很大的变化,就是从 TL(Teach Lead) 的角色变成了 EM(Engineering Manager) 的角色。 这两个角色主要差别在...
今年以来,我在使用 Coding Agent 方面有一个很大的变化,就是从 TL(Teach Lead) 的角色变成了 EM(Engineering Manager) 的角色。 这两个角色主要差别在技术参与深度多少。 之前我更像一个 TL,虽然不是说事必躬亲,但是系统设计、代码审查什么的肯定是少不了的,说到底还是对 AI 写的代码不放心。 这样虽然质量更有保障,但是人会成为 Agent 的瓶颈,很多事情需要人去决策,细节需要人去掌握。 转折点在 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 的时候,基本上可以每天一个小版本迭代。 baocut.app/releases/ 这两天速度慢下来了,是因为需要构思新的大版本,这时候人就又成了瓶颈了:如果人没想清楚该做什么,Agent 再厉害也帮不上。 宝玉 @dotey 通常北美的工程技术相关的职业分成以下五个类别: 开发工程师 SE / SDE(Software Engineer / Software Development Engineer) 工程经理 EM / SDM(Engineering Manager / Software Development Manager) 技术主管 TL / TLM (Tech Lead / Tech Lead Manager) 技术项目经理 TPM (Technical Program Manager) 产品经理 PM (Product Manager) baoyu.io/blog/engineeri… 🔗 View Quoted Tweet 💬 3 🔄 3 ❤️ 10 👀 2212 📊 5 ⚡
- AI Will07-28 07:37原文