AI代码助手让工程师能飞速生成可运行的代码，但作者Vinícius Brasil发现，真正瓶颈已经转移到审查环节——他越来越频繁地拒绝AI生成的代码，即使它们能通过测试。这种拒绝不是出于技术错误，而是出自一种更深层的责任：代码必须能被理解、解释和长期维护。
认知负担转移
在AI编码代理普及之前，工程师接到任务后会花数天探索代码库、思考多种方案、做实验，再动手实现。当最终提交PR时，对方案有足够把握，也能向同事清晰解释每个改动。但AI改变了这个节奏。即使遵循最佳实践——先制定计划、分阶段、小步提交——作者在审查AI生成的代码时仍感到认知过载：这些代码不是自己亲手推敲出来的，面对一段看似正确但无法在脑中重演推导过程的东西，心里没底。
实际后果是，完成大任务依然要数天，而且作者经常在第一次session后直接拒绝AI的全部改动，重新从零开始。不是因为AI模型变差了，而是因为第二次时他自己有更充裕的时间消化问题，能主动引导代理走向更好的方案，而不是被代理带着走。
什么时候必须拒绝
作者总结了拒绝AI代码的几个具体阈值： - 当自己无法用语言复述方案的逻辑时，说明理解缺失； - 当diff改动的幅度远大于原本要解决的问题时，说明引入了不必要的复杂度； - 当代码过早引入抽象（比如为了复用而设计接口，但当前需求根本没证明需要抽象时）； - 当代码在本地能跑但让整个系统更难推理时，比如增加了隐式依赖或跳转； - 当自己信任输出超过了自己的理解时——这是最危险的信号。
这些标准的共同点：把对代码质量的判断标准从“CI是否通过”拉回到“人是否真的掌握它”。作者观察到，工程师经常过于快速地接受AI生成的改动，而“能运行且通过CI”的代码完全可能是一个糟糕的解决方案。工程的核心从来不是写出能跑的代码，而是实现恰当、可扩展、可维护的解。
这对团队实践的启示是：AI审查不能代替人工审查，反而需要更强的人工审查流程。即便编码代理越来越强大，它们仍然需要优秀的工程师在背后做方向判断和设计取舍。目前阶段，它们还无法可持续地自主完成复杂工程任务。
编注：信源为Hacker News上作者的个人博客，材料基于个人经验，未涉及行业统计或第三方案例，读者宜注意其主观性。