生成式人工智能正在改变软件开发领域，但专家们对无代码和低代码平台的未来持有不同看法。一些人认为GenAI将取代无代码，而另一些人则认为它将增强现有平台，特别是那些具有强大治理和安全性的平台。融合开发团队和企业级平台将变得更加重要。
作者：Darryl K. Taft
软件开发领域再次经历着一次重大转变。在拖放式、无代码平台普及应用创建多年之后，在许多情况下，生成式人工智能 (GenAI)正在消除对无代码平台的需求。
请注意，我说的是“无代码”，而不是“低代码”——它们之间存在关键差异。（稍后会详细介绍。）
GenAI 引入了一种能力，让非技术用户可以使用自然语言来构建应用程序，只需告诉系统他们想做什么。称之为“氛围编码”——描述你想要的东西，然后观看人工智能生成可用的应用程序，或其他任何东西。但是，这种新模式会增强现有的无代码工具，还是会使其过时？
我向行业资深人士寻求见解，以探讨这个关键问题，揭示了关于人工智能和可视化开发的交叉点将走向何方的广泛观点。
技术债务困境
David Mytton 是 Arcjet 的 CEO，他长期观察开发工具的演变，对传统无代码及其人工智能驱动的继任者都提出了警告。“我一直觉得‘无代码’的想法有点奇怪，因为对于任何非简单的应用程序，它仍然需要大量的工程工作来连接数据库、连接表单，并理解所有交互应该如何工作，”他告诉 The New Stack。
然而，“我预计 GenAI 会让构建这些应用程序更快更容易，但它仍然会造成技术混乱，”他说。“未来几年，氛围编码内部应用程序将成为技术债务的巨大来源！”
这种观点突出了软件开发民主化中的一个根本矛盾：速度和易用性通常以架构的合理性为代价。
“我预计 GenAI 会让构建这些应用程序更快更容易，但它仍然会造成技术混乱。未来几年，氛围编码内部应用程序将成为技术债务的巨大来源！”
—David Mytton, Arcjet CEO
“氛围代码杀手” 命题
Josh Haas 是 Bubble 的联合 CEO 兼联合创始人，他采取了不同的立场，将他的公司定位为他所谓的“氛围代码杀手”。经过 13 年的无代码工具构建，Bubble 现在正在转型为一家人工智能公司——不是为了取代可视化开发，而是为了创造全新的东西，他告诉 The New Stack。
他说，氛围编码适用于构建原型，“但是一旦你尝试在它上面构建一个真正的应用程序，你就会发现人工智能犯了一些错误，”Haas 解释说。“作为应用程序的所有者和创建者，你需要了解代码的作用，我不认为人工智能可以替代。”
Bubble 的解决方案是什么？人工智能帮助你构建，但它构建的内容是用公司的可视化无代码语言表达的。“你实际上可以理解人工智能在做什么。你可以自己调整它，你可以给人工智能提供具体的反馈，不仅仅是基于输出，而是基于对应用程序内部结构的全面理解，”Haas 说。
这种混合方法承认了人工智能的力量，同时保持了纯代码生成所缺乏的透明度和控制。
代理优先的未来
人工智能应用程序构建平台提供商 Replit 的创始人兼 CEO Amjad Masad 采取了更为激进的观点，他认为整个无代码与低代码之争可能变得无关紧要。“我认为两者都会消失。代理将完成这项工作，”他预测，将人工智能定位为与以前的方法根本不同，因为它“更灵活，并且基于开源语言和库。”
Masad 设想了一个未来，在这个未来中，编码和“无编码”之间的区别消失了，取而代之的是人工智能代理，它们处理技术实现，而人类则纯粹专注于描述期望的结果。
无代码的死刑判决？
与此同时，低代码平台提供商 Mendix 的战略高级副总裁 Gordon Van Huizen 对传统无代码的未来做出了或许是最直接的判决。当被问及 GenAI 工具是否消除了对无代码的需求时，他明确地表示同意：“对于无代码？我绝对同意这一点。你知道，我认为无代码是为了解决在一段时间内存在的特定问题，要么是问题的本质发生了重大变化，以至于你不再称其为无代码，要么它最终会消失，”他告诉 The New Stack。
但 Van Huizen 的批评比简单的替代更为深刻——他指出了纯氛围编码的根本缺陷，这解释了为什么这种转变不会一帆风顺。“GenAI 本身的答案还不够好，因为你将得到数百万行人工智能编写的代码，这些代码尚未准备好投入生产、未经强化、存在错误，并且将成为一场无法维护的噩梦。”
他的担忧集中在他所谓的“意图捕获问题”上：“在氛围编码的世界里，如果你真的在进行氛围编码，你知道意图基本上会消失得无影无踪。你知道几乎立即你就会放入一些可能应该存在于用户故事中的东西……”
Van Huizen 还预测，鉴于微软能够访问用户数据并集成现有的生产力工具，Microsoft 的 Power Platform 最有希望主导这个不断变化的格局。
可视化开发的持久性
无代码平台提供商 Creatio 的方法与“无代码已死”的说法形成了鲜明的对比。他们没有将人工智能视为一种替代品，而是将其视为一种增强功能，使可视化开发更强大，而不是过时。
当被直接问到，“如果可以让人工智能为你做一切，为什么还需要无代码？”时，Creatio 的首席产品官 Burley Kawasaki 告诉 The New Stack：“我会说，人工智能实际上是无代码的一种形式，对吧？只不过它使用的是自然语言，而不是可视化设计工具。”
Kawasaki 补充说，“我认为自然语言非常适合某些事情。UI 设计工具非常适合其他事情，特别是如果你正在设计一个像素完美的用户界面，你想要构建对布局的控制，或者如果你想要能够设计一个仪表板……”
他说，Creatio 的“人工智能原生”平台在其整个平台中嵌入了对话界面，同时保持了可视化设计工具，以便在它们更有效的任务中使用。
“我会说，人工智能实际上是无代码的一种形式，对吧？只不过它使用的是自然语言，而不是可视化设计工具。”
—Burley Kawasaki, Creatio 首席产品官
企业现实：OutSystems 的代理编排模型
低代码平台提供商 OutSystems 的开发人员副总裁 Miguel Baltazar 提供了一个将理论与实践相结合的视角。在低代码领域拥有 22 年从业经验的 Baltazar 告诉 The New Stack，OutSystems 的方法说明了成熟的平台如何演变为人工智能代理的协调者，而不是被它们取代。
“有趣的是，人工智能更具颠覆性，因为它颠覆了你构建应用程序的方式和应用程序本身，”他说。OutSystems 开发了“Mentor”，这是一个完整的软件开发生命周期助手，可以在几分钟内根据需求生成数据库、UI 和逻辑。
但 Baltazar 专注于“代理式人工智能”趋势及其对企业开发的影响。“应用程序开始能够拥有并非为人类设计的界面。它们并非为后端设计。它们是为代理设计的，”他说。
然而，挑战在于代理是不完美的：“很多代理在执行时，60% 或 70% 的时间都能完美执行，但有 30% 的时间它们要么产生幻觉，要么无法完成任务，”Baltazar 说。
这种可靠性差距需要复杂的协调——而这正是低代码平台擅长的，他指出。“构建这种协调，构建人类与代理交互以获取所有数据的界面，为代理构建 RAG [检索增强生成] 上下文，使其能够使用事务的当前上下文进行操作……所有这些事情都可以很容易地以可视化的方式构建。”
他说，OutSystems 及其客户正在将这种方法用于实际应用。OutSystems 本身通过使用通过其平台协调的人工智能代理，减少了 35% 的支持单提交。
氛围编码的现实检验
OutSystems 的视角还提供了对纯氛围编码工具的最坦率的评估之一。Baltazar 广泛尝试过 Windsurf 和 Lovable 等工具，他承认它们的吸引力，同时强调了关键的局限性。
“这太酷了，对吧？你可以去那里。你告诉它你想要什么，”他说。“但是，如果你真的不理解它生成的内容，它很快就会失控。”
他的经验与其他人对人工智能生成的代码的可持续性的担忧相呼应：“你在那里花费了四五个小时，而你最终得到的东西不是我敢冒险投入生产以满足业务需求的东西，”他说。
此外，Baltazar 发现了所谓的“立即孤立代码”问题：“如果你不理解人工智能生成的内容，并且你不会阅读代码，你实际上从第一天就开始创建孤立代码。因为编写代码的人是唯一能够理解的人，而它是一个人工智能。”
他用一个类比来说明这一点：“这就像尝试用人工智能用日语写一本书。你说，‘好的，写这个，’它会给你日语句子。然后你说，‘好的，这是我的日语书，太棒了。’然后你把它交给一个日本人……你正在尝试用一种你不理解的语言写一些东西。”
“如果你不理解人工智能生成的内容，并且你不会阅读代码，你实际上从第一天就开始创建孤立代码。因为编写代码的人是唯一能够理解的人，而它是一个人工智能。”
—Miguel Baltazar, OutSystems 开发人员副总裁
构建块优势
Bubble 的方法为 Mendix 和 OutSystems 共同发现的“孤立代码”问题提供了一个引人注目的解决方案。他们的 AI 不是生成原始代码，而是使用 Haas 描述的“生产化的构建块”来构建应用程序。
“你可以将无代码视为乐高积木，我们构建的不同块，我们确保它们是安全的，我们确保它们是强大的，我们确保它们是可扩展的，”Haas 解释说。“因此，当 AI 吐出一个由这些块组成的应用程序时，你得到的东西实际上可以用来工作，并且在构建业务时可以实际使用，而不仅仅是构建原型。”
这种方法解决了 Mendix 提出的安全问题和 OutSystems 强调的可维护性问题。可视化表示对业务用户来说仍然是易于理解的，而底层实现则保持了企业级标准。
巨大的鸿沟：Vibers 与工程师
Scotiabank Digital Factory 的移动开发人员 Abhishek Sisodia 对这种转型提出了细致的看法。他认为氛围编码是“新的无代码——只不过现在是人工智能在承担重任，而不是拖放构建器。”他说，优势是显而易见的：“它更快。它更容易访问。而且在许多情况下，它也更加强大。”
但 Sisodia 也发现了一个关键风险：“虽然 GenAI 能够以前所未有的规模进行快速原型设计，但它经常跳过对系统架构、可扩展性、安全性和长期可维护性的批判性思考。”
他预测市场将会出现分叉。“那些学会将‘氛围’与真正的技术验证相结合的人将构建下一代变革性产品，”Sisodia 说。“其余的人可能会通过氛围编码走向无关紧要。”
OutSystems 的经验证实了这一预测，Baltazar 指出，氛围编码“绝对是专业、硬核开发人员的工具，他们知道生成了什么，并且了解其背后的原理。”
“那些学会将‘氛围’与真正的技术验证相结合的人将构建下一代变革性产品。其余的人可能会通过氛围编码走向无关紧要。”
—Abhishek Sisodia, Scotiabank Digital Factory 的移动开发人员
平台加速论
与此同时，Forrester Research 的首席分析师 John Bratincevic 提出了一个与市场数据支持的相反的观点。他认为，人工智能不会取代低代码平台，而是会加速它们的采用。“SDLC [软件开发生命周期] 中的人工智能将增加软件交付的低代码化和平台化，”他告诉 The New Stack。“生成软件需要更多的抽象和集成，而不是更少。”
他的数据显示，“低代码的采用率一直在上升”，他认为真正的颠覆发生在其他地方，他说。
“真正的威胁在于‘现成的’应用程序，而不是开发平台本身，”他指出。
Bratincevic 预测将会出现融合。
“一些获胜的供应商将是现有的低代码供应商，而另一些将是新的进入者，”他说。“但所有产品最终在几年内看起来都会非常相似。”
无代码与低代码：一个重要的区别
与多个平台供应商的对话强化了一个关键的区别，即在讨论人工智能对可视化开发的影响时，这种区别常常被忽视。来自 OutSystems 的 Baltazar 和来自 Mendix 的 Van Huizen 都认为，无代码和低代码面临着截然不同的未来。
Baltazar 同意无代码将被 GenAI 吞噬，“因为技能组合相似。”他对无代码局限性的洞察解释了原因。
“无代码唯一拥有的 GenAI 没有的是它工作的非常有限的一组参数，”他说。“一旦你超出这些参数，那就糟了，因为它比用高级代码做要难三倍。”
这造成了他所谓的危险悖论。
“GenAI 甚至比无代码更危险，因为在无代码中，至少你拥有那个可以在其中玩耍的围墙花园，”Baltazar 补充说。“但是 GenAI 可以生成你想要的任何东西……数千个类，大量的 JavaScript 和其他代码集，如果你不理解它在做什么，它真的会成为孤立的代码。”
相比之下，低代码平台保持了可读性和治理，他指出。
“使用低代码，即使对于不是专家开发人员的人来说，生成的东西也是可读的，”Baltazar 说。“你可以理解数据流。你可以理解可视化表示。”
“GenAI 甚至比无代码更危险，因为在无代码中，至少你拥有那个可以在其中玩耍的围墙花园。但是 GenAI 可以生成你想要的任何东西……数千个类，大量的 JavaScript 和其他代码集，如果你不理解它在做什么，它真的会成为孤立的代码。”
—Miguel Baltazar, OutSystems 开发人员副总裁
也就是说，Bubble 模型代表了一种有趣的混合——在保持低代码的可视化可理解性的同时，使用 AI 来加速开发。
“我们的愿景是，你知道，Bubble 的用户最终会学习它，并且存在一个学习曲线，但是 Bubble 的学习曲线与代码的学习曲线相比截然不同，”Haas 告诉 The New Stack。
集成而不是替代
Intellyx 的分析师 Jason Bloomberg 采取了一种务实的中立立场，他认为“‘吞噬’可能是一个太强的词。”他指出，“所有低代码/无代码平台现在都在集成 GenAI，要么是为了增强应用程序规范过程，要么是为了构建可用的应用程序。”
然而，Bloomberg 强调了纯 AI 生成的局限性。
“从提示构建可用的应用程序说起来容易做起来难，”他告诉 The New Stack。“要么应用程序必须遵循 LLM [大型语言模型] 已经训练过的既定模式，要么充其量它可以构建出大约 80% 的可用应用程序。”
他的预测侧重于用户体验的演变。“GenAI 正在成为每个无代码平台的必备功能，但它并没有吞噬它们，”Bloomberg 说。“最终目标是让无代码供应商在已使用的其他无代码隐喻列表中添加一个基于提示的隐喻。”
Bubble、Creatio 和 OutSystems 的经验验证了这种集成方法。他们没有将 AI 视为一种替代品，而是将其嵌入到整个开发生命周期中，同时保持了可视化、可治理的特性，这些特性使平台能够可持续地用于企业开发。
范式已经转变
The Futurum Group 的分析师 Brad Shimmin 认为转型已经在进行中。“范式已经转变为无代码工具，”他说，并将商业智能工具如何从传统界面演变为自然语言处理进行了类比。
作为证据，他指出了现实世界的例子。“Airtable 等公司使用他们的 Cobuilder 工具作为应用程序开发的起点，用户只需描述他们想要构建的应用程序以及该应用程序将在其中运行的上下文，”他说。“关键的洞察在于，用户使用提示而不是下拉菜单开始他们的开发工作”，同时仍然保留传统的开发范例，例如备份选项。
各种各样的用户，各种各样的解决方案
然而，Bloomberg 指出，氛围编码的影响很大程度上取决于谁在使用它以及他们正在构建什么。“在低经验的一端，业务用户可以轻松地使用氛围编码来创建相对简单的应用程序，”他说。“这些用户并不真正关心香肠是如何制作的，只要它能用就行。”
但是，对于从事 Linux 内核更新或设备固件等复杂系统的高级开发人员来说，氛围编码几乎没有价值，他说。但对于广大的企业开发人员来说，“氛围编码是工具箱中的一种工具——但他们必须审查每一行生成的代码，以确保他们理解它并且它没有安全或质量问题。”
企业实施：微软的平台战略
当通过 Microsoft 的 Power Platform 战略来看待围绕 AI 和无代码的理论讨论时，它们呈现出实际的维度。Microsoft 的 Power Platform 智能应用程序公司副总裁 Ryan Cunningham 对“AI 将取代一切”的说法提出了不同的看法。
“正如我们在过去十年中所认为的那样，传统的低代码可能不是未来十年的答案，”Cunningham 承认。“但是一个平台，一个抽象层，现在比以往任何时候都更加重要。”
Microsoft 的方法说明了成熟的平台是如何演变的，而不是被取代。他们新的“计划”概念超越了传统的拖放界面，转变为 Cunningham 称之为“数字软件团队”——充当需求分析师、流程分析师、数据建模师和解决方案架构师的 AI 代理。
“正如我们在过去十年中所认为的那样，传统的低代码可能不是未来十年的答案。但是一个平台，一个抽象层，现在比以往任何时候都更加重要。”
—Ryan Cunningham, Microsoft 的 Power Platform 智能应用程序公司副总裁
“我们实际上构建了不仅可以充当编码人员，还可以充当需求分析师、流程分析师和数据建模人员的代理，”他告诉 The New Stack。“他们会进来并开始研究这个问题，推荐并构建正确的前进方向，然后生成结果资产。”
这代表了纯 AI 生成和传统可视化开发之间的一种中间道路：AI 驱动的规划和分析融入到具有内置治理、安全性和可扩展性的企业级平台中。
抽象演化继续
Cunningham 还为当前的颠覆添加了历史背景。
“在过去的 40 年里，我们为软件工程师所做的一切都是添加抽象层，因此我们不必编写低级汇编代码，”他说。“我们正处于下一个抽象层的悬崖边上。”
这种框架将 AI 驱动的开发定位为不是与过去的革命性决裂，而是朝着更高层次抽象的数十年进程中的逻辑下一步。Cunningham 指出，不同之处在于，这个抽象层可以理解自然语言需求，并将它们转换为可用的软件。
“在过去的 40 年里，我们为软件工程师所做的一切都是添加抽象层，因此我们不必编写低级汇编代码。我们正处于下一个抽象层的悬崖边上。”
—Ryan Cunningham, Microsoft 的 Power Platform 智能应用程序公司副总裁
企业现实也加强了平台倡导者的论点。每月有 5600 万人使用 Power Platform，90% 的财富 500 强公司采用了 Copilot Studio，这些数据表明，具有 AI 功能的成熟平台在企业市场中胜过纯 AI 优先的工具。
融合团队变得更加重要
事实上，Cunningham 认为，AI 并没有消除业务和技术用户之间协作的需求——它使这种需求变得更加重要。Cunningham 强调，“融合开发团队”——由专业开发人员和公民开发人员组成的开发团队——仍然是他们战略的核心。
“很难教会一个商人如何构建可扩展、安全的企业软件。很难教会软件开发人员如何运营企业，”他说。“但是如果我可以将他们都放在同一个工具包中，他们就可以一起做令人惊叹的、神奇的事情。”
这与 Bloomberg 以用户为中心的分析相一致——目标不是消除技术专业知识，而是创建更好的协作模式，使业务知识和技术能力可以更有效地协同工作。
“很难教会一个商人如何构建可扩展、安全的企业软件。很难教会软件开发人员如何运营企业。但是如果我可以将他们都放在同一个工具包中，他们就可以一起做令人惊叹的、神奇的事情。”
—Ryan Cunningham, Microsoft 的 Power Platform 智能应用程序公司副总裁
治理势在必行
此外，Microsoft 的例子突出了纯 AI 生成工具尚未解决的一个挑战：大规模的企业治理，Cunningham 说。他描述了用于管理 AI 生成的应用程序的复杂功能——自动化策略、部署管道、安全控制，甚至还有监控和清理孤立应用程序的 AI 代理。
“我们确实从端到端地考虑了该治理和管理计划，”他指出。“这是客户在平台上构建的原因，特别是高度监管行业的客户。”
前进的道路
正如这个专家圆桌会议所表达的那样，无代码开发的未来不是一个简单的替代或增强的故事。它更复杂，涉及多个用户群、用例和技术方法。
例如，推动具有强大的治理、安全性和企业集成能力的成熟平台的平台供应商似乎在 AI 时代提供了优势。他们没有被 AI 优先的工具颠覆，而是在保持其核心平台的同时融入了 AI 功能。
Bubble 通过 AI 驱动的可视化开发“杀死氛围代码”的方法、Creatio 对现有工作流程的自然语言增强以及 OutSystems 的代理编排模型都指向了一个未来，在这个未来中，AI 将增强而不是取代可视化开发——但方式与传统的无代码根本不同。
正如 Sisodia 所说，最有用的工具将是那些能够利用 AI 的速度和可访问性，同时保持构建可持续、可扩展系统所需的工程规范的工具。
此外，正如 Microsoft 的 Cunningham 指出的那样：随着每个新的抽象层，“我们实际上已经大大扩展了谁在构建软件以及他们正在构建多少软件。”
这个 AI 时代似乎很可能会延续这种模式：创造更多的软件构建者，同时增加而不是减少平台管理结果的重要性。
我对这些专家的评估是，AI 将继续增强现有平台，同时创建新的工具类别。最成功的解决方案将是将 AI 的易用性与成熟平台的治理和可靠性相结合的解决方案。
