“AI 在一線：開發人員如何重塑軟件開發流程” ｜圓桌討論

作者 | Arthur Casals

譯者 | 劉雅夢

引言

從代碼生成到自動化文檔，人工智能已經開始滲透到軟件開發生命周期的幾乎每個階段。但除了炒作之外，實際上發生了什么變化？我們詢問了一群工程師、架構師和技術領導者，AI 輔助工具的興起如何重塑軟件開發的既定節奏，以及他們在現實世界中采用 AI 后學到了什么。

討論嘉賓

• Mariia Bulycheva——Intapp 高級機器學習工程師

• Phil Cal?ado——Outropy 首席執行官

• Andreas Kollegger——Neo4j 高級開發者倡導者

• May Walter——Hud.io 創始人、首席技術官

InfoQ：AI 輔助工具的興起對你們組織的軟件開發過程有何影響？它們是否改變了你們對軟件架構的思考方式？

Mariia Bulycheva：AI 輔助工具加速了原型設計，并減少了在重復編碼任務上花費的時間，使我們的團隊能夠更多地關注架構決策和設計復雜的在線實驗，這對于大規模迭代改進復雜的推薦系統至關重要。從數字平臺典型的大量多模態數據中獲得初步洞察也變得更快、更順暢、更一致，因為我們可以將初始數據分析委托給了 AI。

我們工作的另一個非常重要的方面是跟上我們領域科學發展的快速步伐。每年，在頂級會議上都會發表數千篇新的研究論文，過去閱讀它們并確定哪些可能與我們團隊的日常 ML 任務相關是非常耗時的。今天，AI 工具提供了高質量的摘要，甚至突出顯示哪些方法可能適用于我們的用例。這已經導致了幾個新建模想法的快速實現，否則我們可能需要花費數周甚至數月的時間來發現和測試。

Phil Cal?ado：絕對有。我們運行的是一個消費者參與平臺，其功能之多，任何正常人都無法全部記住。例如，最近，我們需要改變我們處理時區的調度方式。代碼變更本身可能只有 10 行，但真正的工作是深入數百個涉及調度的地方，弄清楚每個地方的假設，并添加單元測試以斷言調用站點不會中斷，而是行為的變化。我們原以為這將是一個為期六個月的項目，因為我們需要逐步研究并進行小的更改。

有了像 Cursor 和 Claude Code 這樣的工具，我們大大縮短了這個時間。它們幫助我們找出所有受影響的位置，為每個位置生成單元測試，并將推出分成按子系統分組的小 PR。每個 PR 都帶有對所屬團隊的上下文敏感的描述——不僅僅是“修復調度，請審查”，而是解釋為什么以及在他們的世界中預期的影響。

因此，盡管我們像其他人一樣看到了原始代碼輸出的增加，但在我們這樣成熟的、超大規模的系統中，最大的提升在于 AI 如何幫助我們研究自己的代碼庫，將無聊但必不可少的安全檢查整合在一起，使系統性變更變得不那么可怕。

Andreas Kollegger：在我們組織中，所有員工現在都可以使用 AI 輔助工具。對于表面層級的界面設計，這些工具幫助我們更快地迭代，探索新想法，并解鎖新方法，如氛圍編碼，專注于更高層次的設計和策略。

但我們也確實遇到了 AI 的局限性。像許多組織一樣，我們發現大語言模型（LLM）在需要深厚領域專業知識和全局架構整體視圖的高度專業化代碼上掙扎。我們的代碼庫本身就超過了任何 LLM 上下文窗口的容量，而這些模型本身也沒有在其中的獨特復雜性上進行訓練。簡而言之，AI 不能發明它不理解的東西。因此，我們有意采取了一種以人為中心的方法：雖然 AI 幫助我們加速和增強，但推動軟件架構突破的是我們工程師的專業知識。

May Walter：AI 輔助工具極大地縮短了從想法到工作代碼的路徑。一旦意圖明確，迭代周期就會顯著縮短。開發人員正在從代碼的唯一作者轉變為更像是管理者的角色——指導代理，驗證輸出，并確保需求得到真正滿足。

AI 之前，架構是關于團隊之間的所有權和可擴展接口。這引入了一個新的維度：上下文架構——設計代理生成生產就緒代碼所需的輸入、腳手架和護欄。上下文工程正在成為系統的核心部分，它簡化了在復雜環境中快速構建的能力，如分布式和基于事件的系統。

