刚听了 Martin Fowler 和 Kent Beck 的一场对谈。两位都是软件工程领域非常有分量的人物，但这场讨论里最有价值的，不是他们讲了多少新概念，而是他们在 AI 这波变化里，重新确认了哪些东西依然重要，哪些东西正在失去中心位置。
整场听下来，最大的感受是，AI 确实在改写软件开发，但它改写的未必只是怎么写代码，更是在重排开发者能力的优先级。
视频：https://www.youtube.com/watch?v=CZs8J1ZD0CE 原文：@hongming731
1. AI 不是一次普通的工具升级，而是更大一级的变化
Martin Fowler 提到，过去几十年他们经历过很多技术浪潮，比如面向对象、互联网、敏捷开发，但 AI 带来的冲击，无论是规模还是速度，都明显更大。
过去那些技术迁移的经验只能提供参考，不能直接照搬。很多人今天还在把 AI 看成更强一点的 IDE、更聪明一点的搜索、或者更自动化一点的脚手架工具。这样理解并不全错，但容易低估它对工作方式的影响。
这次变化真正特别的地方在于，AI 不只是替你做一小段具体工作，它正在进入分析、实现、验证、重构、沟通这些原本分散在不同阶段的环节。它不是简单地替代某一个动作，而是在逐步改造整个开发流程。
所以，问题已经不是要不要用，而是你准备怎么和它一起工作。
2. 现在最重要的，不是找到标准答案，而是学会探索
Kent Beck 讲得很直接：过去很多工程问题，其实是有相对成熟的方法和答案的。遇到 Bug 多，就加强测试；代码难维护，就改善设计；流程混乱，就引入更好的协作方式。
但在 AI 时代，现成答案少了很多。哪种模型更适合，什么场景下值得信任，任务怎么切，审查怎么做，边界怎么设，很多都还在变化中。
探索不再只是过渡阶段，而正在成为一种长期能力。 不是等别人整理出完整方法论后再开始，而是边做边学，边试边调。
3. 最值钱的能力之一，是做最小可验证实验
Kent Beck 提了一个很关键的问题：如果你想验证一个说法是否成立，能做的最小实验是什么？
这几乎可以算是 AI 时代开发者最实用的思维方式之一。围绕 AI 的信息太多、声音太杂，面对各种说法，最没价值的两种反应就是全信和全否。真正有用的是，把它们变成可以验证的小实验。
比如，不要笼统地问「Claude Code 好不好」，而是拿自己真实的一个任务去试：它在老代码重构上表现怎样，补测试是否可靠，跨文件修改是否容易失控。
同样，不要争论「AI 写代码可不可信」，而是把问题拆开：在什么任务上可信，可信到什么程度，需要什么保护措施，失败模式主要是什么。
4. 好的工程实践没有过时，反而更重要了
模块化、测试、重构、清晰命名、领域建模这些经典工程实践，并没有因为 AI 出现而过时，反而变得更重要。
原因很现实：AI 的确能生成代码，但它对上下文质量极度敏感。代码边界清不清楚，命名是否一致，测试是否完善，模块职责是否明确，这些都会直接影响 AI 的输出质量。
一个结构清晰、测试扎实的系统，对人类更友好，对 AI 也更友好。一个混乱、耦合严重、缺乏约束的系统，人写起来痛苦，AI 介入之后通常只会更快地制造新问题。
AI 不是让工程约束失效了，而是让工程约束的重要性变得更显性。
5. 代码的形态会变，但精确表达意图的能力不会消失
Martin Fowler 在对谈里提到，当有人说「以后没人需要写代码了」，他首先会问，对方说的代码到底是什么。
如果把代码理解成手工编写某种语言的文本，那它的占比很可能会下降。但如果把代码理解成对系统行为的精确表达，那它并没有消失，只是在变化。 未来你写的东西，可能更多体现在 spec、prompt、测试、约束、工作流、接口定义和领域语言里。
开发者不一定还像过去那样花大量时间逐行构造实现，但依然要负责把意图表达清楚，把边界定义清楚，把结果校验清楚。从这个角度看，开发者并没有退场，只是工作的重心在迁移。
6. 未来的分化，不在于用不用 AI，而在于会不会形成自己的工作流
很多人讨论 AI 时关注点还停留在工具层——哪个模型更强，哪个助手更好，哪个插件更快。这些当然重要，但真正拉开差距的，是有没有形成一套稳定有效的工作流：
- 你会不会先整理任务上下文，再交给 AI
- 你会不会把需求、约束、接口、测试拆开处理
- 你会不会区分哪些任务适合 AI 快速推进，哪些任务必须自己主导
- 你会不会在输出后做结构化审查，而不是凭感觉看看"差不多能跑"
未来大多数开发者都会用 AI，正如今天大多数开发者都会用 IDE、版本控制、自动化测试一样。真正的差别，不会是使用者和非使用者，而会是有方法的人和没有方法的人。
7. AI 会放大个体能力，但不会自动替代人与人的协作
Kent Beck 讲了一个特别值得警惕的趋势：有人觉得自己带着多个智能体工作，就像在管理一个团队。但这和真实的人类协作根本不是一回事。
AI 很容易让人产生一种错觉：只要单个开发者的执行能力足够强，团队沟通的重要性就会下降。但软件开发里很多最难的部分，从来都不是写出一段代码，而是：我们到底要解决什么问题，边界怎么划，取舍怎么做，风险谁来承担，系统如何长期演化。
AI 越强，团队越需要在更高层面上达成共识。否则就会出现一种情况：每个人都在高效地产出，但整个系统在朝不同方向分裂。
8. 开发者真正该提升的，是对系统和业务的理解力
Kent Beck 最打动人的是他说自己过去非常享受打磨局部代码的过程，那种一点一点重构、逐步澄清结构的体验，本身就是一种乐趣。但在 AI 时代，这种对局部实现的专注，杠杆在下降。
更有价值的能力，正在转向对整体系统的理解，对业务问题的抽象，对领域语言的建立，以及对软件如何支撑现实世界流程的把握。
开发者未来最需要守住的，不一定是亲手写每一行代码，而是对系统正确性和业务结果负责。 过去很多工程师的成就感来自控制实现细节，未来更大的成就感，可能来自你能否看清全局，组织清楚上下文，让人和 AI 都在正确的方向上高效协作。
总结
AI 正在降低「写代码」这件事本身的门槛，但它同时也在抬高「做工程」这件事的门槛。
代码生成会越来越便宜，判断、建模、验证、取舍和协作会越来越贵。局部实现的价值会下降，系统理解的价值会上升。会不会写，依然重要，但已经不是最核心的问题。更核心的是，你能不能把问题说清楚，把上下文组织好，把结果验证稳。