最近比较触动我的是 Boris 的那句话："我今年还没写过一行代码。"初听像是炫耀，细想却是一种工作形态的提前剧变。作为 Claude Code 的创始人，Boris 的产出是"一天 150 个 PR"，但他完成这些产出的方式，已经从"亲手写代码"变成了"设计 prompt、设计工作流、设计 agent 行为边界"。这不是某个天才的特例，而是一个信号------工程师的核心技能正在发生迁移。
这种迁移的本质是什么？不是"写代码"这件事消失了，而是"写代码"在价值链条中的位置发生了变化。过去，工程师的价值很大程度上体现在"能把想法变成可运行的代码"；现在，AI 编程工具让这一步的门槛急剧降低。Boris 提到 Claude Code 最初 6 个月几乎不好用------"我可能只用它写了 10% 的代码"。转折来自模型逐步追上产品想象力。这段经历揭示了一个常被忽视的真相：产品有时会先于模型成熟，早期体验糟糕不等于方向错了。那些耐得住"几乎不好用"阶段的人，往往在模型能力跃升时获得先发优势。
面对这种变化，一个关键问题浮现出来：工程师的护城河在哪里？答案或许藏在"不变"与"变"的辩证里。
首先，"为用户创造价值"这条线没有变。 AI 编程工具改变了"工程师做什么"，但没改变"工程师为什么而做"。Boris 反复强调的 YC 信条------
"build something people love"
在 AI 时代依然有效。工具再强大，最终要能让用户"love"它。具体到实践中，这意味着工程师需要花更多时间思考"这个功能对用户意味着什么"、"这个交互流程是否合理"、"这个 AI 能力应该以什么形式呈现给用户"。如果你大部分时间在写代码，那 AI 编程工具对你的冲击是真实的；但如果你花更多时间在思考用户价值，那 AI 工具反而在给你加速。
其次，从"写代码"到"设计流程"，这是技能栈的迁移，而不是技能的消失。 Boris 的一天 150 个 PR，背后是他对 prompt 工程、工具行为边界、人机协作模式的深度设计。这种设计与写代码不同：写代码是"我怎么实现这个功能"，设计流程是"AI 应该怎么实现这个功能，在什么情况下需要我介入，在什么情况下可以放手"。这要求工程师具备一种新能力------把模糊的需求转化为清晰的边界条件。比如 CLAUDE.md 的撰写，核心不是告诉 AI"要做什么"，而是告诉 AI"不要做什么"和"优先级是什么"。这种"反向定义"的能力，正在成为 AI 时代工程师的核心竞争力。
最后，技术底座的快速成熟意味着变化在加速，而不是在减速。 本周另一个值得注意的信号是小米开源 MiMo-V2.5 直接登顶全球开源 Agent 模型榜首。这是国产模型在开源社区的一个里程碑，意味着 2026 年开源模型的竞争正式进入了一个新阶段------不再只是"追赶"，而是开始"领跑"。对工程师来说，这意味着两件事：一是工具会越来越好用，二是工具的更新换代会更快。2026 年的 AI 化不是一个"未来"的话题，而是每天都在发生的事情。你用的工具在变，你写的代码在变，你设计的产品形态也在变。
面对这种持续的变化，或许最值得问自己的问题是：当工具可以帮你完成越来越多的"怎么做"时，你是否清楚"为什么做"和"为谁做"？
工程师的护城河，从来不在"写代码的速度"，而在"定义问题的能力"和"理解人的能力" 。
AI 会越来越快地完成实现，但理解人如何工作、理解用户真正需要什么，这些能力不会被替代。保持对工具变化的敏感度，同时不断回到"为用户创造价值"这个根本问题，或许是穿越这场变化最可靠的方式。