AI 原生开发
通过像 GitHub Copilot 这样的 AI 技术，开发团队内工程师的工作可能会发生变化，最终可能会影响架构。 本文档将介绍 AI 原生开发方法可能带来的影响。
一切皆为上下文
像 GitHub Copilot 这样的 AI 技术进入开发环境或开发流程时，涉及的领域是多种多样的。 为了进一步提高开发速度，开发团队需要更加意识到上下文的重要性。 需要注意的是，你的程序包含哪些技术上下文和商业上下文。 这并不是一个新话题，自古以来一直是如此。然而，随着 AI 的出现，现在是时候重新考虑这两个上下文的价值了。 这些上下文将影响架构和工程师的职业生涯。
此外，每个上下文都有高上下文和低上下文的领域。 例如，在编码中编写重复性任务或编写任何人最终都会执行的任务，可能只需按 Tab 键即可接受 GitHub Copilot 的建议。 另一方面，在需要高度上下文的领域中，按 Tab 键并不能产生任何结果。 这些领域需要经验和特定技术领域的知识，因此不是轻松掌握的东西。
技术上下文
考虑几种编程语言来思考技术上下文。 有些语言（如 Python）有共通的表达方式来表示一件事，而另一些语言（如 Ruby）则有多种表达方式。 此外，作用域的范围也是一个问题。 有一些语言（如 BASIC）将全局作用域作为基础，而其他语言则具有较小的作用域。 例如，Rust 中的引用和借用机制是包含技术上下文的典型例子。 在框架层面上，这些上下文可能会重叠多层。
商业上下文
商业领域也是如此。 考虑 SQL 这种数据库语言。 AI 擅长于处理简单的任务，对于复制 SQL 的定型表达式，AI 很适合。 如果只是定义对数据库的访问，那么上下文较少，AI 的支持也相对容易。 然而，在处理复杂交织的大型数据库时，AI 生成的代码是否对其他处理产生影响，难以保证。 需要理解整体架构，并且需要一定的实际逻辑知识。 同样，测试方面也是如此，AI 擅长于根据给定场景编写测试，但很难考虑到全面的测试场景。 对于具有简单 CRUD 功能的 REST API，可以轻松编写 API 测试，但是对于具有复杂授权条件的应用程序的测试，AI 很难完美地编写测试。
AI原生架构
那么，你管理的功能/应用程序的架构中有多少上下文存在呢？ 如果架构包含许多上下文，则利用 AI 提高开发速度的可能性可能会降低。 这是因为 LLM 可以理解的上下文是有限的，AI 同时提供大量上下文是不可能的。 这是因为有一些限制，例如提供的令牌数目有限，而且通常人类无法以 AI 可读的形式提供所有信息。 在某种程度上，AI 可以在提供提示的情况下无限制地工作。 但是，人类可以向 AI 提供提示的时间是有限的。 在这种情况下，瓶颈在于人类。 因此，应该考虑尽可能减少组件的上下文，以便 AI 能够编写正确的程序。
将服务分解为小型单元，建立稀疏关系是一个好主意。 但是，我提到的并不是要将 Kubernetes 中的微服务变成上下文。 这可以包括 SOA 和库级别的分离，无论你考虑哪种设计都没有关系。 重要的是将组件分解为简单且易于测试的单元。 应用程序具有更多上下文，AI 的支持就越困难。
关于程序处理的适当大小，有时会发生宗教战争，而利用 AI 进行开发仍处于刚刚开始阶段，因此没有确切的答案。 但是，考虑到最大化工程师的生产力并使产品以最短的时间成长，您的团队应该考虑至少一次以 GitHub Copilot 为前提的开发方法或架构。
但是，请注意，IT 架构不应该被认为是为最大化工程师的生产力而设计的目的，而应该被视为实现最终目标的手段。
我希望大家能积极参与这个领域的讨论。
作为工程师的职业前景展望
迄今为止，我们已经提到了AI可能会给体系结构和开发文化带来变化的可能性。在这里，我们也需要关注工程职业生涯。这不仅关乎工程师自身，还涉及到那些担任管理职位和构建组织的人们。
最终，工程师需要考虑是成为具备广泛商业产品知识的工程师，还是追求技术精湛的工程师。然而，问题是这两个领域中都存在低上下文和高上下文的领域。
例如，在编码方面，编写简单的重复性工作或编写处理过程，不论由谁编写，最终都会到达该处理过程的情况，可能只需要按下Tab键来响应GitHub Copilot的建议即可。另一方面，在技术上下文和商业上下文部分指定的领域，需要高上下文的领域。由于这些领域需要经验和特定技术领域的知识，因此并不是易于掌握的东西。如果这些是可以在互联网上获得的知识，那么还有追赶的余地，但是，如果这些是特定组织封闭的知识领域，而且没有记录或者获得信息需要非常高的成本，则很难跟上。
这不仅限于编码问题，但是，AI有一种趋势，即增强知识丰富和经验丰富的人。这意味着高级工程师可能会失去新手的工作。如果不处理，新手将不能在组织中担任重要工作，也无法预期其技能的增长。高级工程师的技能将进一步提高，而组织将难以维持这些人的存在，并且也难以将高级工程师与退屈的新手绑定在一起，因为高级工程师已经被时间限制而只能从事退屈的工作。
那么，该怎么办呢？其中一个答案是将产品或组织中的技术信息和商业信息编写成包含上下文的文档，并在内部进行培养。当许多人参与这些文档的创建时，共同创作将发生，并且企业的知识数据库将逐步建立起来。现在正是进行类似于开源的内部协作的时候。
检查清单
Last updated