AI News HubLIVE
站内改写4 分鐘閱讀

前沿團隊如何重塑AI原生開發

前沿團隊不僅利用AI加速編碼,更從根本上重新設計軟體構建方式,實現了4.5倍乃至超過10倍的生產力提升。本文透過亞馬遜Bedrock、Prime Video等團隊的案例,揭示了成為前沿團隊的五個關鍵實踐,並指出工作流程的變革比工具本身更重要。

來源AWS Machine Learning Blog作者: Swami Sivasubramanian

前沿團隊不僅僅是將AI用於更快地編寫程式碼。他們正在重新設計軟體的構建方式。結果是4.5倍的生產力提升,某些情況下甚至超過10倍。

六名工程師。七十六天。一個原本計劃由30名開發人員耗時12到18個月的專案,在一個季度內交付。這並非假設。這是亞馬遜Bedrock團隊在停止將AI視為編碼捷徑、轉而將其作為工作基礎後所發生的事。該團隊在五個月內投入生產的程式碼量超過了前十年。

像這樣的團隊與其他團隊之間的差距正在迅速拉大。AI編碼代理從根本上改變了軟體編寫的速率,但並未改變其交付給客戶的速率。提交量激增,CI/CD管道比以往更加繁忙。然而,投入生產的功能並未保持同樣的速度。瓶頸不在於代理生成輸出的能力,而在於代理獲取做出正確決策所需知識的渠道,以及團隊圍繞這一現實重組工作的意願。

我們將這些已經找到解決方案的團隊稱為“前沿團隊”。他們並不侷限於精英實驗室,而是遍佈各行各業和公司規模。他們有一個共同的原則:將AI採用視為一項工程投資,而不是工具部署。任何工程團隊都可以成為前沿團隊。

亞馬遜實現AI原生開發的三條路徑

AI原生軟體開發將AI視為軟體構建的基礎,由人類專家指導能力不斷增強的代理。團隊如何指導這些代理決定了結果。在亞馬遜,AI在開發中的主要驅動力是減少開發人員花在文件、協調和運維等非編碼任務上的時間,消除技術債務,並最小化數千個小型“兩個披薩”團隊之間的編碼不一致性。我們已在數百個工程團隊中進行了實驗,並確定了至少三條路徑:由專家挑戰難題的探路者計劃、執行明確計劃的結構化衝刺,以及在現有方法與AI適應工作流程之間將團隊一分為二的原位實驗。這些路徑結構不同,但都指向同一個洞察。

探路者計劃是一項對照實驗。六名高階工程師接到單一任務:重建亞馬遜Bedrock推理引擎,該專案最初估計需要30名開發人員工作12到18個月。團隊並未增加人員,而是在最初幾周圍繞AI重新設計工作流程,從離散任務轉向目標導向的結果,並行執行多個代理,並建立系統讓AI在非工作時間獨立工作。該專案在76天內交付。以標準化提交速度衡量,單個開發人員的生產力提高了約20倍。提交次數從每週2次增加到40次。該團隊在五個月內投入生產的高質量程式碼超過了前十年的專案總和。

結構化衝刺採取了不同的方法。Prime Video財務系統團隊進行了一次為期10天的實驗,靈感來自探路者模式。六名工程師,一個房間,零上下文切換,無待命職責,無其他專案,有限的會議。一名高階工程師提前三週將複雜性分解為範圍明確的任務,並附有詳細需求。團隊對複雜功能工作採用規範驅動開發,對需求明確的任務直接採用代理輔助開發。10天內,他們產生了556次提交(基準為96次),並將90周的專案估計縮短至24周。這相當於近6倍的吞吐量和4倍的加速。他們將AI帶來的收益歸因於三個因素的倍增:低判斷力工作的加速(1.5倍)、高判斷力工作的專注(1.5倍)以及即時獲取代理捕獲的領域專業知識(1.5倍)。移除任何一個因素,收益就會消失。該團隊現在正尋求在日常運營中最佳化這三個因素。

在原位實驗中,在所研究的50多個團隊中,實施新工具和新實踐的25個團隊優於那些僅僅在現有工作流程中新增AI的團隊。亞馬遜商店以典型開發團隊為物件,針對其常規積壓工作進行了結構化試點,使用了Kiro和專用AI工具,沒有特殊條件,也沒有挑選工程師。中位生產力提升為4.5倍,部分團隊在標準化部署速度上實現了超過10倍的改進。Perfect Order Experience現在可以在一個下午內交付功能,而不是兩週。WW Grocery將設計文件建立時間從五天縮短至幾個小時。

