Vibe 编码（或 vibeware）现在在 X 上流行起来。据我所知，Andrej Karpathy 在本 X 条目中发起了“模因”。我发现它写得很好，很有趣，而且似乎已经流行起来了。
不过在此之前，reddit 上的一篇帖子已经广为流传，有人在不懂 Python 的情况下构建了整个 Python 代码库，而现在人工智能很难理解该代码库并提出解决方案和错误修复。
显然，这引起了强烈的反对。程序员似乎很害怕，但不一定是因为人工智能可能会抢走我们的工作。主要是因为代码质量和理解力方面的担忧，以及对未来的推断，以及这将给我们带来什么。
另一方面，各种类型的开发者、独立黑客、个体创业者、产品经理、营销人员，以及我称之为加速主义者的人（主要是 X 平台的）都对这种可能性感到兴奋不已，他们完全支持这种可能性。有观点认为，高级开发人员很快就会集体前往失业办公室。
不同上下文情境中的Vibe氛围编码
那么，氛围编码到底是好还是坏呢？当然，这得看具体情况、目的和结果。
首先，我觉得公司和他们的技术团队不会突然就开始盲目地搞氛围编码，然后把结果直接用到实际产品中。这种事情在成熟的公司里是不会发生的。像测试驱动开发（TDD）、代码审查、持续集成这些东西存在都是有原因的，它们不会消失。
根据我的经验，没有哪个理智的公司会把看不懂的代码直接用到产品里，而且我觉得人工智能也不会改变这一点。
相反，我觉得现在的工程师在审查代码时要更加小心和警惕，因为他们知道像copilot这样的工具可以用来生成代码。
作为一个工程师，不管代码是怎么生成的，理解你写的代码是你自己的责任。虽然这个行业确实在尝试用人工智能来帮忙写代码，但至少目前来看，大部分代码还是由人写的，也还是由人来审查的。
另一方面，对于那些独立开发者、自由程序员或者个体创业者来说，从写氛围编码到直接用到产品里——谁在乎呢？我觉得，只要代码能正常运行就行。如果你是独立创业者，那么这么做的风险其实很低。即使代码变得复杂到你都看不懂了，你也可以从头再来，从过去的错误中学习。
下一次，你可能会采取更小的步骤，改进你的开发流程（虽然迭代开发是软件工程师的一种常见做法，但当非程序员开始写氛围编码时，可能不会想到这一点——这也是一个值得进一步探讨的有趣话题）。
非程序员的 Vibe 编码
这个Reddit用户提到的问题其实不是什么新鲜事。
我敢说，自从有了计算机，人们就一直在写那种乱七八糟的代码，也就是所谓的“意大利面条式代码”。而且不仅仅是业余爱好者会这样，实际上，可能大部分都是专业人士写的。
那些失败的“氛围编码”项目的结果，其实和随便拼凑一个Wordpress网站的结果差不多。比如，你可能装了一大堆插件，结果两年后发现，啥都用不了了。可能是因为版本太旧，插件没人维护了，或者你根本没法升级了。当然，Wordpress只是个例子，但我们在做网页开发或者编程的时候，经常会在各种代码库里看到这种情况。
“初级开发人员无法再编写代码了”
氛围编码中出现的另一个有趣案例是初级开发人员。我在这方面没有太多信息，因为我现在很少与这个行业的新人互动。
然而，最初的见解似乎基本符合你的预期：新初级开发人员实际上无法编写代码。
话虽如此，我认为我需要同意 Gergely Orosz 的观点，“新开发人员不会编码”是一个古老的故事。这并不是什么新鲜事，很可能每一代程序员都对即将到来的新一代程序员这么说。
更有趣的问题是——有了所有现代工具，新开发人员将如何成长和发展？我相信，以此推断未来可以让我们深入了解软件工程学科本身的未来。
当我们说话时，机器人正在更新我们的代码库
我们也不要忘记，在 AI 代码生成之前，我们已经拥有许多半智能自动化。 例如， Dependabot几乎无需人工干预，每天更新您的依赖项。如今，在您的存储库上运行它是一种标准做法。我们实际上是让机器人更新我们的依赖项，合并并将代码部署到生产中，而无需任何人工监督。这是通过拥有一个您相当有信心的测试套件、一个针对每个更改运行该测试套件的持续集成管道https://www.jdon.com/59269.html和一个将其自动发布到世界的持续部署管道来实现的。明天的自主代码生成能力将比这更进一步。
应用氛围编码
首先，我要说的是，我发现氛围编码确实可以发挥作用，这真是太神奇了。事实上，你可以直接与模型对话，告诉它你想要实现的想法，它会给你代码、部署说明、各个步骤的解释，并就整个项目、决策、想法、解决方案、进一步改进等进行连贯、持久的对话，这真是太了不起了。我确实感受到了 AGI。
同时，由于前面提到的问题，人们很容易将整个前提视为在严肃的软件工程环境中永远行不通的东西。但我们必须承认，人工智能和人工智能驱动的软件开发将继续存在。这种工具将继续改进，并将在不久的将来永远改变软件生产的格局。
它已经改变了软件产品构建的各个方面，包括营销、产品工程、运营、交付和维护，因此不禁要问，这一切对于在更大、更“成熟”的组织中实践的软件工程学科的未来意味着什么？
带有 AI DNA 的产品
让我们推测一下不久的将来可能会推动软件工程变革和实践的一些产品功能：
自我修复软件
与 Dependabot 升级依赖项类似，我们可能会看到自我调整和自我修复系统，其中会自动检测和分类错误。修复将自动实施并部署到生产中。这将需要多个系统之间的集成 - 错误报告软件、可观察性系统、版本控制、可能的票务系统和公司聊天系统，用于通知和编排。软件工程师将负责设计和维护这些集成，以及监控将执行工作的 AI 代理。
提示管理系统
随着越来越多的系统与 LLM 和 AI 代理集成，版本控制工作提示可能会成为现实。跟踪提示的更改、了解更改对代码库的影响、标记 AI 生成的代码部分并跟踪其相应的提示将成为传统版本控制系统的新亮点。
自动生成的功能
想象一下最终用户通过表单或聊天机器人请求某项功能，该功能会自动验证安全性、实施并部署到生产中，无需或仅需极少的人工干预。除了标准测试、安全检查之外，可能还会有专门的人工智能来审查建议的更改、安全审计等。最后，人类可能会在更改生效之前对其进行批准。同样，需要软件工程师来推动、实施和维护这些流程。
对话驱动开发（又名Vibe Coding Enterprise Edition）
软件开发可能更多地转向关于“什么”而不是“如何”的对话空间（想想Cucumber和BDD，但主要由 AI 驱动）。在 AI 实际实施之前，可能需要专门的软件来弥合非确定性 AI 输出和由详细测试和/或形式验证驱动的确定性代码之间的差距。我们需要熟练的软件工程师来进行测试驱动过程并创建工具来验证 AI 是否生成正确的代码。
生产氛围编码原型
肯定会有一段时间，程序员将负责使氛围编码原型做好生产准备。这些可以由非程序员作为 A/B 测试或实验的一部分完成，在一些小组中验证并移交给他们，使其做好生产准备。
更具交互性的文档
自动生成和维护您可以讨论和提问的文档。将代码和可观察性融入上下文中，使体验完全集成，您可以在文档、代码和可观察性工具之间无缝切换，以深入了解和理解您正在分析的系统。
其他
可能还会出现其他“副驾驶”类型的协作工具。AI 代理会监控系统性能并自动持续提出改进建议。AI 代理会跟踪对话和技术讨论，并提出消除浪费、差距或改进各种流程的机会。AI 驱动的系统可观察性：将出现新的工具，以缩短生产事故中的反应时间和恢复时间。
概括
目前，氛围编码，取决于你问谁，要么是令人厌恶的东西，是未来问题的根源，是我们自己造成的灭亡，要么是一种神奇的、平等的、平等的、民主化的工具，可以让人们将自己的想法变成现实，而无需学习编码。作为软件工程师，无论我们喜欢与否，我们很快就会在整个软件开发生命周期中与人工智能打交道，如果不是已经这样做的话。
氛围编码模因暗示了事情的发展方向。它是对软件开发未来的一瞥。
我们的工作是想象和制造工具、构建解决方案、实践和设计流程，使我们能够利用人工智能的力量安全高效地构建更好的软件产品。
网友：Cursor + Supabase + MCP= 最佳的 AI 驱动的 MVP 开发。