QCon伦敦2026：AI写代码速度暴增3倍|qcon|代码|伦敦|电子表格|速度

开发速度终于来了，但整个行业却不知道该怎么用它。这是Hannah Foxwell在QCon伦敦2026开场时抛出的悖论。她没聊技术细节，而是直接切向一个更扎心的问题：当AI代理（AI Agent，能自主完成任务的智能体）开始写代码，人类还剩什么？

从半年发版到秒级交付，速度革命来了第三波

Foxwell的履历本身就是一部软件交付的压缩史。早期在大型机团队，一年两次发版是常态；后来进入持续交付（Continuous Delivery，持续交付）时代，规模化部署成为标配。她把AI代理编码称为"又一次阶跃变化"，但强调这次不同——它制造的是全新的组织压力，而非简单延续旧逻辑。

她援引了Steve Yegge的八阶段开发者进化模型。这个模型从"初级工程师"一路铺到"技术领袖"，描绘的是能力维度的成长路径。但Foxwell的潜台词很明显：当机器能覆盖模型中下游的大量环节，人类的位置需要重新校准。

她的核心判断是：AI代理已经来了，与其争论"会不会来"，不如直面"怎么适应"。

现场听众的构成很有意思——大量工程管理者、架构师，还有少数CTO。这群人过去十年主导了DevOps转型、云原生迁移，现在却被同一个问题困住：如果代码产出速度提升10倍，现有的团队结构、评审流程、绩效考核，哪些会瞬间失效？

Foxwell的演讲标题挂着AI，内容却刻意绕开技术实现。她解释得很直接：代理的能力边界每天都在变，任何具体的技术讨论三个月后就过时。但组织层面的冲击是结构性的，值得提前布局。

她抛出了一个让现场安静的类比：持续交付刚普及时，很多团队只是把"半年发版"改成"每月发版"，代码质量反而崩了。真正的转型需要测试自动化、监控体系、文化重塑——AI代理编码同理，速度本身不是答案，配套机制才是。

具体有哪些机制？Foxwell没给清单，但反复提到两个关键词：团队适应性（team adaptability）和决策权再分配。当AI能生成候选方案，人类的核心价值从"写代码"滑向"判断代码"——这个滑动幅度，比她经历过的任何一次技术变革都大。

她提醒在场者警惕一种幻觉：以为AI代理只是"更快的自动补全"。自动补全是工具层面的增强，代理是工作流层面的重构。前者改变个人效率，后者动摇团队协作的底层假设。

Steve Yegge的模型在业界流传多年，把开发者成长分为八个阶梯：从能独立修bug，到能设计系统，再到能影响组织技术方向。Foxwell没否定这个框架，但暗示它的适用场景正在收缩。

模型中段的大量技能——写模块、调接口、做集成——恰恰是当前AI代理最擅长的领域。这不是说中级工程师会消失，而是他们的产出形态会变：从"亲手实现"转向"验收AI产出、调试边界案例、定义验收标准"。

Foxwell自己创办了两家AI相关公司：AI for the Rest of Us和BIMP.ai。她的商业视角让演讲多了层务实色彩。她观察到，客户公司里最焦虑的不是初级开发者，而是技术中层——那些刚爬到"能带小团队"位置的人，突然发现带队方式要推倒重来。

一个细节让她印象深刻：某客户的技术负责人要求团队"每天提交50个AI生成的PR"，两周后代码库陷入混乱。速度指标本身成了陷阱，因为没人定义"什么样的AI产出值得合并"。

演讲收尾时，Foxwell没给行动指南，而是抛回给听众一个问题：当机器能比你更快写出"能跑的代码"，你凭什么 claim 自己的不可替代性？

她列了几个可能的答案，但都不满意。说"我能审核AI代码"，审核标准谁定？说"我能设计系统架构"，架构决策的输入 increasingly 来自AI的候选方案。说"我能理解业务"，业务方迟早会直接对话AI代理。

她唯一相对确定的，是一个否定性判断：单纯追逐速度的团队会栽跟头。持续交付时代的教训是，发版频率提升后，回滚能力、监控密度、团队心理安全感必须同步升级。AI代理编码的速度红利，同样需要配套的"减速机制"——更严格的验收标准、更频繁的人工抽检、更清晰的权责边界。

现场有人问：这对招聘有什么影响？Foxwell的回应很产品经理式：她还在观察，但注意到一个趋势——"能清晰定义问题"的候选人在涨价，"能快速写代码"的溢价在收缩。问题定义能力，可能是人类对AI代理的少数护城河之一。

演讲结束后，Twitter上的技术讨论分裂成两派。一派转发她的速度悖论，认为组织变革滞后是最大风险；另一派质疑她"不谈技术"的立场，觉得回避代理能力边界是避重就轻。Foxwell没参与争论，她的下一站在柏林，另一个技术大会，同一个主题。