不同的路徑,同樣的教訓:工作流程至關重要,而不僅僅是工具。

成為前沿團隊的五個步驟

在所有三條路徑中,表現最好的團隊共享五個實踐,且具有共同邏輯:減少代理獲取上下文的障礙,增加其獨立完成工作的表面積。

前沿團隊與以往習慣的分歧在於此。傳統方法最佳化的是個體程式碼生成的速度。前沿團隊則最佳化不同的事物:正確、可投產的軟體交付給客戶的速度。這一區別驅動著以下每一個實踐。

投資於代理上下文。最先進的團隊大力投入,透過代理引導檔案和關於團隊慣例、編碼標準、測試和程式碼庫導航的指南,使專案和知識更易於代理消費。Bedrock基礎設施團隊將所有程式碼和文件放入單一程式碼庫,並保留AI生成的線上註釋,將其視為持久記憶。跳過此步驟的團隊會疑惑為什麼代理不斷重複同樣的錯誤。

放慢速度以加速。上述實踐需要時間,要求團隊有耐心。每個高績效團隊都報告說,隨著他們學習模型,事情最初會放慢。他們將跨職能專業知識編碼到可重用的引導文件中,重組倉庫以便LLM能夠推理,併為AI消費新增註釋和重構程式碼分割。那些挺過學習曲線並首先定義預期結果的團隊經歷了複合加速。那些期望立竿見影而不改變工作流程的團隊則感到失望。預計前兩週會感覺較慢。之後幾週會感覺快得多。在第二週放棄的團隊永遠看不到複合效應。

餵養代理而非監控。前沿團隊維護一個穩定的、範圍明確的任務積壓,具有清晰的結果,並行執行多個代理,並非同步審查輸出。構建者報告說,在短時間內完成主要功能,即使他們沒有主動等待代理完成任務,工作也在推進。一位首席工程師僅用“幾個小時的連續時間”就完成了一個完整的更改,因為代理在工程師處理程式碼審查、運維支援和會議時工作。

在編寫程式碼前明確意圖。無論是透過結構化規範、詳細的需求文件,還是範圍明確的任務分解,前沿團隊確保代理在開始生成程式碼之前對“完成”的樣子有清晰的上下文。一些採用此方法的團隊報告說,他們隻手寫了1-2%的程式碼,同時每人每週的提交量比以前顯著增加。

“左移測試”。前沿團隊構建工具,使代理能夠在程式碼進入管道之前本地執行所有整合測試並自我糾正。Prime Video團隊投資於自動化防護欄、元件測試、效能測試和格式化工具,及早發現問題。程式碼審查的重點轉向介面定義和架構決策,而不是程式碼風格和命名約定。

技術領導者今天可以做什麼

並非每個團隊都能取得這些成果。跳過上下文構建階段、將AI視為替代品、或期望不重組工作就能立竿見影的團隊,表現始終不佳。整個行業的開發人員都採用了AI編碼工具,但並非所有人都看到了生產收益。他們使用的工具沒錯,但工作流程不對。

關鍵要點:

改變工作方式,讓AI發揮最佳效果。

三個因素倍增帶來成果:AI處理低判斷力工作、不間斷專注於高判斷力工作、即時獲取領域專業知識。

先試點,再推廣。

實際的起點不是廣泛部署,而是深思熟慮的試點。從一個小團隊開始,願意花最初幾周構建代理上下文(引導檔案、規範模板、單一程式碼庫),然後再編寫生產程式碼。給團隊重組工作流程的授權。衡量提交速度、部署頻率和解決時間,以及開發者滿意度分數。然後利用所學為組織其他部分制定手冊。

實現4.5倍到10倍以上生產力提升的團隊不僅僅是採用了更好的技術。他們學會了以不同的方式與之協作。這一決定今天對每個工程組織都可用。當然,程式碼提交速度只是故事的一部分。我們希望在軟體開發生命週期的所有方面提供幫助,無論是簡化釋出管理、運維和安全操作,還是處理EOL升級和軟體工程中無數無差異的任務。請關注下一篇部落格,我將介紹我們如何應對這些挑戰。

瞭解更多關於前沿團隊的資訊 >

收聽AWS紐約峰會,瞭解更多關於AI原生開發的內容。