但速度帶來了一個新的瓶頸：為生產準備 AI 生成的變更。即使審查有了 AI 輔助，挑戰也不再是關于發現語法錯誤，而是在大型、大規模的系統中驗證意想不到的后果。

InfoQ：人工智能的采用如何影響團隊內部的入職流程？你們團隊或組織中的初級開發人員是否受到軟件開發過程中采用人工智能的影響？

Mariia Bulycheva：人工智能工具可以通過提供即時的代碼示例、文檔摘要和測試建議，顯著加快學習過程，這些都支持了初級開發人員。在處理個性化和推薦系統等復雜領域的團隊中，這一點尤其有用，因為現在初級人員可以更快地探索新的代碼庫，而不必總是依賴高級工程師。同時，我們將他們與更有經驗的同事配對，以確保他們學習潛在的基本建模和系統設計原則，而不僅僅是捷徑。

Phil Cal?ado：我們剛剛讓暑期實習生展示了他們的項目，幾乎每個人都把人工智能稱為救星。進入一個有 10 年歷史的 Rails 代碼庫，其中包含數千個可移動的部分，這是令人生畏的。但是能夠對 Cursor 或 Claude Code 說，“我是一名懂 Python 和 C++ 的大三學生，請用我熟悉的方式解釋這個 Rails 代碼”，這意味著他們可以在幾周內提高效率，而不是僅僅把時間花在弄清楚基礎知識上。

而且，不僅僅是實習生。在這個龐大的系統中，即使是高級工程師也需要比在小公司更多的準備時間。AI 并沒有消除對系統的實際理解，但它確實減輕了“我們在哪里處理認證？”或“我們是否已經有了觀察者模式的實現？”這類問題的壓力。

當然，這里有一個問題。生成式 AI 擅長復制模式，這通常意味著我們不希望再看到的遺留風格和架構。因此，我們不得不適應。我們正在使我們的工作流程和架構更加適應 AI，并且我們已經開始將當前的指導方針直接嵌入到 Claude Code 和 Cursor 的智能體中。這樣，當 AI 提供幫助時，它會引導人們走向現在，而不是過去。

Andreas Kollegger：人工智能的采用增強了我們的入職流程，特別是對于新接觸圖數據庫的初級開發人員。雖然人工智能不能取代經驗豐富的導師的指導，但它通過幫助新員工更快地上手，補充了我們現有的入職資源。

入職培訓不僅僅是教授編碼技能。它是關于建立領域專業知識的。編碼能力很重要，但更重要的是理解要編寫什么代碼以及為什么。這就是為什么我們的入職開發人員，他們對代碼庫及其架構有深入的了解，在向初級團隊成員傳授專業知識和上下文方面發揮著關鍵作用。

May Walter：人工智能降低了貢獻的障礙。現在，一個新開發人員可以在他們的第一天就寫出可用的代碼——這與早期工作僅限于樣板或錯誤修復的日子相比，是一個戲劇性的轉變。但真正的機會不在于速度；而是在于能力和范圍的深度。

我最常聽到的擔憂是，人工智能有使入職變得膚淺的風險——初級人員可以在不理解代碼為何以某種方式行為的情況下生成代碼。我的經驗恰恰相反。當代碼生成與運行時反饋配對時，初級開發人員從一開始就接觸到系統思維：架構在負載下的行為如何，依賴項如何相互作用，以及變化如何波及到業務結果。工程師成為智能體代碼生成過程中的業務大使。

他們不再需要花幾個月的時間來處理低價值的工作，而是能夠處理團隊的更多任務。如果做得好，這不會跳過步驟——它會加速步驟。有了正確的文化和期望設定，初級工程師可以更快地發展成為全面發展的工程師，因為他們不僅學習如何編寫代碼，還學習了為什么它在系統環境中很重要。

InfoQ：在你們團隊或組織中，你們是否測量過 AI 輔助開發對生產力或質量的影響？你們學到了什么？

Mariia Bulycheva：我們在樣板代碼和單元測試生成方面看到了明顯的生產力提升，甚至在為推薦系統設置模擬實驗方面也是如此。然而，當處理影響大規模客戶體驗的關鍵系統時，真正的好處來自于將 AI 輔助與深度工程師參與結合起來。我們了解到，雖然 AI 提高了生產力，但質量仍然取決于仔細驗證和清晰的指標和測試。

