码农的核心竞争力：从编码者到编排者的进化
TL;DR: AI 正在把写代码这件事从人手里收走。工程师的角色正从「编码者 → 指挥者 → 编排者」进化，核心竞争力不再是写代码的能力，而是组织工作、验证结果、驾驭 Agent 的能力。2028 年之前，这场转变将基本完成。
前置知识：本文假设读者了解 AI 编程助手（Cursor、Claude Code、GitHub Copilot）的基本用法。关于如何系统性地驾驭 AI 模型，可以参考 Harness Engineering；关于结构化的 AI 协作方法论，可以参考 Spec 驱动开发。
一个正在发生的身份危机
2024 年初，AI 辅助编程本质上是一个「大幅增强的自动补全」。你让 AI 写那些枯燥的、模式化的代码——文档注释、工具函数、数据模型、测试。它帮你提速，但方向盘在你手里。工程师是司机，AI 是巡航控制。
到 2025 年，部分自主的 Agent 出现了。你给一句指令，它自己拆解任务、跨文件实现。工程师的角色变成了「指挥者」——像乐团指挥一样给出指示，然后坐下来听结果、给反馈、重复循环。从巡航控制升级到了半自动驾驶。
2025 年底，完全自主的后台 Agent 把事情又推了一步。你不再需要同步盯着一个 AI 会话，而是可以同时编排多个 Agent——前端一个、后端一个、数据层一个，各自独立工作，完成后通知你审查。工程师变成了「编排者」。
Addy Osmani 把这个趋势总结得很精炼：we’re moving from coder to conductor to orchestrator。
这个趋势不是假设，是正在发生的事。问题在于：当写代码不再是工程师的核心工作时，码农的核心竞争力到底是什么？
从文本编辑器到任务管理器
如果工程师的主要角色是编排 Agent，那 IDE 的形态必然要变。
传统 IDE 的一切都在围绕「编辑代码」设计：语法高亮、自动补全、代码导航、调试断点。这些功能的前提是——人要亲手写代码。
但当 Agent 在云端写代码时，人需要的界面变成了：哪些任务在排队、哪些已完成、哪些卡住了需要介入。你可以在多个 Agent 会话之间切换，每个会话是一个 chat 界面，让你与 Agent 交互迭代。
GitHub Mission Control 和 VS Code 的 agents panel 已经在做这件事。Google Antigravity 更激进——它把 Agent 管理放在前台，代码推到后台。用户体验优化的是「快速扫描 Agent 状态」，而不是「高效编辑文本」。
可以预见的下一步是：IDE 允许你把不同 Agent 的输出合并成一个完整项目。前端 Agent 负责组件、后端 Agent 负责 API、数据层 Agent 负责 schema，IDE 提供一个界面把三者编织在一起。
按这个速度，2028 年大多数 IDE 的主界面会是 Agent 管理面板，而不是代码编辑器。
从手动编码到禁止手动编码
这一步听起来极端，但逻辑很顺畅。
一旦 AI 写的代码质量超过人类，为什么还要让人碰代码？人类手动编辑只会引入不必要的风险和 bug。这和自动驾驶的逻辑一样——一旦自动驾驶足够成熟，人类驾驶反而会被视为危险和不可预测的行为。保险公司的反应会是：人类驾驶的保费大幅上涨。
在高风险系统（自动驾驶、医疗、金融）中，这个转变会来得更快。代码会被视为「太重要了，不能交给不可靠的人类」。就像今天没有 Fortune 500 公司会考虑手工做账一样，未来让人类直接编辑源代码会被认为是不负责任的。
保险行业可能会加速这个过程——要求「所有代码编辑必须经过 AI 审查，AI 在编辑过程中同时检查错误和安全问题」作为投保条件。这个转变大概会在 2030 年前后初见端倪。
从代码审查到任务验证
当前工程师的核心价值之一是审查代码——确保它满足需求、遵循最佳实践。在这个阶段，源代码主要充当「人类审计工具」的角色。
但 AI 在代码审查上追上人类只是时间问题。审查代码比写代码更复杂，因为审查者需要正确的上下文来理解代码。不过 AI 最终会跨过这个门槛。
更可能出现的流程是：一个 Agent 生成代码，另一个 Agent 审查并给反馈，第一个 Agent 修改，循环往复直到代码达标。Google Antigravity 已经在实现类似流程——Agent 生成代码后自动执行验证计划。
当 Agent 之间达成一致后，人的工作简化为：验证「我要求的任务是否完成了」。而且这一步也不再依赖代码审查——Agent 会提供 UI 截图、交互视频作为验证材料。你看完截图和视频，确认功能正确，一键部署。
审查的对象从代码变成了产出物。工程师从「代码审查者」变成了「任务验证者」。
从工程团队到最小可行工程团队
一个编排者 + 多个 Agent，产出相当于过去多个工程师的工作量。这意味着工程团队的规模必然缩小。
但「最小可行工程团队」（Minimum Viable Engineering Team, MVET）不会是一个人。几个非技术因素决定了团队的下限：
- 孤独感：人是社交动物，一个人闷头编排 Agent 可能并不高效。和其他工程师讨论方案、互相验证思路，可能比单打独斗产出更好。
- 单点故障：一个人休假、生病、离职，项目就停了。为消除 SPOF 多雇一个人是值得的保险。
- 领域专精：一个复杂系统涉及前端、后端、数据库、安全、基础设施。期望一个人在所有领域都是专家不现实。公司可能仍然需要一个前端专家、一个后端专家、一个数据库专家分别编排各自领域的 Agent。
- 人才梯队：公司需要工程师离职后的继任计划。至少一个高级 + 一个初级的配置，既消除 SPOF 又保证连续性。
已经有公司在 2025 年尝试大幅缩减工程团队。我的判断是：过度缩减的公司会为此付出代价，并最终意识到 MVET 永远不是一个人。
不过团队确实会变小。过去那种因为「需要写很多代码」而大量招人的模式会消失——AI 能以更低的成本产出更高质量的代码。那些「勉强能写代码但产出平庸」的工程师将没有位置。
从交付代码到交付价值
当写代码不再是核心能力时，哪些技能才重要？
答案是那些通常在从初级工程师晋升到高级工程师、再到 Tech Lead 过程中才学到的技能——组织工作、分配任务、审查结果、确保交付价值。
很多 Tech Lead 最初都会不适应：他们不得不减少写代码的时间，转而做审查技术方案、分配任务、指导他人这些事。但最终他们会理解——他们可以通过多种方式交付价值，而不只是写代码。事实上，他们可以成为团队的「乘法器」，让每个人都更高效。
但这里容易有一个误解：认为「交付价值」就是「管人变成管 Agent」。不是。真正拉开差距的，是你对业务和架构的理解深度。Agent 可以写出技术上正确的代码，但它不知道你的支付系统为什么要用最终一致性而不是强一致性，不知道你明年要从单体拆微服务所以当前的数据库设计要预留分库分表的能力，不知道你的用户增长模型决定了某个模块三个月后会成为瓶颈。这些判断来自对业务的深入理解和对系统演进方向的洞察。一个优秀的编排者不只是「把任务分给 Agent」，而是知道该分什么任务、为什么分、分完之后对整体架构的影响是什么。
这正是 Tech Lead 和高级 IC 之间的分水岭。高级 IC 擅长解决技术难题，但 Tech Lead 能站在业务和架构的高度，判断「该不该做这件事」比「怎么做这件事」更重要。当 Agent 接管了「怎么做」之后，「该不该做」和「做什么」就成为了工程师最核心的判断力来源。
未来的工程师从职业生涯第一天就需要像 Tech Lead 一样思考。以下是关键技能：
- 业务理解：理解产品为什么存在、用户是谁、商业模式是什么。技术决策必须服务于业务目标——一个在技术上完美但不符合业务节奏的方案，就是错误的方案。
- 架构设计：从整体视角设计系统——模块边界、数据流、扩展性、演进路径。Agent 可以实现你描述的架构，但架构方向本身需要人来决定。这包括判断什么时候该引入复杂性、什么时候该保持简单。
- 组织能力：编排多个 Agent 需要制定「飞行计划」——工作如何拆分、并行执行、合并结果。包括日志和可观测性设计，确保 Agent 工作流可追溯。
- 沟通能力：团队人更少，但跨职能沟通反而更重要。误解更可能导致返工。你需要把技术判断翻译成业务语言，也要把业务需求翻译成 Agent 能执行的技术指令。
- 系统思维：不能只关注某个组件，需要理解各部分如何组成整体。这意味着看一张架构图时，你能说出哪些耦合是必要的、哪些是历史包袱、哪些会在下一个季度成为问题。
- 模型选择：知道哪个模型适合哪类任务。Claude 4.5 Sonnet 和 Claude 4.5 Haiku 什么时候该用哪个？
- Prompt 工程：与 Agent 交互的核心技能。Prompt 需要足够具体以防 Agent 误解。提供示例和反例、使用步骤和列表、把复杂任务拆成单独 prompt，都是关键工具。
- 输出验证：大量工作将是验证 AI 输出。需要建立确定性的工作流来评估结果，在部署到生产环境之前识别不完整或有错误的内容。
- 调试工作流：当 Agent 没有产出预期结果时，需要调试工作流定位问题根源。
- 面向 Agent 的信息管理：文档对 Agent 至关重要。信息需要为 AI 消费而结构化，检索系统需要让 Agent 能按需获取最新数据。
- 安全：确保 Agent 不访问敏感系统、不遭受 prompt injection 或 jailbreak 攻击。即使是云端 Agent 也可能逃逸沙箱。
- 预算管理：工程师可能获得每周或每月的 AI 预算（美元、token 或信用额度）。理解特定模型的输出价值与生成成本之间的关系，将成为重要技能。
过去，「能写出可运行的代码」就能拿到初级工程师的 offer。现在 AI 已经把代码生成商品化了，这个能力不再够用。企业看重的技能正在转变——它们更难教、更依赖实战经验。软件工程岗位会吸引更多「想解决问题的人」而不是「想写代码的人」。
局限性与权衡
时间线的不确定性。文中提到的 2028 和 2030 时间节点是基于当前趋势的推断。技术发展不是线性的——可能因监管、安全事件或技术瓶颈而减速，也可能因突破性进展而加速。
适用场景的差异。在高风险系统（金融、医疗、自动驾驶）中，AI 编码 + 人类验证的模式可能更快落地。但在创意驱动的产品（游戏、艺术工具、社交应用）中，人类直觉和审美判断仍然不可替代——至少在短期内如此。
对初级工程师的冲击。这场转变对初级工程师影响最大。「入门级编码工作」正在消失，但行业还没有建立起替代的人才培养路径。实习和学徒制可能需要重新设计，让初级工程师从第一天就学习编排和验证，而不是从写 CRUD 开始。
个体差异。不是所有工程师都会顺利转型。有些人热爱写代码本身，把编排 Agent 视为「不是真正的工作」。行业的吸引力可能会下降，导致人才流失。但留下来的人，工作会变得更有创造性和战略性。
组织惯性。即使工具就绪，组织变革也需要时间。管理层需要理解 MVET 的价值，保险行业需要更新政策，招聘标准需要重新定义。这些都不是技术问题，而是社会和制度问题。
进一步阅读
- Conductors to Orchestrators: The Future of Agentic Coding — Addy Osmani 对 coder → conductor → orchestrator 趋势的原始阐述
- Harness Engineering — 系统性驾驭 AI 模型的外部配置框架
- Spec 驱动开发 — 从需求到代码的结构化 AI 协作方法论
- GitHub Copilot Coding Agent — GitHub 的自主编码 Agent
- Google Antigravity — Google 的 Agent-first 开发环境
- Cursor Cloud Agents — Cursor 的云端自主 Agent
- TOON - Token-Oriented Object Notation — 面向 LLM 的高效数据格式，可能预示未来编程语言的演进方向
- On Pair Programming — 即使在 Agent 编排时代，结对编程仍可能提升产出质量
"Code is poetry written for machines, but read by humans. Optimize for the latter."