为什么优秀开发者会如此警惕 agentic 开发？
经验丰富的程序员正在争论 AI “agentic” 编码工具究竟是在提升还是侵蚀软件质量与开发者技能。许多人赞赏 agent 能大幅加快常规实现和调试，但也警告说，把过多设计和编码工作交给它会破坏对系统的心智模型，鼓励对大规模代码变更进行浅层审查，并让人类退化为低上下文的 QA 角色。另一些人认为，由强工程师谨慎使用 agent，并配合扎实的测试与可观测性，可以形成竞争优势；而能力较弱的团队若过度依赖，则可能导致系统脆弱、理解不足，并长期侵蚀专业能力。
为什么会警惕？
- 许多人认为，这种警惕源于经验，而不是恐惧：当前的 agent 往往能产出“能跑”的代码，但这些代码可能脆弱、不连贯，或者难以推理。
- 有人担心，agentic 开发会削弱造就优秀开发者的过程：练习设计、调试和架构思维。
- 有些人将其类比为外包：短期收益，长期侵蚀本地专业能力。
代码质量、风险与心智模型
- 资深开发者强调，“写出来了”并不等于“可投入生产”：一个微妙的 bug 就可能引发重大事故，而 agent 可能更快地产生这类 bug。
- 手写代码会迫使人澄清需求与权衡；把任务交给 agent，则会让模型悄悄解决歧义并做出架构选择。
- 大量自动生成的 diff（例如 3k 行的 PR）很难真正审查；开发者会失去对系统的深层心智地图，并且在每次变更上都依赖 agent。
信任、责任与依赖
- 有些人说，他们不会信任自己不理解的代码；但也有人指出，我们其实早已在信任不透明的层：编译器、操作系统、庞大的依赖树。
- 反驳是：开源库有社区声誉、历史记录和共同审视；而 AI 生成的片段通常只是一次性产物，没有任何过往记录。
- 围绕“信任网络”存在争论：当大部分代码是 agent 写的，谁来负责？有人认为责任仍然在提交代码的人身上；也有人担心责任会变得分散。
agent 何时以及如何提供帮助
- 普遍共识是，LLM 对以下任务很强：范围明确的小任务、查 bug、升级 API、样板代码、衍生功能，以及快速实验。
- 有些人声称，“最强”的开发者会激进地使用 agent，但仍保持严格控制：他们先指定架构、测试和防护栏，然后验证输出。
- 也有人表示，agent 在不熟悉的领域里比在自己已经很精通的领域里更有用。
采用模式、文化与长期担忧
- 观点分裂：一些人认为反对者是固执或受身份威胁；另一些人则认为全速使用 agent 是鲁莽的“vibe coding”。
- 人们担心形成一种“测试过了就发版”的文化、过度指定的 AI 编写工单，以及管理层推动 agent“更快做事”，而开发者仍要承担后果。
- 长期担忧包括技能退化、训练数据劣化，以及大量低质量“slop”代码泛滥；乐观者则预见，更强的测试/可观测性支架会让实现细节变得不那么关键。