几年前，软件开发中的AI还只是偶尔能猜中你变量名的自动补全，而今天，它更像是你旁边多坐了一个工程师——一个从不睡觉、从不抱怨上下文切换、读过的代码比任何活人都多的工程师。事实上，如果你善于编排调度，你甚至可以拥有一整支额外的工程团队，这个转变是渐进的，但正在快速加速，AI也不再是藏在你IDE里的新鲜功能了，它正在成为软件真正被构建出来的那套连接组织。工程团队要么拥抱它，要么冒着被远远甩在后面的风险。
从自动补全到自主式智能体
早期的AI编程工具本质上就是训练数据更好的自动补全引擎，有用吗?当然，但它们并没有改变软件工程这份工作的本质。开发者仍然需要思考、规划和调试;工具只是帮你省了几次敲键盘。
现在不同的是，自主式AI系统出现了，它们不再是建议你下一行该写什么的工具，而是能接收一条指令(比如"给结账表单加上输入验证，并为它写测试")，然后跨多个文件执行、运行测试套件、定位失败并自动修复的系统。开发者的工作正在从写代码转向规划、指挥、审核和打磨。换句话说，更像是在扮演技术负责人或产品经理，而不是一个码农。
在Nutrient，我们让整个工程团队都可以使用Claude Code、Codex和其他编程智能体，利用公司账户宽松的使用额度。现阶段，使用自主式AI不仅是被推荐的，更是被强制要求的：我们只在兜底情况下才手动写代码。组织层面的转型当然不容易，团队中不同成员在智能体编排方面的熟练程度也参差不齐，但对于那些走在前面的人，我们看到了生产力和影响力的巨大提升。根据我们自研的工程度量工具的数据，在短短几个月内，全公司经过影响力加权的pull request(即自包含的代码变更，按复杂度加权)数量几乎翻了一倍。
AI贯穿完整的开发生命周期
AI的影响不仅限于写代码这一个环节，它正在渗透到软件被构建、测试和维护的每一个阶段。
我们正在逼近这样一个节点：规划、设计、测试甚至调试都在变成实现细节。工程师们现在把精力集中在清晰地定义期望结果上，然后以一种能让智能体带着验证反馈循环执行的方式去编排工具。反馈仍然可以来自人类，但即便如此，也可以让智能体自动获取。比如我们想优化某个特定模块的性能——这通常被认为是一项高级工程任务。如果我们先建立好合理的基准测试，就可以直接让智能体跑一整夜，尝试不同的方法来激发更好的性能。工程师第二天早上只需要审阅报告，选出最优方案就行。
根据任务的不同，工程师现在可以选择在流程的每一步中参与多深。有时候你想和你的AI同事一起头脑风暴一个详细方案，有时候你想让它一把梭解决问题。理解在特定任务下该做哪种选择，正在成为软件工程师需要培养的一项关键新技能。
事实是，软件开发流程的每一个阶段都需要提速，才能真正从自主式AI中获得承诺的提升。代码审核需要智能体分析和与智能体的FAQ来辅助，QA测试需要借助智能体来加速编排，发布说明和文档需要由AI来撰写。如果不做出这些关键调整，只是把瓶颈转移到了组织的另一个环节而已。
有人担心这种工作方式会导致写出来的代码没人看得懂，但说实话，对于任何一个像样的大型人类编写的代码库来说，这已经是现状了。如果说有什么不同的话，AI在应对这个问题上已经变得真正有用了，代码库会累积熵增，原作者离开了，文档腐烂了。AI可以帮你从实现中反向推导意图，而这在以前需要花好几天小心翼翼地做考古挖掘。
竞争是真实的，而且对开发者有利
AI编程市场是一场激烈的竞赛，而且值得关注。除了各大平台玩家之外，一波专门为此打造的工具也涌现出来，有些聚焦于工作流中的某个特定环节，有些则试图拿下AI辅助开发的全栈。
Cursor凭借其深度的代码库集成和模型灵活性，在专业开发者中收获了一批忠实拥趸，而Copilot的VS Code集成也让它面临着强有力的竞争。Claude Code和Codex如今已成为真正意义上智能体编程的领跑者，不过也有很多其他选择，比如开源的极简编程智能体PI。与此同时，Replit和Lovable正在为非传统开发者拓展可能性的边界，而我们当然也有像OpenClaw这样能远远超越编程范畴的智能体项目。
今年五月的Google I/O和Microsoft Build上，最可能揭晓的是这些平台巨头将如何应对这种碎片化局面。两家公司都拥有分发优势：如果你已经在用他们的某些工具——不管是VS Code、Google Cloud还是Google Workspace——那阻力最小的路径就是他们捆绑的AI工具，但在开发者工具领域，最容易走的路不一定能赢，因为工程师们都有很强的主见，一旦有更好的选择就会切换。
总的来说，这些玩家之间的竞争压力对在职开发者是好事，它意味着更快的迭代、更多的模型选择、更优的定价，以及真正由真实工程反馈而非产品营销所塑造的工具。
这对开发者角色意味着什么
每当AI在能力上实现一次有意义的飞跃，那个问题就会被提起——"AI会取代开发者吗?"——而且它总是得到同一个诚实的回答：不会以人们担心的那种方式，但没错，这份工作确实在变，只有那些愿意快速且全面适应的人才有未来。
AI实际在做的事情，是压缩开发者意图与可运行代码之间的距离，这很有价值，但也带来了一系列新要求。那些能清晰表达自己需求的开发者，那些对系统有足够了解、能判断AI输出是否正确的开发者，以及那些能在何时信任工具、何时提出质疑之间保持判断力的开发者，会变得更有生产力，而那些把AI当黑箱、不加批判地接受其输出的开发者，则会制造出另一种问题。
资深工程判断的投入方向也在发生转移，当AI承担了更多的实现工作后，稀缺资源不再是代码量，而是架构、系统思维，以及只有在大规模构建和维护过真实系统后才能获得的那种上下文知识。当你周围的工具变得更强大时，这些技能不是变得不重要了，而是更重要了。
沟通在更字面的意义上变成了一项技术技能，给AI智能体写好prompt并非易事。要用足够精确的方式描述一个问题以获得有用的结果，同时又不过度指定以至于不必要地限制了解空间，这确实很难。那些将这种技能作为团队共享实践来培养的团队，会胜过那些把它当作个人怪癖的团队。
关于接下来会发生什么的残酷真相
让我们诚实地面对一个行业倾向于回避的问题：我们不是在渐进式地改进软件开发，我们正在拆解它的基本假设。"构建软件需要大型专业团队以月为周期协同工作"这个观念正在迅速过时。一个拥有合适智能体配置的工程师，现在就能完成过去需要一整个小团队才能做到的事，而且这个差距还在不断拉大。
这对很多人来说并不是一个令人舒适的认知，它引发了关于团队结构、招聘，以及当一个擅长AI编排的初级开发者能超越一个拒绝适应的资深工程师时，"资历"到底还意味着什么等一系列尖锐问题。在Nutrient，我们已经看到了这种动态的上演。那些早早拥抱变化的工程师不只是更快，他们是在一个完全不同的高度上运作，用系统和结果来思考，而不是用代码行和文件。
真正的风险不是AI取代开发者，而是这个行业会分裂成两个层级：那些已经将AI内化为自己思考和工作方式核心部分的人，以及那些仍然把它当作一个迟早要学的功能来对待的人，后一类人正在耗尽他们的跑道，适应的窗口不是最终才会关闭——它正在此刻关闭。
