¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
2 274
Suscriptores
+124 horas
+77 días
+1330 días
Archivo de publicaciones
2 274
Repost from ᴊᴜsᴛ ᴀ ᴘᴇᴇᴋ
写代码从来不是瓶颈｜Pedro Tavares
多年来，我一直认为软件开发的瓶颈根本不在于写代码本身。
真正的瓶颈从来都是代码审查、通过指导与结对编程传递知识、测试、调试，还有人与人之间沟通协调所产生的“人类开销”。所有这些都被嵌套在纷繁复杂的任务票据、计划会议和敏捷开发流程之中。
这些旨在提升质量的流程，往往比实际写代码的速度慢得多，因为它们需要思考、共同理解，以及理性判断。
现在，大语言模型（LLM）的兴起使得生成可运行的代码变得前所未有的简单快捷，一种新的论调便随之出现：过去写代码才是瓶颈，现在我们终于打破了它。
但事实并非如此。
尽管借助LLM，新增代码的边际成本正在无限趋近于零，但理解、测试、信任这些代码的成本却比以往更高了。
LLM只是转移了工作，而非移除了工作
像Claude这样的工具能加快初步的代码实现，但结果通常是产生更多代码，进而给审查、集成和维护代码的人带来更大的压力。
这种现象尤其明显，当：
* 提交代码的人可能自己都没完全理解代码的逻辑。
* 生成的代码引入了团队不熟悉的模式或违反了已有的惯例。
* 一些边缘情况或潜在的副作用并不明显。
于是，我们陷入了这样一种状况：代码生产变得容易了，但验证代码却更加复杂，这并不会真正提高团队整体的速度。
这其实并不新鲜。开发者早就自嘲自己进行的是“复制粘贴工程”，而LLM所带来的速度和规模则进一步放大了这种复制粘贴的现象。
理解代码才是真正的困难所在
> “代码最大的成本是理解，而不是写出来。”
LLM确实减少了产生代码所需的时间，但它们并未降低理解代码行为、发现细微的Bug或确保长期可维护性的努力。甚至，在面对由LLM生成的代码时，这些任务可能变得更难，因为审查者要区分生成代码与手写代码之间的差异，以及弄清为何要选择某个特定的方案。
团队仍然依赖信任和共同背景
软件开发本来就是一个协作过程，它依赖于共同的理解、目标一致和互相指导。然而，当代码的生成速度远超沟通和审查的速度时，团队可能会陷入一种“默认质量”而非“确保质量”的模式。这无形中给审查者和指导者带来巨大压力，可能进一步以微妙的方式拖慢团队的整体节奏。
LLM很强大，但并未解决根本问题
LLM在快速原型开发、脚手架搭建和自动化方面确实带来了真正的价值。然而，它们无法消除清晰思考、谨慎审查以及周密设计的必要性。相反，随着生成代码越来越多，这些基础工作变得更为关键。
是的，写代码的成本确实降低了。但团队一起理解代码的成本并没有降低。
这才是真正的瓶颈。我们不应假装它不存在。
原文：Writing Code Was Never The Bottleneck
2 274
感觉这就是一种异化，虽然这些离职案例具有这些特点，但如果将其总结为过滤用的 tag 那反而就不对了；不知道这人有没有调研过在转正员工或者目前仍在 OD 任职的员工里具有这些 tag 的人数比例如何。。
