使AI代码助手发挥作用的工作有助于开发者，但组织机构对AI伦理的言论并不总是与其选择相符。
译自 What Tabnine Learned from Building an AI Code Assistant，作者 Mary Branscombe。
开发者们对 AI 编码工具既好奇又怀疑，但也准备好使用它们。Gartner 表示，14% 的企业开发者已经在使用 AI 编码助手，Docker 的 2024 年 AI 趋势报告中三分之一的开发者正在将 AI 用于编码，Stack Overflow 2023 年开发者调查中 43% 的编码人员（尤其是前端、全栈和云基础设施开发者）已经在使用 AI 工具。
许多使用 AI 进行编码的开发者正在从 ChatGPT 复制粘贴（这具有免费的优势）。在集成代码助手方面，尽管此后出现了一系列其他助手，但 GitHub Copilot（在 Gartner 最近的魔力象限中处于领先地位）是去年 Stack Overflow 调查中最受欢迎的工具。
第二受欢迎的是可以被认为是最初的 AI 代码助手 Tabnine。它比 GitHub Copilot 早大约四年，拥有超过一百万的月活跃用户，并承诺了一些企业认为有价值的东西：隐私和机密性。
您可以将 Tabnine 部署为服务，部署在您自己的云租户或您自己的基础设施中，用您自己的代码库对其进行训练（Copilot 可以使用这些代码作为上下文，但不会对其进行训练或微调），并使其使用来自开发者 IDE 的信息来添加上下文（包括当前选定的代码、当前和其他打开的文件、连接的存储库、对话历史记录、Git 历史记录、导入的库、项目元数据以及编译、语法和运行时错误）。您也可以在多个 IDE 和不同的源代码管理平台中使用它。
组织可以选择 Tabnine 使用哪个大型语言模型（GitHub Copilot 最近推出的一个选项）选项。这包括公司自己只使用许可的开源代码训练的模型。
Tabnine 总裁指出，所有这些都是企业表示关心的问题。“他们担心隐私，因为他们担心对他们系统的访问会被用来对付他们。或者至少，他们允许供应商窃取非常重要的客户和员工信息以及他们的代码，而当这种情况发生时，他们会失去对这些信息的控制。”
Gartner 在其《AI 代码助手关键能力》研究报告中指出：“业务利益相关者正在要求对 AI 代码助手的使用采取负责任的方法。”类似地，CIO 们在调查中表示，版权和许可证侵权是可能会阻止他们采用生成式 AI 代码助手，或者至少会让他们花钱保护自己免受索赔的担忧。但在实践中，这些良好的意图似乎让位于性能。
“当我们创建我们的 LLM 时，我们只使用许可的开源代码进行训练，”Guagenti 说。“我们知道我们正在做一些不如其他事情的事情，但我们认为这是我们为我们自己冠名的正确做法，我们可以通过私下访问客户的代码来弥补其能力上的差距。”
“每个人都认为 LLM 是王者，但他们并非如此。实际上，它们只是房子的地基。” — Tabnine 总裁
他声称，使用客户自己的代码库作为上下文以及用于微调模型，对于大型工程团队来说，可以有效提高性能。 “每个人都认为大型语言模型是王者，但事实并非如此。实际上，它们只是房子的地基。真正有价值的是AI代码助手，并非大型语言模型本身的功能，而是应用的上下文，”他说道。
提供开发者IDE中打开文件的代码库感知能力，将使程序员接受Tabnine助手建议的比率提高40%。他指出，客户通常因为隐私问题而关注Tabnine，但由于版权问题，受保护的模型往往是他们首先询问的内容。
“我们最新发布的受保护模型的性能与GPT 3.5一样好，即使它是在规模小得多的数据语料库上训练的，而且我们可以告诉你——这些数据都是允许的。”
但GitHub Copilot现在使用GPT 4（以及用于聊天和拉取请求摘要的GPT-4o）。“他们会比较Tabnine和受保护模型的性能与Claude或Command R+或其他一些非常强大的模型，这些模型都接受了他们可以抓取的所有数据的训练。”
Guagenti将受保护模型的性能描述为“十分之七”。“Claude和其他模型的得分可能是十分之八点五，如果你真的突破界限，也许是十分之九，但差异并不显著。”然而，即使是微小的性能差异，也往往比潜在的伦理问题更优先。“当他们看到差异时，我会告诉你，令人惊讶的是，许多人会说，‘啊，实际上，我们不再关心许可证合规性了。’”
他认为，这种实用主义（尤其是在组织部署了生成式AI编码工具后，这在LinearB的研究中也有体现）并非组织的过错，因为这些问题关乎社会认为什么是可以接受的，而IT团队则被要求以最经济的价格提供高生产力和高性能。
“内部选择和使用这些工具的动机与我们在谈论AI伦理时面临的挑战相冲突，这与之前出现的任何其他技术没有什么不同。”
RedMonk高级分析师Kate Holterhoff对此并不感到意外，这突显了需要了解这些工具如何影响开发人员的工作流程以及他们生成的代码。
“在代码助手方面，我们仍然处于‘往墙上扔意大利面条看看什么能粘住’的产品开发阶段。” —— RedMonk高级分析师 Kate Holterhoff
“AI代码助手供应商对开发者需求的预期与从业者实际使用的情况之间存在着真正的脱节，”她解释道。“在代码助手方面，我们仍然处于‘往墙上扔意大利面条看看什么能粘住’的产品开发阶段，这就是为什么关注例如在线论坛和会议走廊讨论中表达的真正开发者情绪如此重要的原因。”
使用一个更了解你自身代码库而不是其他人代码总和的AI代码助手，也存在其他悖论，因为你现有的代码可能无法帮助你获得想要的结果。组织希望使用自己的代码进行训练以获得最相关的建议，但这几乎肯定包括你不想复制的遗留编码实践，因此你必须选择代码库中符合你希望新代码工作方式的部分。
“[假设]我是一个组织，我有3000万行代码，”Tabnine的联合创始人兼首席技术官Eran Yahav假设道。“其中700万行是遗留代码，我不希望任何人看到。我不希望你连接到它，我不希望在它上面进行训练；我不希望[代码助手]知道它们的存在，除非也许作为一个反面例子。”
他警告说，对于大多数组织来说，遗留代码、过时库、废弃构件和已弃用的编码模式的例子可能比你希望助手建议的那种代码多得多。代码不仅比几代员工的寿命还长——“公司里没有人知道20年前的代码是做什么的”——而且无论是员工还是生成式AI盲目复制现有最多例子的代码，都很容易最终得到他所谓的“新的遗留代码”。
“新的遗留代码是指公司的新员工通过查看遗留代码并模仿其中的内容来创建新的遗留代码，”Yahav解释道。“架构师或开发工程师经理试图消除某些库、API或某些做事方式，但由于人们通过AI或搜索看到它反复出现并不断模仿，他们正在创建新的遗留代码。”
如果开发人员不知道该使用哪个版本的库（因为团队还没有策略或精选的构件存储库），他们很可能会选择已经在他们使用的其他代码中存在的那个版本，训练和微调AI模型也是如此。“如果你使用AI助手并将其连接到所有遗留信息，每当人们询问如何做某事时，他们总是得到旧的答案，因为旧答案的例子最多。除非你小心谨慎，否则很容易被这种遗留内容的巨大引力所吸引。”
即使这不会引入新版本构件中已修复的漏洞，也不会意味着你违反了编写原始代码时不存在的法规，你最终也可能会混合使用旧方法和新方法，得到与两者都不一致的结果。
新近性可以作为一个信号，但最安全的选择是使用开发团队已经熟悉的相对较新的代码进行训练并获得AI的帮助，这样他们就知道如何评估建议，然后转向他所说的“遗留代码和旧代码的不稳定领域”。
采用在你自己的代码上训练的AI助手，可以使对代码进行改进以使其成为更好的训练数据变得有价值，因为AI的投资回报率更明显（特别是如果你在Faros或LinearB等工具中跟踪完整的工程指标）。
一些Tabnine客户已经进行了重要的代码重构和大量文档工作，以使代码辅助工作更好。
“整理代码并非优先事项，但现在它融入另一个流程[AI助手]中，并变得更加重要。”
——Tabnine联合创始人兼CTO Eran Yahav
Yahav指出：“对AI有帮助的东西也对人类有帮助，所以这不仅仅是为Tabnine完成的工作，”“这是因为我们的介入，我们架起了一面镜子，反映了代码库的状态。”代码质量不仅仅意味着更少的错误：它还提高了开发人员的生产力，因为它更容易使用，但通常会优先考虑发布代码。
他明确表示，这并不是要批评现有的代码或编写这些代码的开发人员，而是关于优先级、截止日期和可用资源。“代码不干净的原因不是因为人们愚蠢或懒惰，而是因为他们必须交付它，而且它有效。整理代码并非优先事项，但现在它融入另一个流程中，并变得更加重要。”
文档是经常资源不足且通常过时的领域之一：开发人员可能会抱怨文档缺失，但它很少被视为优先事项，而且交付文档通常不会像编写代码或修复错误那样获得那么多认可。使用AI，你可以清楚地看到添加文档的价值。
Yahav说：“我看到人们正在添加关键组件的文档，而这些组件之前没有任何文档。”“这有助于AI，但也帮助任何冒险进入这个项目并试图理解正在发生的事情的人。通过添加这些文档，整个世界对[人类]来说变得更好，但这并不是动力。如果检索系统有额外的解释来解释正在发生的事情（这些事情无法从代码中推断出来，只有编写这段代码的人才知道），那么它就能更好地工作。”
文档需要解释特定设计选择的理由，而不是代码的功能。
这份文档需要解释特定设计选择的理由，而不是代码的功能。“AI知道代码的功能：但为什么做出这个设计决定是额外的信息，这有助于使用AI的人们全面了解这个东西是什么，或者为什么它看起来是这样的。”
文档中的信息变得更有价值，因为它可能会间接地在不同的上下文中出现，更多的人会发现它有用，而不仅仅是寻找如何做某事的开发者，Yahav建议道。
以JIRA（或任何工作管理系统）为例，其中的问题充当了将要完成工作的隐式合同。“人们在[JIRA]中编写的 issue 通常不是很详细。开发人员显然讨厌编写它们，产品经理也讨厌编写它们，这取决于组织的大小，因为它限定了功能，然后开发人员说，‘嘿，这比你在工单中告诉我的要多得多，我不做。’每个人都讨厌JIRA issue的这个合同。”
Tabnine可以自动生成与JIRA issue匹配的代码，例如故事、bug或任务（或验证代码是否实际捕获了issue中的需求，如果未捕获则建议改进代码），使用issue中的文本作为生成的代码的上下文。“这是开发人员第一次真正对issue拥有足够的信息以供AI使用感兴趣。工单中的信息越多，AI就能提供越多的帮助。”这改变了人们使用系统的方式，因为现在有一个明显的激励措施来确保其准确性和全面性。”
“这种‘issue到代码’的自动化并非试图取代开发人员，Guagenti很快指出，将其描述为适用于简单的用例，例如简单的React应用程序。“它不会给你带来DoorDash；它不会给你带来真正创新的东西。”
是的，AI代码助手已经能够在他所谓的适合的任务中提供“不可思议的”改进。“他们花费的时间是以前时间的20%；如果做得好的话，某些任务的自动化因素为80%，甚至90%。”但这并不意味着你需要的开发人员更少了；这意味着开发人员可以将时间花在更重要的事情上（并花时间学习如何充分利用他们使用的AI编码工具）。
Gartner从使用代码助手中识别出的好处与基本的生产力一样多地与开发者体验有关：减少任务切换并保持流程状态，通过帮助扩展单元测试覆盖率来提高代码质量和可维护性，编写更一致的代码注释和更清晰的pull request——这反过来可以减少技术债务，并让开发人员将更多时间花在高价值的工作上。
“任何认为软件开发人员会完全消失的人都在自欺欺人。”
——Guagenti
Guagenti建议，AI“只是提升了技能水平，使我们能够创建更大、更复杂、更有趣的应用程序。”最有效地利用AI代码助手的组织和团队将通过投资于他们的开发人员来做到这一点。“我们将期望他们更有创造力，更具创新性，更有能力，并且减少在hackery上的时间。”
“任何认为软件开发人员会完全消失的人都在自欺欺人。有很多事情我们可以完全自动化，但仍然有人必须设计系统。仍然有人必须将用户需求或业务需求转化为能够实际解决问题的方案的愿景。”