每个开发者都应该成为 Tech Lead

关于 AI 和软件开发，现在最常见的问题还是：AI 会不会取代 developer？

这个问题可以理解，但它问得太粗了。它把 developer 想象成一个单一的执行单位：拿到需求，写代码，修 bug，交付功能。如果这个定义成立，那么 AI 确实会持续挤压很多开发工作的价值。因为写一个函数、生成一个组件、补一组测试、解释一段陌生代码，这些动作正在变得越来越便宜。

但 developer 的价值从来不只是执行。

过去，一个强 Tech Lead 的价值在于：他能理解系统，拆解问题，判断技术方向，协调多人工作，识别风险，并把事情推到交付。写代码当然重要，但那不是全部。更稀缺的是他能把一团模糊的工作，变成一个可以被多人可靠执行的技术系统。

Agent 时代真正改变的，是这件事不再只属于少数 Tech Lead。

当可被指挥的执行力变得便宜，每个 individual contributor 都要学会领导一套小型工程系统。这个系统里可能有自己，有 coding agent，有 research agent，有 testing agent，有 documentation agent，有设计和产品推理 agent，也有其他人类协作者。

所以我越来越相信一个判断：

Every developer should be the tech lead.

但这里的 Tech Lead 不是传统职级，不是管理头衔，也不一定意味着带人。它是一种新的工作能力：你能不能领导一个由 agent、人和工具组成的系统，让它们一起高质量完成复杂任务。

旧角色是执行密集的

过去，developer 的日常工作里有大量执行动作。

你读需求，开分支，写代码，查文档，调 API，跑测试，修 lint，写 PR 描述，回应 review，补文档。很多时候，能力差异体现在谁能更快、更稳、更少犯错地完成这些动作。

这当然仍然重要。深层技术理解不会消失。代码 taste 不会消失。debug 能力也不会消失。

但这些执行动作的经济性已经变了。

一个 agent 可以在几分钟内起草实现，搜索 repo，生成测试，解释错误，重构重复代码，整理 release note。它不一定总是对，也不一定总是好，但它已经足够改变工作分工。

如果你仍然只把自己定位成“亲手完成所有执行动作的人”，你会和越来越便宜的执行力竞争。

这不是一个好位置。

执行单位变了

过去，一个任务的基本执行单位通常是一个人。

现在，一个任务的执行单位越来越像一个小型系统。

你可以让一个 agent 先读代码库，另一个 agent 查相关文档，第三个 agent 写实现，第四个 agent 从测试和安全角度 review。你自己不再只是坐在中间等结果，而是在不断定义目标、收窄范围、分配任务、审查输出、整合判断。

这听起来像管理。

但它更准确地说，是技术领导。

管理通常关心人、组织、激励、绩效和长期成长。新的 Tech Lead 型 IC 关心的是工作系统：目标是否清楚，任务是否拆得对，agent 是否拿到了足够上下文，输出是否可验证，多个结果是否能被整合成一个干净的技术决定。

这不是把 IC 变成 manager。

这是把 IC 变成自己那支 agent 工程团队的技术负责人。

瓶颈会上移

当执行力变便宜，真正稀缺的东西就会向上移动。

稀缺的不再是“能不能写出一版代码”。很多系统都能写出一版。稀缺的是：

• 什么问题值得解决？
• 这个需求应该被拆成哪些子问题？
• 哪些部分适合交给 agent，哪些必须自己判断？
• agent 的输出有没有误解系统？
• 哪些结果应该被接受，哪些应该被丢掉？
• 多个 agent 给出的不同答案，应该如何整合？
• 什么时候该继续探索，什么时候该收敛交付？

这些问题本来就是 Tech Lead 工作的一部分。

只是以前，一个 Tech Lead 协调的是几个人。现在，一个强 IC 也可能每天协调多个 agent、工具、测试 harness、文档 artifact 和少量人类协作者。

这就是角色变化的核心。

未来 developer 的分层，可能不再只是 junior、mid、senior、tech lead。更真实的分层会变成：

• 被 agent 替代的执行者
• 使用 agent 加速自己的工程师
• 指挥 agent 完成复杂工作的 Tech Lead 型 IC

第三种人不是 prompt 写得更花。他们真正强的地方，是能让一套系统朝正确方向运转。

新 Tech Lead 不是经理

这个概念最容易被误解的地方，是把 Tech Lead 听成 title。

我不是说每个 developer 都应该去管人，开会，做 roadmap，或者变成组织协调者。很多开发者最有价值的状态，仍然是深度 IC。

但深度 IC 在 agent 时代也会变。

过去的深度 IC，往往通过个人技术能力穿透问题。他可以自己读完系统，自己写关键路径，自己做架构判断，自己把复杂问题扛下来。

新的深度 IC，仍然需要这些能力，但他还要多一层：能把自己的技术判断外化成一个可执行、可审查、可迭代的工作系统。

他会写的不只是代码，还有 brief、task breakdown、review criteria、eval checklist、handoff note。他会关心的不只是 diff 能不能跑，还有 agent 为什么这么做、它遗漏了什么、它是否违背了系统已有的 taste。

