我担心我们的 Copilot 落下了一些乘客
GitHub Copilot 和类似的 AI 编码助手，一些有经验的工程师把它们视为强大的自动补全工具，但另一些人则批评它们会鼓励产生臃肿、缺乏可访问性或细微错误的代码，最后还得由队友来收拾。评论者担心，过度依赖 LLM 生成的代码，尤其是经验较少的开发者以及在安全性和可访问性等领域，会加速软件质量长期下滑，并加深“enshittification”的压力。许多人认为，这些工具最好在强测试、审查和明确规范下使用：把它们当作初级协作者或翻译器，而不是理解、设计和长期可维护性的替代品。
团队规范与代码生成工具的误用
- 有几位描述了同事把大量由 LLM 生成的改动直接粘贴进来，里面夹杂着无关代码，自己却解释不清，还指望队友帮忙调试和修样式。
- 许多人认为，这应当像处理任何其他糟糕工程实践一样：拒绝 PR，要求解释，要求符合代码库的规范；也有人认为，习惯性地把思考外包出去，足以成为解雇理由。
- 有人担心，“LLM 开发者”把工作量从作者转移到了审查者身上，这被视为不尊重。
Copilot 在哪里有用，哪里有害
- 大家认为它最有用的场景包括：样板代码、重复性结构、不同格式之间的转换（例如 JSON → types）、快速查文档、测试脚手架，以及“橡皮鸭”式调试。
- 有些人默认关闭它，只在自己非常清楚想要什么时才启用。
- 也有人说它变差了或表现不稳定，经常在上下文很少甚至没有解法的情况下给出猜测。
- 有效的使用方式：把它当作强大的自动补全，像和一个非常初级的开发者搭档一样使用，只接受你本来就打算接受的内容。
代码质量、可访问性与安全性
- 许多人同意，Copilot 反映了公开代码里（往往不佳的）质量：一团 div 的 HTML、薄弱的可访问性、糟糕的 Bash 等。
- 担心 LLM 生成的代码会让不良实践常态化（可访问性、安全性、国际化），这些代码“看起来能用”，于是就会在无人察觉时被发布。
- 也有人认为，这些问题可以通过更好的训练数据，以及把 lint、可访问性检查器和测试集成到生成循环中来缓解。
学习、招聘与过度依赖
- 这个工具被认为对专家有提升作用（他们能识别错误），但对新手是个陷阱（新手做不到）。
- 有人担心初级开发者会把思考外包出去，学到错误模式，永远无法打好基础。
- 招聘方面：面试官发现候选人在远程测试中偷偷使用 AI；应对措施包括全屏共享、只做伪代码任务，或把重点放在推理而不是死记硬编码上。
更广泛的行业与未来方向
- 有几位把 LLM 与“enshittification”联系起来：它们可能会加速已经存在的糟糕激励（快点上线、永远不清理、接受平庸的 UX/性能）。
- 也有人认为，烂应用是市场驱动的，不是工具造成的；LLM 甚至可能帮助小团队在竞争中胜过根深蒂固的糟糕系统。
- 也有人设想更丰富的工作流：面向组织的专用模型、由编译器/语法约束的生成、重构建议，以及通过测试和 lint 验证的多轮生成。