理解是新的瓶颈

软件工作的理解角色

• 许多人认为，理解一直是瓶颈；LLM 只是通过更快地产生更多代码，把这一点暴露并放大了。
• 也有人认为瓶颈正在转移：我们现在把理解“后置”到代码生成之后，而不是在写代码的同时建立理解。
• 还有人反对“X 是新的瓶颈”这种说法，认为从来就没有单一瓶颈；用户价值和好的产品决策仍然是核心约束。

阅读、所有权，以及“不要读代码”

• 不少开发者坚持要阅读并理解所有生产环境提交；他们认为这是不可推卸的责任。
• 也有人承认，对于低风险的 CRUD 工作，他们会直接交付未经审查的“垃圾代码”，并依赖有针对性的测试。
• “不要读代码”这种立场被认为对速度很诱人，但从长远看普遍被视为危险，尤其是在复杂或与安全相关的系统中。

LLM 作为代码生成器：质量与债务

• 常见抱怨包括：冗长、过度设计的 diff；重复逻辑；遗漏显而易见的更简单方案；微妙的算法错误。
• 有人表示，代码库正在退化成难以阅读的“vibe-coded”乱局，只有 LLM 才能安全地接触这些代码。
• 也有人指出，这只是 LLM 之前“能工作但违背模型”的问题的延伸，只是现在速度更快了。

PR、规格与解释

• 自动生成的 PR 描述常被批评为冗长、机械，而且没有说明变更为什么存在。
• 一些团队成功地把描述限制为简短的“是什么 + 为什么”摘要，有时由 LLM 撰写，但需经过人工验证。
• 一个反复出现的主题是：意图应该由人来负责。像 SPEC.md / “spec-driven development” 这样的做法，试图先把理解放进规格中，再让代理去实现。

测试、保障与工具

• 一派认为可以把 LLM 当作承包商：不要过度解读代码，只要构建强大的测试和 QA 即可。
• 另一派强调现有实践体系（单元测试、fuzzing、形式化方法、静态分析），并认为 LLM 也应该帮助这些工作，而不仅仅是生成代码。
• 提议用于帮助理解的工具包括：解释 diff 的工具、带文档的“grill-with-docs”工作流、时间旅行调试，以及把测试覆盖率当作行为地图来使用。

组织与文化动态

• 一些评论描述了这样一种压力：优化吞吐量、token 使用量和可见的 AI 采用，而不是可维护性。
• 人们担心出现“集体精神失常”：工程师和管理者都已脱离投入，批准自己都不理解的 AI 生成 PR。
• 也有人认为新兴的“代理管理”与项目/人员管理类似：分解工作、设定预期，并知道何时该信任，何时该深入细节。