他不是把工作扔给 AI。

他是在领导工作。

新能力栈

我会把新的能力栈拆成七件事。

Intent definition. 先定义目标，而不是立刻要求 agent 开始做。好的 intent 会说明用户、问题、边界、成功标准和不该做什么。

Task decomposition. 把一个模糊目标拆成可以并行、可以验证、可以回滚的子任务。拆错了，agent 越努力，浪费越大。

Agent orchestration. 知道什么时候让 agent 查资料，什么时候让它写代码，什么时候让它只读不改，什么时候让多个 agent 独立给出方案。

Review. 不把 agent output 当成结果，而是当成候选材料。强 developer 会审查假设、边界、错误路径、安全影响和长期维护成本。

Eval. 为结果建立可验证的标准。测试、lint、benchmark、人工 review、产品判断，都是 eval 的一部分。这和我之前写的 Taste、Intent 和 Eval 是同一个闭环。

System thinking. 理解代码库不是文件集合，而是一套带历史、约束和惯性的系统。Agent 可以生成局部答案，但人要负责系统后果。

Taste. 最后仍然是 taste。知道什么是刚刚好，什么是过度设计，什么只是看起来完整，什么真正能留下来。

这些能力听起来抽象，但它们会非常具体地改变日常工作。

日常工作会怎么变

一个 Tech Lead 型 IC 开始任务时，不会只写一句“帮我实现这个功能”。

他可能先写一个 brief：我们要解决什么，为什么现在做，第一版边界是什么，哪些文件可能相关，哪些行为不能破坏。

然后他让 agent 做只读 inventory。不是立刻改代码，而是先理解系统。

接着他拆任务：一个 agent 研究现有实现，一个 agent 草拟方案，一个 agent 找风险，一个 agent 补测试思路。等这些材料回来，他不会平均接受，而是做技术判断：保留什么，丢掉什么，合并什么。

实现阶段，他会把改动收窄，让 agent 处理机械部分，自己审关键路径。验证阶段，他会要求明确证据：跑了什么测试，覆盖了什么路径，哪些还没证明。

最后，他会留下 artifact。不是为了流程好看，而是为了让未来的自己、团队成员或另一个 agent 能接上上下文。

这套工作方式看起来比“直接让 AI 写代码”慢。

但在复杂任务里，它更快。因为真正慢的从来不是生成第一版代码，而是发现第一版代码解决了错误的问题，或者引入了你没有意识到的复杂性。

最大的风险是放弃判断

Agent 时代最危险的 developer，不是完全不用 AI 的人。那当然会慢。

更危险的是大量使用 AI，却不承担技术判断的人。

他把模糊需求丢给 agent，把 agent 输出当作完成，把测试通过当作正确，把文档生成当作理解，把漂亮 demo 当作产品质量。

这种工作方式短期会显得非常高产。

直到系统开始积累看不见的债务：抽象变多，边界变软，测试只覆盖 happy path，文档解释的是错误假设，代码库表面更完整，但更难理解。

AI 会放大能力，也会放大坏习惯。

如果一个 developer 没有 taste，agent 会帮他更快地产出平庸。如果一个 developer 没有 eval，agent 会帮他更快地相信错误。如果一个 developer 没有 intent，agent 会帮他更快地跑向错误方向。

所以新的 Tech Lead 能力，核心不是控制更多 agent。

核心是承担更多判断。

个人生产力会变成组织能力

这也是我觉得这个转变重要的原因。

以前，组织能力主要存在于团队和公司层面。一个人能做的事情有上限。复杂项目需要多人协作，需要流程，需要 manager，需要 Tech Lead。

Agent 让一部分组织能力下沉到了个人。

一个强 IC 可以拥有自己的 research capacity、implementation capacity、testing capacity、documentation capacity 和 review capacity。它们不等同于真正的团队，也不能替代所有人类协作，但它们足以改变个人能承担的问题规模。

未来最强的 developer，不一定是打字最快的人，也不一定是最会背 API 的人。

他会更像一个小型技术组织的 operator。

他知道什么时候自己写，什么时候让 agent 写。什么时候并行探索，什么时候停止探索。什么时候相信测试，什么时候怀疑测试。什么时候接受一个粗糙但正确的方案，什么时候拒绝一个漂亮但脆弱的方案。

这就是 Tech Lead 工作。

只是它正在从少数人的正式角色，变成每个 AI-native developer 的基础能力。

结论

AI 不会简单地让 developer 消失。它会重新定义什么样的 developer 值钱。

如果你的价值主要来自执行固定任务，那么 agent 会持续逼近你。如果你的价值来自把模糊问题变成清晰目标，把复杂工作拆成可执行系统，审查输出，整合判断，并对最终质量负责，那么 agent 会放大你。

这就是我喜欢这个句子的原因：

In the AI era, every developer becomes the tech lead of their own agent-powered engineering team.

中文说就是：

在 AI 时代，每个开发者都会成为自己那支 agent 工程团队的 Tech Lead。

这不是职级膨胀。

这是软件工作的重心变化。

代码正在变便宜。可被指挥的执行力正在变便宜。真正变贵的，是能领导这些执行力的人。