思想领袖
开发人员能否在企业不接受 AI 技术债的情况下拥抱“氛围编码”？
当 OpenAI 联合创始人 Andrej Karpathy 最近提出了“氛围编码”这个术语时，他捕捉到了一个转折点：开发人员越来越多地依靠生成式 AI 来编写代码，而他们自己则专注于高层次的指导和“几乎不需要触摸键盘”。
基础的 LLM 平台 – GitHub Copilot, DeepSeek, OpenAI – 正在重塑软件开发，Cursor最近成为有史以来最快的公司，从 1M 年度收入达到 100M（仅仅一年左右）。但这种速度是有代价的。
技术债务，已经估计每年给企业带来超过 1.5 万亿美元 的运营和安全低效问题，并不是什么新鲜事。但现在，企业面临着一个新兴的、我认为更大的挑战：AI 技术债务——一种由低效、错误和可能不安全的 AI 生成代码所驱动的沉默危机。
人为瓶颈已经从编码转移到代码库审查
2024 年 GitHub 调查发现，几乎所有企业开发人员（97%）都在使用生成式 AI 编码工具，但只有 38% 的美国开发人员表示他们的组织积极鼓励使用 Gen AI。
开发人员喜欢使用 LLM 模型来生成代码以提交更多、更快，企业也在加速创新。然而，手动审查和传统工具无法适应或扩展以优化和验证每天数百万行 AI 生成的代码。
随着这些市场力量的应用，传统的治理和监督可能会崩溃，当它崩溃时，未经验证的代码会渗入企业堆栈。
开发人员“氛围编码”的崛起风险会增加技术债务的数量和成本，除非组织实施了平衡创新速度与技术验证的防护措施。
速度的幻觉：当 AI 超越治理
AI 生成的代码本身并没有缺陷——它只是 未经验证，速度和规模不够。
考虑数据：所有 LLM 都表现出模型损失（幻觉）。最近的一篇研究论文评估了 GitHub Copilot 的代码生成质量，发现 错误率为 20%。问题的复杂性是 AI 输出的庞大数量。一个开发人员可以使用 LLM 在几分钟内生成 10,000 行代码，超过了人类开发人员优化和验证的能力。传统的静态分析器，设计用于人类编写的逻辑，难以处理 AI 输出的概率模式。结果？由于低效算法导致云账单膨胀，未经验证的依赖项带来的合规风险，以及在生产环境中潜伏的关键故障。
我们的社区、公司和关键基础设施都依赖于可扩展、可持续和安全的软件。AI 驱动的技术债务渗入企业可能意味着业务关键风险… 或更糟糕的情况。
在不杀死氛围的情况下重新控制
解决方案不是放弃生成式 AI 编码，而是让开发人员也部署代理 AI 系统作为大规模的代码优化器和验证器。代理模型可以使用诸如进化算法等技术来迭代地改进代码，跨多个 LLM 以优化关键性能指标（例如效率、运行速度、内存使用量），并验证其在不同条件下的性能和可靠性。
三个原则将区分企业在 AI 中茁壮成长和那些将在 AI 驱动的技术债务中溺亡的企业：
- 可扩展验证是不可协商的：企业必须采用能够在规模上验证和优化 AI 生成代码的代理 AI 系统。传统的手动审查和传统工具不足以处理 LLM 生成的代码的数量和复杂性。没有可扩展的验证，低效率、安全漏洞和合规风险将蔓延，侵蚀业务价值。
- 平衡速度与治理：虽然 AI 加速代码生产，但治理框架必须随之发展。组织需要实施防护措施，以确保 AI 生成的代码满足质量、安全性和性能标准，而不会扼杀创新。这种平衡对于防止速度的幻觉变成技术债务的昂贵现实至关重要。
- 只有 AI 才能跟上 AI：AI 生成代码的庞大数量和复杂性需要同样先进的解决方案。企业必须采用能够在规模上连续分析、优化和验证代码的 AI 驱动系统。这些系统确保 AI 驱动开发的速度不会损害质量、安全性或性能，使得创新可以在不积累毁灭性的技术债务的情况下持续进行。
氛围编码：让我们不要过于激动
推迟对“氛围编码”采取行动的企业最终将不得不面对音乐：由于云成本失控而导致的利润率侵蚀，团队在调试脆弱代码时的创新瘫痪，技术债务的增加，以及 AI 引入的安全漏洞的隐藏风险。
开发人员和企业的前进道路需要承认 只有 AI 才能在规模上优化和验证 AI。通过为开发人员提供代理验证工具，他们可以在不让企业面临日益增长的 AI 生成技术债务的情况下拥抱“氛围编码”。正如 Karpathy 所说，AI 生成代码的潜力令人兴奋——甚至令人陶醉。但在企业开发中，必须首先进行由新一代代理 AI 进行的氛围检查。
