Vibe Coding：AI对企业的隐形“影子IT”威胁
Vibe coding，这个在科技界日益流行的热词，描述了通过与人工智能代理进行对话式提示来生成软件的过程。其倡导者安德烈·卡帕西（Andrej Karpathy）曾形象地描述这种方法为“这并不是真正的编码——我只是看到一些东西，说一些东西，运行一些东西，然后复制粘贴一些东西，它大多时候都能奏效”，并认为它适用于“一次性的周末项目”。Vibe coding与其他AI辅助方法的关键区别在于，它对AI代理生成的代码采取了不加批判的接受态度。这使得“公民开发者”（那些没有接受过正规编程训练的人）无需理解底层代码或其工作原理，即可创建小型应用程序。
这一愿景与一个长期存在的抱负不谋而合：使用简单的英语作为编程语言来定义软件。虽然通过软件解决一些小挑战可能会令人满意，类似于一次成功的家庭维修，但其在企业环境中的应用，却与传统的软件开发截然不同，反而与被称为“影子IT”（shadow IT）的问题现象有着惊人的相似之处。
影子IT的出现，是当业务部门对官方IT项目的缓慢进度感到沮丧时，选择自行解决问题。在管理日益增长的工作量的压力下，他们常常求助于“业务英雄”，这些人利用电子表格或数据库等现成工具拼凑出临时解决方案，并且经常绕过官方采购流程。尽管这些临时性的解决方案提供了局部、暂时的缓解，但它们很少能提供可持续的长期答案。更多时候，它们的“成功”在于迫使原始项目紧急重新排优先级，这通常发生在影子IT解决方案不可避免地失败之后。
真正的软件开发远不止是创建功能；它需要对非功能性需求进行严格考量。这些包括可扩展性、法律和法规义务、安全性、用户体验、可访问性以及灾难恢复等关键方面。Vibe coding，就像影子IT一样，很大程度上规避了这些关键问题，因为公民开发者不太可能意识到它们，更不用说提示AI去解决它们了。当这些系统不可避免地出现故障时，最初倡导影子IT项目的“业务英雄”往往会变成“罪人”，陷入无休止的修复循环中，因为他们努力保持系统运行。Vibe coding诞生的应用程序也将面临同样的命运。
软件开发中一个普遍存在的误解是，人们认为有人能精确地知道软件需要做什么，只需要一个程序员去实现它。正如弗雷德·布鲁克斯（Fred Brooks）在其1987年的里程碑式论文《没有银弹》（“No Silver Bullet”）中所阐明的：“软件任务最困难的部分是获得一个完整且一致的规范，而构建程序的大部分本质实际上是对规范的调试。”
对于企业组织而言，vibe coding引入了四个关键的风险领域，通常用四个“S”词来概括：Specification（规范）、Scaling（扩展）、Software Design（软件设计）和Security/Compliance（安全/合规）。它们加在一起，听起来就像一个正在缓慢漏气的比喻性轮胎。
首先，规范（Specification）：数十年的经验告诉我们，预先精确定义软件系统的需求是极其困难的。我们通常能掌握主要用例，但在开发过程中会发现大量意想不到的场景。成功的软件创建通常涉及深入理解用户需求，或通过迭代交付小而快速的更改来试验以求成功。最好的团队会结合这两种方法。Vibe coding，就其性质而言，会加剧规范的弱点，导致功能性和非功能性需求的遗漏。当这些问题在后期被发现时，随后的更改可能会无意中破坏之前正常工作的功能，从而有效地将软件交付退回到“边写边改”（code-and-fix）的临时时代。此外，解释系统如何工作通常至关重要，特别是对于涉及自动化决策的法规遵从性。对于vibe-coded软件，唯一的“文档”可能就是最初的对话提示，而这些提示可能无法准确反映所生成代码的真实行为，最终仍需要人工检查和理解。
其次，扩展（Scaling）：除了系统的直接性能之外，企业软件还需要一个可扩展的开发流程。这要求多个开发人员协作，以降低风险、促进共享理解并确保长期能力增长。这种共享理解是通过文档，以及更重要的是，通过用人类可读的编程语言编写的代码来建立的。现代开发团队编写的代码易于理解，并且能够通过可执行的规范来验证系统行为，这些规范是最终的文档，并在很大程度上决定了维护成本——通常是初始实施成本的许多倍。Vibe coding，然而，只提供对话流或AI摘要作为“文档”，两者都无法提供精确的系统描述。虽然原始代码是可访问的，但即使是经验丰富的程序员也可能难以解读AI生成的源代码，这对协作、代码审查以及不熟悉其独特结构的个体之间解决合并冲突构成了重大挑战。无论是软件本身还是开发过程，vibe coding都无法有效扩展。
第三，软件设计（Software Design）：软件的架构设计始终很重要，甚至可以成为关键的竞争优势，实现独特的组织能力。这些设计决策，与功能需求不同，深刻影响着软件适应未来需求的容易程度。在vibe coding中，设计很大程度上是事后才考虑的。人们可能期望，如果设计原则因新需求而失效，整个系统可以由AI重新生成。然而，这需要一种机制来确保所有先前的指令都能被准确地继承，这类似于一个派对游戏，玩家必须回忆一个不断增长的物品列表。对于“一次性”项目，设计问题微乎其微，但对于长期系统，维护成本将远远超过初始开发成本。忽视设计几乎不可能控制这一成本曲线，从而使软件在经济上不可行。
最后，安全与合规（Security and Compliance）：企业面临巨大的安全和合规负担。大型组织的开发人员精通于保护访问、保护数据以及满足审计要求（例如ISO:27001）。在整个开发流程中，从代码仓库到部署，工具和技术确保了合规性。将vibe coding与这些严格的审计要求相协调是极其困难的。需要大量额外的工作来证明AI生成的代码已经经过了与人工编写、经过同行评审且基于产品规范的代码相同的严格审查。必须权衡“节省”的开发人员时间所带来的经济模型与确保代码安全、无隐藏漏洞和合规性所需的急剧增加的验证成本。仅仅从对话提示中整理需求所产生的成本，就可能轻易超过任何感知到的开发节省，同时还会加剧数据丢失、泄露和声誉损害的风险。
Vibe coding对企业的吸引力源于一系列危险的错误假设，特别是它将降低开发成本的观念。正如Octopus公司GitOps和开源副总裁丹·加菲尔德（Dan Garfield）恰如其分地指出：“企业中vibe coding面临的最大挑战与模型质量或工程师潜在缺乏经验无关。它在于vibe coding在指数级地增加测试和降低软件交付风险重要性的同时，也增加了突破临界点的变更量。”
其潜在假设很常见，但存在根本性缺陷：
假设： 软件开发过程中创造的价值仅仅是代码本身。
现实： 真正的价值在于代码所体现的知识，以及更重要的是，理解和维护这些代码的开发者所拥有的知识。
假设： 创建应用程序是最昂贵的部分。
现实： 在其生命周期内维护应用程序通常要昂贵得多。
假设： 生成代码可以节省时间。
现实： 生成代码只是将负担从编码转移到其他通常更复杂的活动，如密集测试、彻底审查和严格审计。
对于企业软件交付而言，这些错误的假设直接通向未来的痛苦，将一个看似捷径的道路变成了一条代价高昂的弯路。