IT領導者們深知他們最終必須解決技術債務問題，但由于解決技術債務并不總能直接帶來收入增加或新功能的實現，因此很難讓企業管理層認真對待這一問題。

然而，技術債務可能會削弱企業長期創新的能力，因為在初始開發過程中采取的捷徑很可能導致代碼庫變得復雜、緩慢，或者難以被開發人員理解，再加上過時的組件或框架，代碼維護的難度會進一步加劇。

正如GenAI工具正在從根本上改變開發人員的編碼方式一樣，它們也被用于重構代碼，這對IT部門如何應對技術債務產生了重大影響。

與我們交流過的開發人員表示，GenAI工具正在多個領域被用于對抗技術債務——有些規模較小且具有偶然性，有些則具有系統性且著眼于大局。一些開發人員對GenAI在控制技術債務方面的能力比其他人更為熱衷，但幾乎所有人都同意，人類短期內不會退出這一舞臺。不過總體而言，AI的應用前景是充滿希望的。

消除代碼清理的繁瑣工作

技術債務之所以持續存在，部分原因是清理它涉及令人厭煩的體力勞動，這正是那些有遠見的開發人員正轉向GenAI工具以在對抗技術債務時尋求幫助的任務。

增加晦澀代碼的清晰度。老舊且文檔不全的代碼庫在重構時尤為令人望而生畏，因為它們需要先被理解才能被梳理清楚。Credibly的首席數據與分析官Dan Yelle建議，“通過讓GenAI進行代碼審查并插入注釋，使晦澀的程序對工程師來說更容易理解，從而增加代碼庫的透明度。”

嗅出“代碼異味”。AI工具能夠擅長發現那些技術上可行但設計糟糕且可能在未來引發問題的代碼，這正是你需要消除以償還技術債務的代碼類型。

“在一個特別具有挑戰性的實施項目中，我們面對的是一個被數百萬行復雜代碼和冗余模塊所困擾的遺留系統，”UST的首席AI架構師Adnan Masood說?！笆謩有迯蛯⒑馁M大量資源，通過部署AI驅動的代碼分析，我們系統地識別出了出現退化的模塊，這些模塊表現出代碼異味、重復模式、過度依賴和架構脆弱性，從而能夠精確地確定重構工作的優先級?！?/p>

增強的代碼檢查?！按a檢查工具是純粹的機械過程，它們會評估你的代碼并標記出實例，例如代碼中if/then/else分支過多，或者類或方法體過長，”Qwoted的CTO Kevin Trowbridge說。“修復這些問題需要大量工作，因此代碼庫中經常充斥著手動覆蓋——代碼中的注釋如‘rubocop:disable’或‘rubocop:todo’，它們告訴檢查器忽略這些問題?！?/p>

這些注釋代表了技術債務的一種經典形式：開發人員在功能開發結束時意識到他們剛剛編寫的代碼最終需要深度重構?！斑@正是LLM(大型語言模型)能夠大放異彩的地方，”Trowbridge說。“檢查器通常可以配置為在代碼中直接注釋違規行為，并附上諸如rubocop:todo和具體問題描述的注釋。然后，只需簡單指示，如‘請解決rubocop:todos’，就可以將文件直接傳遞給LLM?！?/p>

追蹤過時的依賴關系。有時，技術債務的產生并非因為你的代碼糟糕，而是因為代碼所依賴的庫或框架發生了變化或變得不可靠?！癆I編碼助手能夠識別代碼庫中所有庫和依賴項的過時程度，”網絡和移動開發公司Gnar的聯合創始人Pete Whiting說。他指出，即使AI沒有被專門指派去尋找技術債務，它也能識別出這些鏈接的問題：“當被提示進行一些改進請求(例如，提高性能、應用一致的模式或遵循最佳實踐)時，AI編碼助手也會突出顯示代碼庫中的這些區域。”

更智能的測試能消除債務——希望是在債務產生之前

一些開發人員在將AI工具應用于技術債務任務時考慮得更為長遠。以單元測試為例：它是產生高質量代碼的重要工具，不會增加技術債務，但在急于交付最小可行產品的過程中往往被忽視，這意味著生產代碼需要在后續的清理操作中編寫測試——這是一項艱巨的任務，而GenAI工具可以加速這一過程。

“AI編碼助手在為之前沒有測試的現有功能添加測試覆蓋方面非常有幫助。”Gnar的Whiting說。

當然，在技術債務方面，最好的預防是在一開始就避免它。Compai的CEO Justin Ramos表示，AI工具“在輕松創建單元測試方面非常有幫助，這可以防止技術債務的積累，這曾經是一項繁瑣而有價值的任務，但像Claude這樣的工具讓這一過程變得更加容易?！?/p>

