然而，技术债务可能会削弱企业长期创新的能力，因为在初始开发过程中采取的捷径很可能导致代码库变得复杂、缓慢，或者难以被开发人员理解，再加上过时的组件或框架，代码维护的难度会进一步加剧。

正如GenAI工具正在从根本上改变开发人员的编码方式一样，它们也被用于重构代码，这对IT部门如何应对技术债务产生了重大影响。

与我们交流过的开发人员表示，GenAI工具正在多个领域被用于对抗技术债务——有些规模较小且具有偶然性，有些则具有系统性且着眼于大局。一些开发人员对GenAI在控制技术债务方面的能力比其他人更为热衷，但几乎所有人都同意，人类短期内不会退出这一舞台。不过总体而言，AI的应用前景是充满希望的。

消除代码清理的繁琐工作

技术债务之所以持续存在，部分原因是清理它涉及令人厌烦的体力劳动，这正是那些有远见的开发人员正转向GenAI工具以在对抗技术债务时寻求帮助的任务。

增加晦涩代码的清晰度。老旧且文档不全的代码库在重构时尤为令人望而生畏，因为它们需要先被理解才能被梳理清楚。Credibly的首席数据与分析官Dan Yelle建议，“通过让GenAI进行代码审查并插入注释，使晦涩的程序对工程师来说更容易理解，从而增加代码库的透明度。”

嗅出“代码异味”。AI工具能够擅长发现那些技术上可行但设计糟糕且可能在未来引发问题的代码，这正是你需要消除以偿还技术债务的代码类型。

“在一个特别具有挑战性的实施项目中，我们面对的是一个被数百万行复杂代码和冗余模块所困扰的遗留系统，”UST的首席AI架构师Adnan Masood说。“手动修复将耗费大量资源，通过部署AI驱动的代码分析，我们系统地识别出了出现退化的模块，这些模块表现出代码异味、重复模式、过度依赖和架构脆弱性，从而能够精确地确定重构工作的优先级。”

增强的代码检查。“代码检查工具是纯粹的机械过程，它们会评估你的代码并标记出实例，例如代码中if/then/else分支过多，或者类或方法体过长，”Qwoted的CTO Kevin Trowbridge说。“修复这些问题需要大量工作，因此代码库中经常充斥着手动覆盖——代码中的注释如‘rubocop:disable’或‘rubocop:todo’，它们告诉检查器忽略这些问题。”

这些注释代表了技术债务的一种经典形式：开发人员在功能开发结束时意识到他们刚刚编写的代码最终需要深度重构。“这正是LLM(大型语言模型)能够大放异彩的地方，”Trowbridge说。“检查器通常可以配置为在代码中直接注释违规行为，并附上诸如rubocop:todo和具体问题描述的注释。然后，只需简单指示，如‘请解决rubocop:todos’，就可以将文件直接传递给LLM。”

追踪过时的依赖关系。有时，技术债务的产生并非因为你的代码糟糕，而是因为代码所依赖的库或框架发生了变化或变得不可靠。“AI编码助手能够识别代码库中所有库和依赖项的过时程度，”网络和移动开发公司Gnar的联合创始人Pete Whiting说。他指出，即使AI没有被专门指派去寻找技术债务，它也能识别出这些链接的问题：“当被提示进行一些改进请求(例如，提高性能、应用一致的模式或遵循最佳实践)时，AI编码助手也会突出显示代码库中的这些区域。”

更智能的测试能消除债务——希望是在债务产生之前

一些开发人员在将AI工具应用于技术债务任务时考虑得更为长远。以单元测试为例：它是产生高质量代码的重要工具，不会增加技术债务，但在急于交付最小可行产品的过程中往往被忽视，这意味着生产代码需要在后续的清理操作中编写测试——这是一项艰巨的任务，而GenAI工具可以加速这一过程。

“AI编码助手在为之前没有测试的现有功能添加测试覆盖方面非常有帮助。”Gnar的Whiting说。

当然，在技术债务方面，最好的预防是在一开始就避免它。Compai的CEO Justin Ramos表示，AI工具“在轻松创建单元测试方面非常有帮助，这可以防止技术债务的积累，这曾经是一项繁琐而有价值的任务，但像Claude这样的工具让这一过程变得更加容易。”

实际上，AI工具还可以帮助提高在以往难以进行测试的专门场景中的测试覆盖率。“由于ML/AI模型的输出具有不确定性，测试一直是一个挑战，这通常导致团队对复杂系统的测试不足，”Domino Data Lab的现场首席数据科学家Jarrod Vawdrey说。“AI正在改变这一现状，它能够自动生成全面的测试套件，考虑模型的概率行为，并在各种场景下验证输出。”

