应用程序开发和交付 (AD&D) 专业人员的未来工作将不得不改变。 今天，大约 70% 的工作都是关于胶水代码的开发和将事物连接在一起。 从 UI 前端到应用程序的后端，以及集成层，有大量重复性的任务、设计模式和编写的自定义代码。 更糟糕的是，许多团队一遍又一遍地重复开发相同的代码。 创造性的业务逻辑通常代表最小的努力。 当您尝试构建新的、有创意的和差异化的定制软件时，这种浪费会增加更多。
但随着更多 AI 驱动的创新变得可用，更多的可能性出现，可以帮助开发人员提高生产力——特别是来自共享的 AI 注入开发工具的增强，我们在本博客的第一部分中更详细地概述了这一点。
此外，传统科技巨头正在取得重大进展，例如 IBM 的 AI 代码和 Project CodeNet 以及 Microsoft 的 GitHub Copilot。 两者都为企业应用程序现代化工作、编码生产力的提高和开发人员的简化带来了增强和自动化。
企业图灵机器人：深入探索未来
这就是帮助构建企业软件的“TuringBots”或 SW 机器人发挥作用的地方。 我们在 Forrester 中以英国天才 Alan Turing 的名字创造了 TuringBots 一词。 我们相信，在未来 5 到 10 年或更短的时间内，基于 AI 的突破性创新，如 AI 2.0，TuringBots 将由多家技术供应商创建。 企业可以期待利用 TuringBots 更好、更快、无错误地编写应用程序代码。 打包的应用程序业务平台、低代码环境、专业开发和测试工具都将利用 TuringBots，并且已经开始这样做了。
TuringBots 将使用 AI 和机器学习 (ML) 来构建从现有代码中“学习”的模型，并确定哪个代码生成器可以满足业务应用程序和基础架构要求，以生成和交付源代码和可执行代码。 强化学习似乎是 TuringBots 的可能基础技术。 但其他各种人工智能基础技术也是强有力的候选者：从深度学习模型到 GPT-3 再到神经符号推理（很可能是所有这些的混合）。
我们确实知道 TuringBots 必须在以下核心操作原则的基础上工作：
设计工件必须采用标准化格式。
当委托编写整个系统时，生成的代码将不会像过去那样必须是人类可读的。 为什么？ 因为 TuringBots 可以随时快速重新生成代码。 因此，我们所要做的就是更改需求和约束，然后 — 瞧 — 您将获得新代码。
但是，如果 TuringBots 与开发人员（例如，Microsoft 的 GitHub Copilot）共同编写代码，则生成的代码是可读的。
TuringBots 必须满足几个预定义的服务级别协议和约束。
如果需要自定义代码，扩展点将被定义为设计工件中的服务。
TuringBots 将根据设计工件和实施技术工具包以及所需的架构质量生成多个版本的业务应用程序。
TuringBots 将永远改变我们为企业构建应用程序的方式
随着 TuringBots 的出现，我们构建企业应用程序的角色、工具和技术将永远改变。 以下是我们对使用 TuringBots 的未来软件开发生命周期的一些初步想法和想法：
应用程序开发设计人员将使用工具来设计端到端的应用程序工件，这是需求的起点。 我们在这里并不是指传统的 UML 或 BPMN 模型驱动生成。
企业应用程序架构师将定义参考应用程序和基础架构技术堆栈（例如，UI 框架、API、微服务、Kubernetes、数据库、持续集成/持续交付工具链等）。 IBM AI for Code 堆栈代表了一个强大的起点，它提供了注入 AI 的工具来提供帮助。
解决方案架构师将围绕可用性、效率、安全性、可靠性、负载、可访问性等定义应用程序架构质量（即非功能性需求）。
TuringBots 将“阅读”和“学习”上述所有应用程序端到端设计工件和质量要求，包括参考应用程序和基础设施技术堆栈。
AD&D 专业人士和 TuringBots 将共同构建、更改和重构应用程序，并将它们扩展到比当前流程快几个数量级，从而显着降低成本——所有这些都尽可能接近按下按钮的敏捷性。
