多位开发者在讨论中指出AI编码存在代码重复、上下文丢失、缺乏全局视角等问题，建议将AI作为辅助工具而非替代者，采用规格驱动开发策略。

一位开发者在Hacker News上发帖倾诉，称使用AI编写代码是一场噩梦。AI过度聚焦当前任务，对更改是否破坏系统其他部分漠不关心，长上下文等同于即时脑损伤。这一帖子引发了数十条讨论。

多位开发者对此表示认同。有人指出，AI最令人痛苦的习惯是只添加代码而非修改或删除现有代码，导致文件中充斥着addData、addDataNew、addDataForAddData这样的重复函数。AI生成的代码往往缺乏对现有系统的理解，无法复用正确的抽象，也无力承担变更后的完整调用链。

一位开发者将AI比作过度防御性编程的典型，经常添加不必要的tryexcept块来掩盖本应暴露的错误。还有开发者描述了AI编码的生产力悖论：启动一个任务后等待3到5分钟，再启动下一个再等待，这种循环不足以让人真正投入工作，却打断了深度思考的流程。

针对这些问题，社区总结出多种应对策略。首先是计划先行：让AI扫描项目并创建实现计划的markdown文件，在新会话中让AI按照计划执行，而非一次性要求它解决问题。其次是规则约束：在AGENTS.md文件中定义架构不可妥协的规则，要求AI在标记任务完成前必须运行测试。第三是上下文管理：使用具有100万token上下文窗口的模型，或将会话拆分为规划和实现两个阶段，将扫描阶段的上下文压缩到单个文件中。

有开发者引用了Anthropic的一项研究，该研究将开发者分为辅导加手写代码组和AI最大化组，发现前者在速度和系统理解方面表现更好，且成本更低。不过也有人指出，该研究的对象是初级开发者，样本量较小，最有成效的AI使用方式可能是资深开发者利用AI加速工作流，同时仔细审查输出。

一位开发者总结道，LLM的好坏取决于训练数据中代码库的平均质量。如果将AI当作放手不管的开发者，从流程中移除人类，得到的就是代码泛滥。但没有人强迫我们这样使用它，速度的减慢恰恰是将人类专业知识和判断力融入其中的必要代价。当LLM准备好让人类退出循环时，我们会知道，因为那时我们都会失业。在此之前，我们的角色是充当质量瓶颈，而不是打开闸门。

原文：https://news.ycombinator.com/item?id=48770319