将债务转化为战略

许多公司开始将AI工具作为支持量化和纠正技术债务的基础设施生态系统。QueryPal的CEO兼创始人Dev Nag表示，AI不仅可以揭示代码异味，还可以创建整个仪表板，“展示热点区域、变更率、熵指标，甚至每个模块的预测变更成本，这使得技术债务对业务部门来说变得清晰可见。”

AI工具可以根据缺陷密度、频繁变更和依赖关系扩散等模式识别出有风险的组件——这些洞察允许团队规划他们的债务攻击策略。“如果你知道哪里出了问题并能迅速修复它，那么它并不可怕，这是战略性的，”Coder的CEO Rob Whiteley说。

Credibly的Yelle主张采用“框架驱动的方法”来攻击技术债务，该方法应包含代码复杂性和性能的定量定义。“GenAI可以用于提供如何定义复杂性的建议，”他说，“尽管企业领导者将拥有最相关的上下文来确定哪些指标最为重要。”但这些建议可以让团队从基于直觉的应急处理转向系统的修复。

“如果人们盲目地使用AI生成的代码，仅仅因为它有效，那么他们很快就会了解到他们一直想知道的关于技术债务的一切。”Fusion Collective的联合创始人兼CEO Yvette Schmitter说。

一旦框架到位，GenAI工具就可以自动化大部分清理过程。CGI的总监兼咨询专家Kevin Beaugrand描述了使用AI迁移遗留应用程序的情况，其中近70%的新代码被生成并重用。“同时，”他说，“我们观察到应用程序的整体技术债务显著减少——大约减少了50%。”

上下文至关重要——而AI没有

尽管AI工具在解决技术债务方面展现出巨大潜力，但我们交流过的大多数从业者都强调需要保持人类在循环中的参与。

“AI工具在指出看起来混乱、过于复杂或难以维护的代码方面相当擅长，”QueryPal的Nag说，“但它们难以理解为什么代码会变成那样，以及它是否真的是债务还是只是业务上下文的一个怪癖。在一个仓库中看起来冗余的循环可能在另一个仓库中是针对不可靠的供应商API的关键变通方法。”

问题是，“技术债务，从本质上讲，很少仅仅是结构性的——它是文化和上下文性的。”他说。

“AI看不到导致重写被推迟的内部政治因素，看不到迫使采取捷径的发布截止日期，也看不到使抽象变得不可能的脆弱伙伴系统合同，”Nag说。“没有这些背景故事——它们永远不在代码库中——AI无法判断是删除还是维护那段代码。没有这些上下文知识，AI无法可靠地确定是删除还是维护某些代码片段。”

然后还有这样一个问题：从一开始就在编码中使用AI是否只是简单地积累了更多的技术债务。UST的Masood称之为AI开发的“悖论性挑战”。“在没有适当治理框架的情况下，以前所未有的速度生成代码的能力可能会加剧架构不一致性，”他说。“这种紧张关系需要在严格开发实践内对AI能力进行复杂的协调。”

Fusion Collective的联合创始人兼CEO Yvette Schmitter说得更为直白。谈到没有AI防护栏的商店时，她说：“如果人们盲目地使用AI生成的代码，仅仅因为它有效，那么他们很快就会了解到他们一直想知道的关于技术债务的一切。你仍然需要一位有判断力的工程师来决定什么对你的企业是合适的，什么是不合适的。”

如何预防明天的技术债务

尽管如此，与我们交流过的所有人都看到了AI在处理技术债务方面的作用。如果使用得当——这是一个重要的前提——AI可以提供前瞻性的指导，在技术债务产生之前就将其扼杀在萌芽状态。“AI框架现在能够以惊人的准确性预测债务积累轨迹。”UST的Masood说。

这些预测模型允许团队将实时债务评估嵌入到代码审查中——在问题扩大之前就将其捕获。正如Coder的Whiteley所说，这些预测“将技术债务从年度消防演习转变为持续可见的待办事项，工程领导者可以据此确定优先级。”

更快、更高效地减少技术债务意味着开发人员可以做更多他们更愿意做的事情。“有很多关于自主AI取代开发人员的讨论，”Whiteley说。“但实际上，它解放了开发人员，让他们能够专注于创造价值，而不是偿还技术债务。”

企业网D1net(www.d1net.com)：

国内主流的to B IT门户，旗下运营国内最大的甲方CIO专家库和智力输出及社交平台-信众智(www.cioall.com)。旗下运营19个IT行业公众号(微信搜索D1net即可关注)。

版权声明：本文为企业网D1Net编译，转载需在文章开头注明出处为：企业网D1Net，如果不注明出处，企业网D1Net将保留追究其法律责任的权利。