十多年前我还在做实习生的时候，曾经给自己设定过一个挑战，想试一下一天到底能写出多少行代码。当时用的好像是C#，为了这个挑战，我提前做了非常充分的准备。我规划好了要开发的项，买好了午饭，甚至连喝水和上厕所的时间都尽量省下来。
那天结束时，鉴于能力有限，我一共写了993行有效代码。我对这个数字印象极其深刻，因为正好差一点就到1000行。虽然那天累得够呛，但那种充实感直到现在都记忆犹新。在那时候，写代码这种执行层面的工作，是需要靠体力去拼的。
现在进入了AI时代，情况发生了很大的变化。最直观的感受是，随着各种高级工具的涌现，Token不再是稀缺资源了，各种高级模型也变得随手可得。以前在大公司里，因为开发成本极高，大家的时间都很宝贵，所以会演化出各种各样的流程。无论是需求评审还是架构设计评审，这些流程本质上都是为了应对变更，用来保护那些珍贵的执行时间。实际情况是，即便有这么多流程，开发过程中依然会有各种变更。管理者会因此想出更多的办法来保护执行层，流程越加越多。这种做法，在AI Coding普及的今天，早就成了一种束缚。我们在公司经常遇到这样的情况：为了决定要做什么而不断开会，试图在前期就把每一步都想得滴水不漏。结果在沟通和来回折腾上花的时间，已经远远超过了实际写代码的时间，几乎每一次都是这样。
有时候坐在会议室里听大家反复争论方案A和方案B，我心里就在想，其实利用AI Coding的时间，我们已经能把这两个方案的原型都做出来了。与其空谈，不如直接把两个方案都上线跑一下，看看反馈结果，这比开会讨论要直观得多。
当执行层面的瓶颈消失后，以前那种面向执行瓶颈的开发方式就显得有些跟不上时代。我一直在思考，这种变化到底带来了什么。我得出的结论是，AI Coding带来的核心价值并不完全是快，而更多的是多。
这两者听起来很像，但切入点完全不同。如果你有一个经过深思熟虑的好想法，那么快和多是统一的。但如果只是为了追求快，在想法还没磨合好的时候就盲目动工，结果往往是产出一堆质量不高的产物。AI就像一个放大器，它会均等且客观地放大你的想法。如果你输入的是精妙的构思，它能帮你快速得到优质的产出；但如果你输入的是没想清楚的垃圾，它放大出来的也只会是更多的垃圾。
我也曾有过一段迷茫期，在Token变得充裕后，总想方设法把它用完。结果发现，当那些深思熟虑的想法被快速消耗掉后，剩下的就是在左右互搏。为了处理那些低质量、没想清楚的代码，还得回头让AI去不断修改、擦屁股。这样不仅没变快，反而陷入了更高的维护成本中。
现在很多管理者也希望通过AI Coding来提高效率，但在制定KPI时，往往还是习惯性地要求快。比如要求一周时间完成以前一个月的活。这种自上而下的压力，有时会适得其反。如果大家为了完成指标而过度追求速度，导致产出物质量下降，整体效率其实是降低的。
我觉得提高效率的终极目的，应该是为了获得更多好的结果。以前我们做选择很艰难，必须在几个方向中选一个，因为执行力有限。现在我们可以尝试得更多。有人可能会担心代码变多会导致维护困难，但其实在AI时代，写代码快，删代码也快。那些验证后不需要的东西，果断删掉就好了。这不再是一种浪费，而是一种更现代的开发节奏（就比如厨房里的抹布和厨房湿巾，用完了扔掉是一种浪费，还是一种现代的生活方式，就这点破事儿我在家天天和我妈辩论）。
与其去卷Token的消耗量或者盲目追求交付速度，不如把节省下来的时间花在把问题想清楚上。当执行不再是障碍，我们可能需要重新思考，什么样的产出才是有意义的。