Steve Krouse 在一篇关于编程精确性的文章里写了这样一句话：
编程和写作一样，是一种活动——你在做的过程中，会不断磨砺自己正在做的事情。
这和写代码时的真实体验高度吻合。每次实现某个功能的某个细节，都会冒出一连串问题：这里的交互具体该怎么处理？那里的边界条件考虑到了吗？数据结构选对了吗？
这些问题不是凭空出现的，它们是代码给你的。
写代码就是在强迫自己想清楚
编程是一个不断被追问的过程。当你把想法逐步落地成代码时，每一个模糊的地方都会被精确的语法和逻辑强制暴露出来。你以为想清楚了，但写到某一步才发现之前的设计有漏洞——于是你调整、重写、再想。
这种迭代不是繁琐，它本身就是理解的形成方式。一个系统最终的形态，往往是在写代码的过程中逐渐”涌现”出来的，而不是在动手之前就全部想好了。
Jim Nielsen 的判断是：写代码是一个工具，这个工具帮你发现并形成你的程序的正确性。
如果你跳过写的过程，直接让 AI 生成一个完整方案，那些细节的问题不是消失了，而是被掩盖了。等到用户碰到那些意外行为时，才会替你把你自己都没意识到的模糊暴露出来——那就是 bug。
挖金矿的比喻
原文用了一个很有意思的金矿类比。
以前挖金矿靠镐头和铲子，一点一点地挖，遇到金块就完整取出来。后来有了炸药，把整个山头炸掉，碎石和金粉混在一起，过滤之后得到的是金粉。
炸药快，产量也不一定差。但如果山里有完整的大金块，炸药也不会让你找到它——你连有没有大金块都不知道，因为炸之前什么都没碰到，炸完之后什么也看不清了。
不是只有工具帮了你，工具背后的过程也在帮你。镐头和铲子会产生一种过程，炸药会产生另一种过程。
代码生成也是一样。它是一种工具，但有自己对应的过程。这个过程帮了你什么，又让你失去了什么，值得认真想清楚。
AI 生成代码为什么感觉”快”
快，是因为跳过了慢的部分。而那个慢的部分，正是磨砺思维的部分。
当你让 AI 直接生成代码，你绕过了那些被追问、被逼着想清楚的时刻。代码是来了，但那些本应在写代码过程中被发现的问题——系统边界在哪、数据流是否合理、某个假设是否成立——都没有被真正触碰过。
这不是说 AI 代码生成没有用。对于样板代码、已知模式、简单工具脚本，它确实能节省时间。但对于你真正需要深度理解的系统，如果完全依赖生成，你就是在用炸药挖金块。
你做了权衡，只是你自己没有意识到。