Sonar CTO Andrea Malagodi与Google DORA、METR等研究均显示：AI让写代码变快，但验证负担大增，现有静态分析、测试、人工审查组成的“过滤器栈”正面临数量与安全漏洞双重压力。
AI解读：AI编程工具让写代码的速度大幅提升，但代码验证——确认代码正确、安全、可维护的过程——成为新的瓶颈。Google DORA研究发现，采用AI越多，交付稳定性下降，超过三分之一的开发者对AI生成代码信心不足；METR的对照实验更显示，AI辅助任务耗时反而增加约 19%。原因是：AI生成代码量激增，拉高了审查负担，同时约 45% 的AI生成代码含有已知安全漏洞。对开发团队来说，这意味着不能只关注AI写码效率，必须补强验证环节——在编辑器、CI流水线、生产监控等各层加入更早、更智能的检查，尤其是让AI审查器解释问题而非简单报错。普通开发者暂时无需恐慌，但CTO和技术负责人应评估：是否在AI编码流程中配套了足够的验证步骤，否则『看起来能跑』的代码可能隐藏安全与维护风险。
随着AI编程工具的普及，代码验证——即确保代码正确、安全、可维护并值得投入生产的一系列检查——正成为比写代码更艰巨的任务。ByteByteGo采访了代码验证公司Sonar的CTO Andrea Malagodi，结合Google DORA研究和METR对照实验的数据，讨论了AI生成代码对验证流程的具体影响。
AI让写码提速，但验证负担上升
AI工具能在几秒内写出可用函数、几分钟完成完整功能，团队每月可生成更多机器代码，这导致评审负担大增：以人为单位一千行的速度，AI能生成同样数量的千行代码，而审查仍需人工阅读、理解并判断是否适合投入生产。
Google的DORA研究（一项追踪数千团队如何构建和交付软件的研究）发现，随着团队更多采用AI，交付稳定性下降；对AI生成代码的信任度偏低，超过三分之一的开发者表示对这些工具产出的代码缺乏信心。
研究组织METR的对照实验显示：有经验的开源开发者在自己成熟项目上，任务被随机分配允许或禁止使用AI工具。开发者预期AI能提速约 25%，但结果相反——AI辅助任务耗时约 19% 更多，额外时间主要花在提示、等待、阅读输出和纠正上。部分开发者仍偏好保留AI工具，但整体证据指向AI增加了代码量，也带来了更多后续验证工作。
代码验证的分层结构
代码验证是伞形术语，涵盖确保代码正确、安全、可维护并适合投入生产的所有检查。理解上可类比起草合同：写文字是部分工作，但审查、法律检查和签字才使之成为可信赖文件。验证是一个逐步赢得信任的过程，而非一次性许可。
团队通常采用分层过滤器，每层捕捉特定类型的问题。最上层是成本最低的检查，如类型检查器和linter，在运行前即可发现错误，成本几乎为零。其下是单元测试，能捕获类型检查器无法发现的逻辑错误（如本应加法却用了乘法），通过对比已知答案揭示问题。再下层是人工审查，由另一位开发者判断变更是否适合系统、解决正确问题且可读，捕捉机器可能遗漏的合规性问题。最底层是生产监控，在真实流量下观察代码并标记异常，可捕获所有早期层遗漏的问题。实际过滤栈可能包含更多层，如安全扫描器、依赖检查。
静态分析（如类型检查、linter）在源码上检查而不执行，快速广泛但可能漏掉运行时行为；动态分析（如测试）用真实输入运行并观察结果，依赖路径覆盖，仅运行快乐路径的测试套件无法检测空输入引发的崩溃。
验证工具存在两种错误：误报（标记实际上正常的代码）和漏报（放过真正的缺陷）。高误报率会侵蚀开发者的信任，导致忽略警告，最终重开漏洞之门。Sonar的Andrea将平衡误报与漏报比作CAP定理：速度、准确性和覆盖率三者难以兼得。他建议聚焦于“可操作的发现”，即能指导开发者行动的警告才值得提出。
验证时机与AI带来的两类压力
验证在变更流程中运行的时间点（编辑器、提交后自动检查、审查、合并、部署、监控）决定了错误捕获的成本。同样的问题越晚发现花费越大：编辑器内捕获只需短暂关注，生产环境中的问题则可能导致事故、回滚和用户影响。"左移"（shift left）指将检查提前至问题还便宜时发现，方向对成本有利；特定的倍数公关说辞（如每阶段十倍成本）值得怀疑。
AI给验证带来两类压力。第一是数量：AI快速生成大量代码（原人写的数百行现在AI生成千行），审查负担剧增；AI工具产生的更大变更更难审查，5000 行拉取请求可能导致评审人草率输入“看起来不错”。第二是AI特有的错误类型：对超过百个模型的研究发现，AI生成代码在大约 45% 的情况下引入了已知安全缺陷；模型在生成能干净运行的代码方面进步显著，但安全检查能力基本持平，安全漏洞与功能正确性之间的差距在扩大。另有对数百万代码变更的分析发现重复代码上升，复用下降。
应对这些压力，AI驱动的代码审查（如Sonar通过收购Gitar获得的能力）正获得势头，优势包括快速扫描、广泛捕获缺陷和一致性。该审查也可在agent自身循环中运行，缩短反馈周期，减轻人工评审负担。但风险在于，审查模型与代码生成模型基于相似训练和模式，可能共享同一盲点——AI审查员能确认代码“看起来正常”，但无法判断代码是否真正实现了最初意图。关于是否可减少或移除人工评审，存在争论，合理答案是取决于项目性质与潜在错误成本。
成熟验证工作流与目标
实现成熟验证工作流从提供稳定上下文开始：大多数工程发生在brownfield （既有大型代码库）中，agent自由探索会导致每次结果不一致，Sonar的Andrea称为“一盒巧克力”。解法是预先向agent提供统一的架构、语言编码准则和设计规则。
三个循环负责验证部分：Agentic Loop在沙盒内让agent迭代构建，优化代码并减少token成本、提高质量；CI验证循环对所有代码执行审查、零信任、多层验证及沙盒出口质量门，并高速高量地合并修复；代码维护循环在后台积极解决技术债务，保持代码清洁以方便编码agent工作。
展望 2026 年的成熟架构，Sonar的元素包括：验证引擎（拥有数以千计的规则，覆盖 40 多种编程语言、框架和IaC技术，自动化分析可靠性、可维护性和安全性），AI代码审查（基于自然语言指令而非固定规则，使每个发现对审查者可解释），以及修复agent（针对积压的旧问题处理）。其他公司也趋向于类似理念。
代码清洁度的另一重要增值在于：Sonar团队测量发现，当AI生成的代码（常显得缠绕密集）在半年以上多个开发者会话中演进后，杂乱代码会增加后续AI模型处理的token成本——每次修改时模型都需要更多精力理解它。此外，关于密钥（如API密钥、密码）问题通常源于开发者将含秘密的代码粘贴到AI会话，使秘密随代码一起进入提交或日志文件，被发现的时机太晚。修复之道是在终端（开发者粘贴代码前）运行一个扫描器，尽早阻断秘密泄露。