作者：SuSun

地址：https://zhuanlan.zhihu.com/p/2003858916971398866

经授权发布，如需转载请联系原作者

我是一个vibe coding的“老手”了，早在24年末我就基本不再手写代码，大抵是一年零几个月的时间，我所产出的所有代码，基本都出自各种不同时期的LLM。随着最近LLM + Coding agent能力大幅提升，我本以为我可以做更多，我可以offload更多事情给它们。但事与愿违，似乎整体效率不如LLM还没进化的去年效率来得高。

有想法，设计，讨论（从这里开始Coding agent开始介入），决定如何实现，实现，E2E 验证，算是一个feat的完成。整个链路非常高效和谐，我也借助这套范式vibe了很多东西。但天下没有免费的午餐，也没有不存在任何bug的系统。当bug来袭，我也依赖coding agent去debug，这花费我完成feat数倍时间的去看，往往bug就来自于一些实现阶段的细节问题。

在LLM能力没有进化之前，我其实是要花不少时间在控制实现复杂度上，因为当时LLM还没有那么强的能力，我必须人工拆解任务，我在脑海中还是会有对应代码雏形的。随着LLM能力提升，在实现阶段的更加高效，我脑海中只有一些自然语言的决策，不再去细想，细看一些具体代码，把时间花在系统更上层的决策上。

就比如说，我设计的SSD Cache，整体基于fifo的ring buffer，读是乐观读，有tail,head维护整体状态。LLM信誓旦旦理解了我的想法，在E2E和一些单测上也都能通过。后来一个棘手问题是，SSD的p99异常高，我让很多coding agent去找这个问题，无论是5.2 xhigh, opus 4.5, kimi 2.5，都无一例外，给我了一些没用的答案。也是在某个午休，我突然想起来一个问题，它是怎么处理FIFO淘汰的，这才知道，它给我写了一个O(n)的淘汰，淘汰时会扫描全部SSD index。仔细细看，整体代码结构也比较糟糕，把事情想的，处理的过于复杂了。

诸如此类的问题还有一些，总在给LLM处理后事的我，必须思考解决此类问题。

我脑海里几句来自《解构领域驱动设计》的书摘提醒了我

计算机编程的本质就是控制复杂度。影响理解能力的第一要素是规模

作为人，人性本懒，我们在复杂和简单两个天平中，会更倾向于简单。但常言到”One size could not fit all”，系统的复杂度是尤其必要性的，想要更好的性能，就需要做更多“定制化”，抽象开始泄漏， 复杂度开始增加。代码也好似有损压损的产物，压缩了各种需求和场景，这世界上应该没有小于O(n)的压缩算法，必须看完所有信息，我们才能知道如何压缩。想要在有限的空间里，实现更高的压缩率，则需要更多的计算，就像bloom filter到binary fuse filter，就像各个压缩软件的压缩等级选项。

所以我们想要更少的代码，更简单的设计，我们必须投入更多的时间去消化，理解，设计系统本身。可惜人类的能力是有限的，这世界上本就不存在什么天才，人类在不断在自己定义的Loss function上做RL，我们必须花时间尝试，成功，失败，从中学习，记录到我们的参数中，人类没有影分身，无法并行，我们只能在有限的生命中，花费珍贵的时间在不断地尝试中去“训练”自己，在自己的Loss function上梯度下降。即使我派出AGENT 集群，去给我撰写一本《RDMA工程开发大全》，我也需要花费巨量的时间精力，在实践中，在脑海里，或在笔记软件上写下这样的思考。我必须去思考，去尝试。

人脑这个推理引擎，无论是prefill亦或decode吞吐，都是有限的。decode吞吐大抵和语速和信息强度相关，prefill吞吐则在于理解新事物的速度上，我觉得人本身并不是full attention的。但总之，如果coding agent产生复杂度的速率快过我消耗的速率，就会出现排队效应，队列会越来越长，需要drain这个队列的时候，我必须消耗完整个队列堆积的复杂度，或者说接管LLM给项目带来的”技术债“。

说一千道一万，我觉得我现在处于一个时间点，LLM的能力提升不再能显著提升我的效率，到了 Amdahl’s Law的极限，剩下的串行阶段都是因为我做一个人类，无法并行的部分。我必须吞下复杂度，接受复杂度，控制住整个项目复杂度增加速率不超过我能处理的极限。

也许是时候，开始手写一些代码了。