實際上，AI工具還可以幫助提高在以往難以進行測試的專門場景中的測試覆蓋率。“由于ML/AI模型的輸出具有不確定性，測試一直是一個挑戰，這通常導致團隊對復雜系統的測試不足，”Domino Data Lab的現場首席數據科學家Jarrod Vawdrey說?！癆I正在改變這一現狀，它能夠自動生成全面的測試套件，考慮模型的概率行為，并在各種場景下驗證輸出?！?/p>

將債務轉化為戰略

許多公司開始將AI工具作為支持量化和糾正技術債務的基礎設施生態系統。QueryPal的CEO兼創始人Dev Nag表示，AI不僅可以揭示代碼異味，還可以創建整個儀表板，“展示熱點區域、變更率、熵指標，甚至每個模塊的預測變更成本，這使得技術債務對業務部門來說變得清晰可見?！?/p>

AI工具可以根據缺陷密度、頻繁變更和依賴關系擴散等模式識別出有風險的組件——這些洞察允許團隊規劃他們的債務攻擊策略?！叭绻阒滥睦锍隽藛栴}并能迅速修復它，那么它并不可怕，這是戰略性的，”Coder的CEO Rob Whiteley說。

Credibly的Yelle主張采用“框架驅動的方法”來攻擊技術債務，該方法應包含代碼復雜性和性能的定量定義?！癎enAI可以用于提供如何定義復雜性的建議，”他說，“盡管企業領導者將擁有最相關的上下文來確定哪些指標最為重要?！钡@些建議可以讓團隊從基于直覺的應急處理轉向系統的修復。

“如果人們盲目地使用AI生成的代碼，僅僅因為它有效，那么他們很快就會了解到他們一直想知道的關于技術債務的一切?！盕usion Collective的聯合創始人兼CEO Yvette Schmitter說。

一旦框架到位，GenAI工具就可以自動化大部分清理過程。CGI的總監兼咨詢專家Kevin Beaugrand描述了使用AI遷移遺留應用程序的情況，其中近70%的新代碼被生成并重用?！巴瑫r，”他說，“我們觀察到應用程序的整體技術債務顯著減少——大約減少了50%?！?/p>

上下文至關重要——而AI沒有

盡管AI工具在解決技術債務方面展現出巨大潛力，但我們交流過的大多數從業者都強調需要保持人類在循環中的參與。

“AI工具在指出看起來混亂、過于復雜或難以維護的代碼方面相當擅長，”QueryPal的Nag說，“但它們難以理解為什么代碼會變成那樣，以及它是否真的是債務還是只是業務上下文的一個怪癖。在一個倉庫中看起來冗余的循環可能在另一個倉庫中是針對不可靠的供應商API的關鍵變通方法?！?/p>

問題是，“技術債務，從本質上講，很少僅僅是結構性的——它是文化和上下文性的?！彼f。

“AI看不到導致重寫被推遲的內部政治因素，看不到迫使采取捷徑的發布截止日期，也看不到使抽象變得不可能的脆弱伙伴系統合同，”Nag說。“沒有這些背景故事——它們永遠不在代碼庫中——AI無法判斷是刪除還是維護那段代碼。沒有這些上下文知識，AI無法可靠地確定是刪除還是維護某些代碼片段。”

然后還有這樣一個問題：從一開始就在編碼中使用AI是否只是簡單地積累了更多的技術債務。UST的Masood稱之為AI開發的“悖論性挑戰”。“在沒有適當治理框架的情況下，以前所未有的速度生成代碼的能力可能會加劇架構不一致性，”他說?！斑@種緊張關系需要在嚴格開發實踐內對AI能力進行復雜的協調?！?/p>

Fusion Collective的聯合創始人兼CEO Yvette Schmitter說得更為直白。談到沒有AI防護欄的商店時，她說：“如果人們盲目地使用AI生成的代碼，僅僅因為它有效，那么他們很快就會了解到他們一直想知道的關于技術債務的一切。你仍然需要一位有判斷力的工程師來決定什么對你的企業是合適的，什么是不合適的。”

如何預防明天的技術債務

盡管如此，與我們交流過的所有人都看到了AI在處理技術債務方面的作用。如果使用得當——這是一個重要的前提——AI可以提供前瞻性的指導，在技術債務產生之前就將其扼殺在萌芽狀態。“AI框架現在能夠以驚人的準確性預測債務積累軌跡?！盪ST的Masood說。

這些預測模型允許團隊將實時債務評估嵌入到代碼審查中——在問題擴大之前就將其捕獲。正如Coder的Whiteley所說，這些預測“將技術債務從年度消防演習轉變為持續可見的待辦事項，工程領導者可以據此確定優先級?！?/p>

更快、更高效地減少技術債務意味著開發人員可以做更多他們更愿意做的事情?！坝泻芏嚓P于自主AI取代開發人員的討論，”Whiteley說?！暗珜嶋H上，它解放了開發人員，讓他們能夠專注于創造價值，而不是償還技術債務?！?/p>