Phil Cal?ado：沒有正式的測量。坦率地說，我不相信大多數拋出的“生產力”數字。在軟件領域，你可以操縱指標，直到它們說出你想要的任何東西，而 AI 的炒作周期使這變得更糟。事實上，人們再次認真計算代碼行數，只是為了增加一輪融資或提高股價，這是令人尷尬的。

Andreas Kollegger：在前端方面，我們看到了生產力的提升，特別是對于那些使用 Cursor 等工具的工程師。我們的許多工程師已經使用 AI 支持來更快地理解、進行表面編碼和測試我們的代碼庫，但我們從 AI 中看到的真正影響是對開發人員體驗的影響。通過使用 AI 工具來支持他們的一些活動，我們的工程師現在有更多的時間發揮創造力，并最終改進他們解決問題的方式，并為他們的工作創造新的方法。

May Walter：是的，我們了解到的第一件事是，大多數常見的度量標準并沒有太大意義。公認的代碼行數、提交次數、PR：AI 可以立即夸大這些數字，但它們只是工程生產力的虛榮指標。

真正的信號存在于下游。發布穩定性、事故頻率、隨叫隨到的時間，甚至代碼變更率，都能告訴我們是否真的在加快速度，或者只是在制造更多的脆弱性。AI 將速度轉移到了管道的前端，但除非驗證循環緊密，否則債務會在后期顯現——以缺陷、回歸和精疲力竭的團隊的形式。

從第一天開始，通過持續的生產反饋，我們可以看到真相所在：功能開發變得更快，但審查周期變得更長了，部署后的錯誤也出現了。

教訓是，AI 生產力需要一個學習曲線和迭代方法。一旦度量，可以逐步改進采用，以捕捉優勢——同時避免因快速交付但存在穩定性問題窒息的陷阱。

InfoQ：為了有效地使用 AI 工具，你們的團隊或組織中有哪些非技術方面的東西需要改變？

Mariia Bulycheva：最大的變化是在心態上。團隊必須從期望 AI 建議是“正確”的，轉變為將它們視為需要徹底驗證、討論和測試的起點。這種文化轉變鼓勵了實驗和跨學科合作，將對確定性的關注轉變為對探索的關注。在大規模個性化工作中，我們還需要與產品和法律團隊就負責任的數據使用和可復制性達成一致。這些協議創造了護欄，使工程師能夠安全地探索和部署 AI 輔助解決方案。

Phil Calado：我認為關于生成式 AI 工具的最大事情是：這超越了編碼。是的，像任何其他工具一樣，你必須注意副作用。生成式 AI 可以很容易地生成內容：代碼、PR 評論、技術規范、電子郵件、Slack 消息。它也使得總結大量文本并過濾掉非必要的內容變得非常容易。

這兩個特性的結合創造了一個奇怪的激勵：人們生成了大量的低信噪比內容，然后其他人再次使用 AI 將其過濾回去。這是極其無效的。我們已經開始內部討論在制作內容時正確使用 AI 的方式。劇透：這不是讓 AI 為你寫作，而是使用 AI 幫助你寫得更好。

Andreas Kollegger：我們在 AI 的早期階段建立了一個 AI 倫理委員會，組織中的代表們更好地理解和指導 AI 如何影響我們的業務的每一個方面。所有技術都可以成為一股善的力量，但它也需要有意識的思考、行動和指導。

因為我們信任客戶數據，我們的開發人員需要在引入 AI 作為助手的任何領域都應用更高的敏感性，從簡單的計劃文件和電子郵件線程到代碼庫本身。隨著我們采用、集成和擴展 AI，我們所有的開發人員都必須確保人類判斷，而不是 AI，指導和監督每一步。

May Walter：最大的變化不是技術上的，而是文化上的。開發人員自然會單獨采用工具，但當 AI 被視為個人生產力技巧時，它的效果并不好。只有當它成為共享流程的一部分，有一致的驗證步驟和清晰的責任時，它才會有效。此外，AI 工具在缺乏上下文時不會失敗，而是產生不準確的回應，這可能會損害用戶的信任并增加變更的摩擦。

在 10 名工程師的情況下，每個人都可以以自己的方式進行實驗。在 100 名工程師的情況下，這種方法就會崩潰。不同的智能體獨立生成代碼會造成分裂和風險。我們轉向了共同的設置和共享的工作流程，這樣 AI 不僅僅是幫助個人更快地移動，而是使整個團隊更快地移動。

