Martin Fowler 和 Kent Beck 这两位在软件工程领域有足够分量的人，坐下来聊 AI 对开发者的影响。对谈里最有价值的不是新概念，而是他们在变化里重新确认了什么依然重要，什么正在失去中心位置。

八个核心提醒

第一：AI 带来的冲击规模和速度都明显更大。过去他们经历过面向对象、互联网、敏捷开发这些技术浪潮，但 AI 的影响无论规模还是速度都明显更突出。过去技术迁移的经验只能提供参考，不能直接照搬。

把 AI 理解成"更强一点的 IDE"或者"更自动化一点的脚手架工具"，并不全错，但容易低估它对工作方式的影响。

第二：AI 在重排整个开发流程。它不是简单替代某一个动作，而是在逐步进入分析、实现、验证、重构、沟通这些原本分散在不同阶段的环节。问题已经不是要不要用，而是你准备怎么和它一起工作。

第三：探索正在成为长期能力。Kent Beck 说得很直接：过去很多工程问题有相对成熟的方法和答案，AI 时代现成答案少了很多。怎么切任务、怎么审查、边界怎么设，很多都还在变化中。不再是等别人整理出完整方法论再开始，而是边做边学。

第四：最小实验思维。Kent Beck 提了一个很实用的问题：如果你想验证一个说法是否成立，能做的最小实验是什么？

不要笼统地问"Claude Code 好不好"，而是拿真实任务去试：老代码重构表现怎样、补测试是否可靠、跨文件修改是否容易失控、给不给完整上下文差别有多大。把大问题拆成可验证的小实验。

第五：经典工程实践没有过时，反而更重要。模块化、测试、重构、清晰命名、领域建模——这些经典实践在 AI 时代没有失效，只是被放到了更显眼的位置。

原因很现实：AI 对上下文质量极度敏感。代码边界清不清楚、命名是否一致、测试是否完善、模块职责是否明确，这些直接决定 AI 的输出质量。结构清晰、测试扎实的系统，对人类和 AI 都更友好。混乱耦合的系统，人写起来痛苦，AI 介入只会更快地制造新问题。

第六：AI 不是让工程约束失效，而是让工程约束的重要性变得更显性。以前团队工程做得差很多时候还能靠熟悉系统的人硬撑，现在如果要把 AI 真正接入日常开发，那些过去被忽略的问题会更早暴露出来。

第七："代码"这个词的含义在变化。Martin Fowler 问得很准：如果把代码理解成手工编写某种语言的文本，那它的占比很可能会下降。如果把代码理解成对系统行为的精确表达，那它没有消失，只是在变化。未来写的东西可能更多体现在 spec、prompt、测试、约束、工作流、接口定义和领域语言里。

第八：人类判断力的价值上升。在 AI 可以接手大部分执行工作之后，知道做什么、验证结果、判断质量——这些人类独有的能力反而变得更值钱。