我们无法准确预测人工智能的影响，但我们可以探索一些可能的破坏点。
源代码：
-
目前，大多数软件系统都是使用源代码开发的——一种人类可读的、确定性的系统行为规范。允许最终用户编程的开发工具通常通过使用记录/回放和可视化编程风格的交互模式来绕过对源代码的需求。当需要改变行为时，源代码表示是有用的。它有助于系统理解并实现行为的细粒度参数控制[1]。
-
有一类系统的大多数行为是由数据的变化决定的。此类包括传统数据库系统以及基于 ML 和 NN 的系统，这些系统创建确定行为的内部（通常是非人类可读的）表示。尽管这些系统很有用，但它们不是透明的，也不是很容易以参数化方式修改的。我们牺牲了源代码提供的对行为的快速、细粒度控制，以便完成其他方式不容易实现的事情。源代码是参数化行为的一种紧凑方式。
-
编程语言通常建立在彼此之上。新编程语言的编译器和翻译器通常以其他高级语言为目标。当他们这样做时，他们能够利用现有的开发平台和生态系统。这个引导过程有一个很好的副作用，它为我们提供了一个人类可读的表示（生成的源代码），但在大多数情况下，构建过程管道最终会崩溃，不再使用源作为中间语言。示例：C++ 最初是作为 C 的预处理器实现的。最终，C++ 编译器直接编译为低级表示、目标代码等。
-
如今，基于 GPT 的系统被用于生成源代码作为中间表示。我们审查然后将生成的代码提供给构建过程。值得考虑是否有必要这样做。近期的答案是：也许吧。基于 GPT 的系统的输出是基于概率的，可以通过在解决方案生成中产生新颖性的“温度”来改变，但也有可能解决方案可能“错过”、错误或产生不良后果（“幻觉问题”） .人工验证目前是流程的关键部分，源代码是可追溯的审查媒介。
-
随着开发转向生成和测试模式，质量保证将重新变得重要。
-
提示在某种程度上替换源代码的可能性很大，但是，“温度”是一个问题。就人工智能产生新奇事物的程度而言，提示不再是行为的确定性规范。无论如何，我们可能会看到提示语言的发展，目的是指定必须具备的行为并对随机性施加约束。这些可能会在 GPT 会议中临时开发并在以后标准化。
模块化：
-
系统会继续由模块化部件构建吗？让我们看一下从部件组成系统的两种常见方法。首先是将零件粘合在一起。另一种是创建带有“孔”或扩展点的作品。笼统地说，前者是库组合方法，后者是框架方法。我们可以将“有和没有”孔的部分视为模块。
-
随着 AI 上下文窗口大小的增加，生成的模块的大小也会增加。这些模块可以被人工智能读取，通过提示修改并按需重新生成。
-
大多数生成代码的系统都有我称之为“逃生舱门”的问题。总有一些事情不能用生成器轻松完成。传统上，处理此问题的方法是提供一种“下拉”到较低级别表示并填写详细信息的方法。就此问题持续存在的程度而言，生成的模块可以提供“漏洞”作为“逃生舱口”。
-
AI 启用了第三种编写软件的方法。具有广泛功能的模块可以由 AI 读取，然后仅使用功能子集和特定用途所需的任何额外定制进行重写。这就像一个自动的私人分叉。可以通过这种方式重用高价值的代码库。
-
另一种可能的开发场景是使用对等 AI 系统，这些系统相互协商功能集以达成系统设计。很难知道这对模块化意味着什么，但很可能康威定律在许多情况下都适用，因为模块化反映了负责生成设计的对等系统的交互。
结束语：
-
源代码似乎对不久的将来有价值。我们可以得到训练有素的人工智能，通过交互和学习，它可以很好地“理解”一个领域及其约束，从而可以根据要求生成大型目标系统。如果发生这种情况，将上下文作为一组嵌入简单地持久化可能是有意义的，绕过对源代码的需要。
-
我们今天拥有的相对较小的上下文窗口似乎是在软件开发中继续使用模块化的主要动力，但 Baldwin 和 Clark [2] 概述的模块化的所有用途仍然存在。模块化不仅仅是一个软件概念；这是几乎所有规模系统都使用的策略。
这就是现在我看来的事情。看看这一切在近期和长期内的表现将会很有趣。
[1] 参数控制 – 系统行为在参数上是可控的，以至于它可以简洁地、确定地、明确地改变。
[2] Baldwin 和 Clark – 设计规则：模块化的力量
在撰写本文时，没有人工智能受到伤害。
原文： https://michaelfeathers.silvrback.com/possible-ai-impacts-on-development-practice