InfoQ：你們在管理 AI 輔助編碼方面設置了哪些護欄（文化、道德或技術），以及你們如何管理個人、團隊和組織對 AI 輸出的信任問題？

Mariia Bulycheva：我們將 AI 輸出視為重復性或樣板任務的“初稿代碼”，這些代碼總是經過單元測試和同行評審。在文化方面，我們強調責任：提交代碼的開發人員負責，無論是否有 AI 輔助。對于機器學習工作流程，我們不信任 AI 直接生成模型，相反，在任何模型更改甚至可以考慮用于生產之前，我們依賴于針對既定基線的自動離線評估。這確保了 AI 驅動的貢獻達到了與人類編寫的代碼相同的質量標準。

Phil Calado：這仍然是一個非常初級的實踐，所以我們一直在嘗試不同的護欄和工具。在安全和合規方面，我們的立場從一開始就很明確：作為一個處理世界上一些最大品牌數據的上市公司，我們必須將相同的治理實踐應用于 AI 編碼工具，就像我們其他地方所做的一樣。幾年前，這意味著落后于曲線，但今天大多數供應商都有堅實的企業計劃，所以我們可以安全地使用最先進的模型，而不會妥協安全性或可審計性。

文化上，我們很早就設定了期望：僅僅因為一個 AI 工具編寫了變更，并不意味著它不是你的代碼。你仍然擁有它，你需要把每一行都當作是你自己打出來的一樣。這與使用 IntelliJ 的提取方法重構沒有什么不同，在這種情況下，它可能自動化了機械操作，但你仍然需要理解并驗證結果。

Andreas Kollegger：大型企業軟件可以提供防止 AI 生成錯誤的保障，但更高的準確性、上下文和可追溯性是使 AI 輸出可解釋和可驗證的關鍵，而不僅僅是性能。這就是為什么我們引入了一個廣泛的測試計劃，涵蓋了從單個單元測試到詳盡的生產級驗證的所有內容。

與此同時，我們的工程師在紀律和創新之間保持平衡至關重要。我們鼓勵工程師嘗試各種想法，探索可能尚未準備好投入生產的項目。這種環境允許快速迭代和創造力，同時確保只有最有價值和經過充分測試的創新才能過渡到生產。其結果是一種獨特的平衡：保持客戶的信任和穩定，同時不斷推進圖驅動的創新，使 AI 更準確、透明和可解釋。

May Walter：我們必須贏得對 AI 輸出的信任，而獲得信任的唯一方法便是創造上下文。每個 AI 生成的變更都經歷了與人類編寫的代碼相同的標準——審查、測試、驗證——但有一個額外的要求：它必須在運行時證明自己。

對我們來說，信任不是來自對模型的信念；而是來自觀察代碼在現實世界條件下的行為。新版本的性能和舊版本一樣嗎？它是否引入了新的錯誤或在負載下改變了性能？當運行時上下文持續可用時，AI 就不再是黑盒。它變成了一個可以信任的伙伴，因為它與工程師依賴相同的信號進行推理。

InfoQ：你們認為軟件開發團隊低估了 AI 編碼工具的哪些方面？你們認為有哪些當前的 AI 增強型開發工作流程或模型被過度炒作，哪些仍然沒有得到充分利用？

Mariia Bulycheva：許多團隊低估了上下文管理的重要性，因為 AI 的效果取決于你提供的上下文（代碼庫、文檔、架構、在線測試的實驗設置）。在大型系統中，這意味著不僅要管理代碼片段，還要管理模型性能數據、日志和實驗歷史，以有效指導 AI 工具。過度炒作：AI 據說取代了工程判斷的“一鍵式開發”。未充分利用：AI 輔助調試、實驗設置和復雜 ML 工作流的文檔記錄，這可以大幅降低長期維護成本。

Phil Cal?ado：現在 AI 中有很多空洞的炒作，很難挑出一個罪魁禍首。但大多數團隊都低估了的這一點是：AI 編碼工具不是一個單程的魔法盒子。你不能只是向它們拋出一個提示，就期望得到一致、正確的結果。

這是任何真正構建 AI 產品的人都知道的痛苦教訓。無論你的提示工程有多聰明，有效使用 LLMs 來自于結合工作流程并確保正確的上下文在正確的時間可用。否則，你只是在擲骰子。

