在 2026 年初突然刷屏的 Clawdbot 又给 AI 编程的火爆添了一把柴，根据项目创始人 Peter Steinberger 的说法，他一个人完全用 AI 写出了这个超级 AI 助手。
另一边，一些公司已经在内部明确表态：不再招聘初级工程师。
表面上看，这是 AI 工具能力突飞猛进带来的自然结果，但真正深入到一线团队，会发现事情并没有那么简单。 在一场围绕 AI Coding 的深度对谈中，几位长期把 AI 用在真实生产系统中的实践者，描述的并不是“未来畅想”，而是已经发生的变化。
一、手工写代码，正在退出工作流中心
过去一年，AI 在开发流程中的角色发生了明显变化。
它不再只是补全代码、查文档的工具，而是逐步进入设计、实现、评审等多个关键环节。 有的人发现自己已经很少完整手写代码； 有的人甚至不再频繁打开编辑器，而是通过与 AI 的连续对话推进工作。
变化的重点不在于“AI 写得有多好”，而在于人把精力从执行细节中抽离出来，开始更多地处理抽象层面的事情： 需求是否清楚、方案是否合理、架构是否可控。
二、代码变得便宜，但系统判断变得昂贵
一个在多个团队中反复出现的现象是：
“能跑”的代码越来越容易得到，但“该不该这样跑”变得更难判断。
AI 极大降低了实现成本，却同时放大了决策的重要性。 不同方案在功能层面可能都能成立，但在可维护性、安全性、扩展性上的差异，会在后期被迅速放大。
这也导致一个结构性变化： 依赖熟练度、手速和经验积累的中间层工程角色，正在被持续压缩。
三、脱离实战的 AI 方案，正在快速失去价值
在讨论 AI 编程工具时，几位实践者的标准高度一致：
是否在真实生产环境中交付过、处理过真实业务，是唯一可信的衡量方式。
不少“完整 AI 研发方案”在展示时看起来体系完备，但一旦进入真实业务场景，就会暴露出大量问题： 需求偏差、架构不一致、质量波动难以控制。
因此，对“照着大厂样板直接复制”的做法，态度普遍偏谨慎。 在真实系统中，能跑起来的，往往不是最完整的方案，而是可被人随时接管和修正的流程。
四、AI 更像同事，而不是自动化机器
在这些团队里，AI 并没有被当成“全能工具”，而更像一个需要被管理的协作对象。
它可以负责执行、扩展、复盘，但方向、取舍和责任仍然掌握在人手中。 真正有效的模式，往往是人机协作 + 关键节点人工兜底。
当 AI 被完全放任，结果通常不是效率提升，而是失控。
五、全自动“软件黑灯工厂”，现阶段走不通
几位实践者都亲自尝试过高度自动化方案，结论相当一致：
需求理解偏差无法完全避免
架构一致性难以长期维持
交付质量呈现不可预测波动
最终产物往往不是“屎山”，而是难以追溯的黑箱系统。 相比之下，在流程中保留少量人工控制点，反而更稳定，也更符合企业对风险的接受程度。
六、为什么有些团队开始停招初级工程师
在一些已经全面采用 AI 编程工作流的团队中，招聘策略正在发生变化。
原因并不复杂： AI 在执行层面的覆盖面太广，而培养初级工程师的成本又难以在短期内体现回报。
但这种变化也带来了新的问题：传统的成长路径正在被压缩，甚至中断。
如果新人一开始就高度依赖 AI，很多“为什么要这么设计”的思考过程，可能被直接跳过。
七、“一人完成一个方向”，正在成为现实工作状态
另一个越来越常见的现象是： 一个人加一套 AI 工作流，承担过去需要多人协作的完整任务。
这并不意味着工作更轻松，而是责任集中度显著提高。 方向是否正确、判断是否合理，往往直接决定结果好坏。
在这种模式下，真正拉开差距的，不再是技术实现速度，而是对业务和系统整体的理解能力。
八、变化已经发生，只是感知时间不同
围绕 AI 编程，讨论中很容易滑向“未来会怎样”，但对很多团队来说，变化并不是将来时，而是进行时。
角色在变化、能力在重新定价、路径在被重构。 有的人已经站在新工作方式里，有的人还在沿用旧坐标系理解问题。
这些差异，短期内可能并不明显，但在接下来的一两年里，会被不断放大。
