AI代码量增，但因质量问题导致生产力悖论。LLM训练数据缺陷是主因。“左移”解决之道是清理LLM训练数据，提高AI代码质量，真正提升开发效率。

译自：Beyond 'Shift Left': Improving AI Training Data作者：Manish Kapur

软件开发领域正面临一个新的“工程生产力悖论”。一方面，AI驱动的编码助手正在生成惊人数量的代码。例如，谷歌表示，其30%的代码使用了AI生成的建议。然而，工程速度并没有按比例跃升，生产力增益估计仅为10%。

这种差异突显了一个关键瓶颈：所有AI生成的代码都必须由人工开发人员审查、验证并经常修复。核心问题不在于AI生成代码的数量，而在于其质量。

“垃圾进，垃圾出”几十年来一直是计算机领域的格言。如今，对于基于庞大、未经筛选的公共代码仓库数据集进行训练的大型语言模型（LLMs）的编码来说，这是一个核心挑战。一个令人不快的真相是，这些仓库充满了错误、安全漏洞和“代码异味”，这些都导致了技术债务。当LLM从这些有缺陷的数据中学习时，它也会学会复制这些缺陷。

最近的研究证实了这一点。Sonar 对领先LLM的分析表明，它们都存在共同的盲点，持续生成带有高严重性漏洞的代码，并且有根深蒂固的倾向编写难以维护的代码。

这种问题代码的涌入给人工审查者带来了更大的负担，转移了瓶颈而不是消除了它，从而产生了我们试图解决的生产力悖论。

“左移”的更左移

多年来，业界一直倡导“左移”运动——一种专注于在软件开发生命周期（SDLC）中尽可能早地识别和修复质量及安全问题的实践。我们将测试从最终的生产前阶段转移到CI/CD管道的集成部分，并将静态分析工具直接集成到开发人员的IDE中。目标很简单：及早发现，低成本修复。

但AI辅助的代码生成打破了这种模式。“生命周期”的“开始”不再是开发人员编写第一行代码的时候。生命周期现在始于更早的阶段——LLM内部，以及它所训练的数据。

如果AI工具生成的代码本身就不安全或存在bug，“左移”的战役就已经输了一半。我们实际上是在防守，用我们最好的开发人员作为最后一道防线，来捕获我们“最生产力”的新工具所犯的错误。

这一概念的逻辑上必然的演变是进一步左移。我们必须将重点从仅仅审查AI生成的代码转移到改进其源头。代码质量和安全的新前沿是LLM的训练数据。

策划AI的“教育”

一种新的方法正在出现，以正面解决这个问题。这个概念涉及对用于训练和微调编码模型的庞大数据集进行“清理”（sweep）。

想象一下，使用一个功能强大、大规模的静态分析引擎——一个能够理解数千种bug模式、安全漏洞和可维护性问题的引擎——并将其应用于PB级的训练数据。这个引擎可以在问题代码成为LLM“教育”的一部分之前，识别、修复并过滤掉它们。

这种方法的结果是深远的。在Sonar，我们新服务SonarSweep的早期发现表明，在经过修复的数据上微调的模型生成的代码缺陷显著减少。在一次分析中，这种“清理”过程使得模型生成的代码安全漏洞减少了高达67%，bug减少了42%，所有这些都没有降低输出的功能正确性。

这代表了我们AI辅助开发方法上的一个根本性转变。我们不再仅仅是更快地生成更多代码并造成下游审查瓶颈，而是可以从一开始就训练模型生成更好的代码。

真正的速度不仅仅是原始输出；它关乎以最少的人工摩擦进入生产环境的高质量、安全且可维护的代码的数量。通过确保我们的AI模型从我们最好的示例中学习，而不是最差的示例，我们减轻了审查负担，并让人工开发人员能够专注于他们最擅长的事情：解决复杂问题和构建未来。