Reading: 【翻译】探索生成式 AI

作者：Birgitta Böckeler

生成式ai和代码生成器的区别

在我职业生涯的开始，我在模型驱动开发（MDD）领域做了很多工作。我们会想出一种建模语言来表示我们的领域或应用程序，然后用该语言以图形或文本方式（自定义UML或DSL）描述我们的需求。然后，我们将构建代码生成器以将这些模型转换为代码，并在代码中保留由开发人员实现和定制的指定区域。

然而，这种代码生成风格从未完全起飞，除了嵌入式开发的某些领域。我认为这是因为它处于一个尴尬的抽象级别，在大多数情况下，它不能提供比其他抽象级别（如框架或平台）更好的成本效益比。

使用 GenAI 生成代码有什么不同？

我们在软件工程工作中不断做出的关键决策之一是选择正确的抽象级别，以便在实现工作与用例所需的可定制性和控制级别之间取得良好的平衡。作为一个行业，我们一直在努力提高抽象级别，以减少实施工作并提高效率。但是有一种看不见的力场，受到我们需要的控制水平的限制。以低代码平台为例：它们提高了抽象级别并减少了开发工作，但因此最适合某些类型的简单直接的应用程序。一旦我们需要做一些更自定义和更复杂的事情，我们就会碰到力场，不得不再次降低抽象级别。

GenAI解锁了一个全新的潜力领域，因为它不是粉碎力场的又一次尝试。相反，它可以使我们人类在所有抽象级别上更有效，而不必正式定义结构化语言和编译器或代码生成器等转换器。

我们应用GenAI的抽象级别越高，构建软件的整体工作量就越低。回到低代码示例，该空间中有一些令人印象深刻的示例，它们展示了如何通过几个提示构建完整的应用程序。不过，就您可以涵盖的用例而言，这具有与低代码抽象级别相同的限制。如果你的用例遇到那个力场，并且你需要更多的控制 - 你将不得不回到较低的抽象级别，并回到更小的可提示单元。

我们需要重新思考我们的抽象水平吗？

当我推测GenAI在软件工程方面的潜力时，我采取的一种方法是考虑我们的自然语言提示和目标抽象级别之间的抽象距离。我上面链接的Google的AppSheet演示使用了一个非常高级的提示（“我需要创建一个应用程序来帮助我的团队跟踪旅行请求[...]填写表格 [...] 应将请求发送给经理 [...]”）以创建正常运行的低代码应用程序。我们可以用这样的提示向下推送多少目标级别以获得相同的结果，例如使用 Spring 和 React 框架代码？或者，提示需要多少更详细（和不那么抽象）才能在 Spring 和 React 中达到相同的结果？

如果我们想更好地利用GenAI在软件工程方面的潜力，也许我们需要完全重新思考我们传统的抽象级别，为GenAI建立更多“可提示”的距离。

感谢John Hearn，John King，Kevin Bralten，Mike Mason和Paul Sobocinski对本备忘录的深刻评论