我在以前為一個流行的代碼審查工具構建 AI 管道時親眼目睹了這一點。模型可能已經記住了所有寫過的 Python 書籍，但如果你問 10 個開發人員“正確的方法”去做某事，你會得到 11 個答案。如果沒有你的代碼庫、組織標準和實際目標的上下文，LLM 就不知道哪個適用。這就是為什么你會得到完全不同的解決方案，甚至是對立的——這取決于當你提問時，概率之神想要傾向于哪一邊。

Andreas Kollegger：許多軟件開發團隊低估了 AI 編碼工具可以簡化開發人員最不喜歡的任務，比如編寫測試和文檔。雖然 AI 編碼演示承諾低代碼和無代碼，通常看起來微不足道或不可靠，但它們展示了 AI 如何將自然語言和代碼之間進行轉換，這對于自動化繁瑣的任務和重復的設置是理想的。類似地，有一種專門用于項目初始化和代碼生成的編碼工具。

有一種工作流程被夸大了，但卻沒有得到充分利用，那就是讓編碼智能體通宵運行，并在早上檢查他們的工作。我不建議在無人監督的情況下重構新產品功能或大量代碼，但編碼智能體非常適合一個定義良好的 GitHub 問題，它有良好的討論，一個孤立且可重現的例子，以及一個可測試的修復。

May Walter：大多數團隊低估的是，模型已經足夠好（并且正在變得更好）——缺失的成分是組織上下文。等待“更好的模型”是一種分心。真正的挑戰是設計提供生成生產級代碼所需的上下文的系統：你的架構、編碼標準、數據邊界和業務優先事項。如果沒有這些，即使是最好的模型（或工程師）也會表現不佳。

另一方面，今天被過度炒作的是原始代碼生成和靜態代碼審查。這些工作流程在演示中看起來令人印象深刻，但它們并沒有解決大型組織中軟件工程最難的部分：調試和質量保證。智能體仍然缺乏運行時上下文，并且很少有工具來評估哪些更改在業務影響方面真正關鍵。

這個差距很重要，因為更快的代碼生成意味著更多的更改流入生產環境——而且沒有更強大的流程來決定要監控什么，團隊冒著為了脆弱性而犧牲速度的風險。未充分利用的前沿不是更快地編寫代碼，而是構建驗證循環和運行時感知工具，以在這些更改部署之前增加確定性。

結論從這次討論中得出的第一個，也許是最重要的結論是，盡管在軟件開發過程中采用 AI 工具無疑降低了貢獻的門檻，但它仍然是一個乘數，而不是靈丹妙藥。只有與強大的組織環境相結合，AI 才能增強生產力。基于 AI 的工程有潛力成為軟件開發的核心，就像 CI/CD 管道曾經一樣。然而，架構、編碼標準和實驗腳手架是成功采用 AI 的支撐支柱。

與此同時，隨著 AI 工具的發展，組織中開發人員的角色也從代碼作者轉變為系統編排者。新采用的策劃、驗證和集成 AI 輸出的過程并沒有取代軟件工程這門手藝；相反，它增強了它。批判性思維和架構意識比以往任何時候都更重要。

當然，采用任何新技術都會帶來陷阱，對于 AI 和基于 AI 的工具也是如此。降低貢獻的進入門檻也意味著增加了淺薄理解和生產次品代碼的風險，這可能對初級開發人員的職業發展和整個組織產生負面影響。指導和運行時反饋是重要的護欄，以及文化和倫理保障：AI 輸出必須被視為初稿，人類必須對其負責。當涉及到 AI 時，信任不是授予的：它是一個過程，通過測試、同行評審、運行時驗證和透明度贏得。

成功的指標也必須重新思考，因為 AI 夸大了所有傳統的生產力指標。有意義的信號來得更晚：穩定性、變動、事件，以及有多少時間可以釋放給創造力和架構。將 AI 擴展視為一個協作過程，而不是個人生產力的提升，這需要協調的工作流程和對周圍流程的更高成熟度。

無論好壞，很明顯，AI 帶來的變化已經到來，正在重塑軟件開發的工藝。仍然有未被充分利用的方面，但上下文設計和運行時感知工具已經是下一個架構前沿。從長遠來看，AI 競賽的贏家將是那些將其整合到具有問責制、信任和能夠以負責任的方式共同發展的團隊級流程中的人。

https://www.infoq.com/articles/ai-developers-rewriting-software-process/

聲明：本文為 InfoQ 翻譯，未經許可禁止轉載。