將AI集成到應用開發中的核心挑戰，不在于其協助能力，而在于我們能在多大程度上放心地將控制權委托給它。

盡管AI智能體可以完美地執行那些曾被認為人類專屬的任務，但它們同樣可能在緊接著的下一段代碼中犯下令人震驚的錯誤。

這些錯誤尖銳地提醒我們，即使是最先進的AI編程助手，仍然缺乏對世界運行方式的理解。這一根本區別將當前的生成式AI與通用人工智能（AGI）的愿景區分開來。考慮到這一點，讓我們來看看AI智能體如何成為出色的開發加速器，卻無法取代人類開發者。

LLM的推理并非邏輯推理

即使是復雜的智能體AI——構建于擁有日益龐大的上下文窗口和復雜工作流程的大型語言模型（LLM）之上——也依賴于語義模式匹配。它們無法對底層的因果關系和相互依賴提供真正的洞見。

讓人類難以理解這一點的是，LLM在闡述其決策過程時具有令人信服的方式，常常模仿一種邏輯遞進，暗示其對因果關系的理解，而實際上它們并不具備這種理解。它們通過拼湊統計上可能性高的人類推理文本片段來實現這一點。雖然這看起來像是邏輯推理，但它基于從訓練數據中得出的概率計算，而非對步驟之間因果關系的直接理解。

LLM模仿邏輯推理，但無法掌握因果關系。

將這比作一位主演醫療電視劇的演員，他多年來記住了數千小時的對話、紀錄片和真實咨詢記錄。他可以完美地進行鑒別診斷，像經驗豐富的醫生一樣自信地用專業詞匯滔滔不絕地說出癥狀、檢測結果和治療方案。他知道"向左臂放射的胸痛"通常出現在關于心臟病的場景中，"全血細胞計數和代謝指標組"跟在"我們來做些檢查"之后，而擔憂的表情伴隨著關于腫瘤的討論。

一位對醫療話題表現出表面理解的醫療劇演員，是比喻AI無法掌握因果關系的絕佳例子。

他們的表演如此令人信服，以至于任何觀眾都會相信他們懂醫。但他們根本不知道阿司匹林為什么能稀釋血液，心臟病發作時會發生什么，或者為什么一種治療有效而另一種會致命。他們只是在背誦他們記住的各種醫療對話的變體，拼湊那些在統計上共同出現的片段，卻不理解這些模式代表了真實的生物過程，其中順序和因果關系 literally 意味著生與死。翻譯到應用開發中，這通常意味著出色的結果之后緊接著災難性的失敗，反之亦然。

統計模式而非因果真相

LLM非常擅長在難以想象的大量文本中尋找并連接模式。盡管這些文本中有許多描述了世界的運作方式，但LLM并不理解這些描述的實際含義。相反，它將文本轉換成數字——向量——這些數字捕獲的是統計關系，而非因果真相。然后，模型將這些數字翻譯回人類語言，而在這一切之下，它始終只是在跟蹤和 shuffling 數字，而不是意義。例如，"charge"、"payment"和"credit card"這些詞可能在向量空間中位置接近，因為它們經常在文本中共同出現，而"profile"、"lookup"和"fetch"則形成另一個集群——但模型實際上并不知道一組涉及金錢，而另一組不涉及。

LLM只處理詞組之間的統計關系。

事物并非表面所見

由于編程語言是高度結構化的，這種數值上的 shuffling 可以產生優秀的代碼。雖然AI模型并不像開發者那樣"理解"代碼，但它可以可靠地將輸入模式映射到輸出，將框架映射到樣板代碼，將語法映射到語義，其方式常?？雌饋砼c人類代碼無異。例如，當被要求"用Python和Flask構建一個REST API"時，模型無法推理HTTP或數據庫——它只是回憶起@app.route通常出現在函數定義之前，GET請求常常映射到返回jsonify，而錯誤處理經常涉及try/except塊。結果往往是結構良好的Flask代碼，即使它源于模式回憶而非真正的理解。

人類需要保持在循環中，以應對AI缺失的上下文和推理能力。

例如，為重試邏輯加固微服務聽起來很簡單——然而實際情況并非如此。要求AI助手"在失敗時添加重試"，你可能會得到一段在任何錯誤時都重試所有操作的代碼。這對于冪等的（或無狀態的）讀取操作（例如"獲取配置文件"）來說沒問題，因為重復調用只會返回相同的數據。
將相同的邏輯應用于非冪等操作——扣款、創建訂單、發送電子郵件、查詢數據庫——你就會招致災難：重復扣款、重復訂單、通知風暴、數據庫中的重復記錄。解決方法并非魔術，而是判斷力。人類首先對操作進行分類——冪等與非冪等——僅在瞬態錯誤時重試，并且對于任何有副作用的操作，都需要冪等性密鑰和服務端去重。雖然這仍然為人類開發者節省大量時間，但他們仍然需要將其技能和專業知知融入其中，否則災難可能并且將會隨機發生。

理解模式匹配的局限性很棘手

原則上，模式匹配難道不能識別出對信用卡扣款需要采用與檢索客戶資料或產品信息不同的API調用重試方法嗎？是的，它可以，但人類無法事先知道這一點，因為這取決于該特定模型的訓練數據是否包含了執行標準POST或GET請求的重試函數。
模型未能建立操作類型與其現實后果之間的聯系；它僅僅回憶統計關聯。為了讓模型避免這個錯誤，訓練數據需要包含清晰、一致且重復出現的配對，將操作類型與重試策略及其后果聯系起來。
理想情況下，數據會明確對比可以安全重試的代碼與必須避免重試的代碼?；蛟S它還包括了事后分析或警告，描述了誤用重試時發生的情況。然而，模型是否攝入了足夠的訓練數據來做出這種區分，我們人類無法確定。更棘手的是，由于其概率性質，模型可能在某一次做出了區分，但在接下來的三次嘗試中卻沒有。
這個例子說明了為什么簡單地添加更多訓練數據通常不是答案，因為必要的數據可能并不以書面形式存在。或者更糟的是，訓練數據可能包含了強化錯誤概括的內容。無論哪種情況，人類用戶都無法知道是否如此，并且需要全面理解特定問題應如何解決。

AI的價值是真實的，開發團隊可以受益

只要清楚地理解其局限性，AI智能體可以顯著提高人類開發者在整個開發生命周期中的生產力。從收集需求并將其轉化為用戶故事，一直到檢測并部署應用程序，AI智能體可以為人類提供建議、自動化驗證和快速原型設計，從而顯著縮短迭代周期。
AI智能體應被視為力量倍增器，可以處理開發的機械性方面，例如基于現有示例和文檔生成樣板代碼、編寫測試用例和記錄API。另一方面，人類則負責真正理解業務影響、決定架構權衡，以及解決需要應用抽象邏輯能力的復雜問題。

AI對SDLC的生產力影響

下表分析了AI對軟件開發生命周期（SDLC）中不同活動的生產力影響，以及AI對每項活動的能力、所需的人力參與程度和每項活動的風險水平。

AI對SDLC活動的生產力影響

來源：Torsten Volk, Omdia ? 獲取數據 ? 使用 Datawrapper 創建

結論

宣布AI智能體正在接管開發者工作的技術領導者們，對AI當前能力產生了不切實際的期望。這導致許多企業高管認為開發者工時不再是他們所能構建內容的限制因素。金融分析師可以創建自己的投資組合再平衡工具；醫療保健管理員可以構建患者排班系統；供應鏈經理可以開發庫存優化儀表板；或者營銷總監可以構建個性化的活動自動化平臺，而無需編寫一行代碼。雖然他們可以為許多此類業務任務實現概念驗證，但架構、開發和交付企業級軟件仍然極大地依賴于人類開發者的技能和經驗。
然而，AI智能體可以通過為人類開發者完成大量基礎性工作來顯著加速SDLC。創建測試用例、用監控代理自動檢測復雜軟件、記錄數萬行主機代碼以及精確定義復雜的基礎設施清單，僅僅是AI智能體可以幫助人類開發者的幾個例子。
人類與AI智能體之間的SDLC必須是協作的、迭代的并接受持續監督。確定如何最優地調整流程、開發工具和企業文化以滿足這些要求，是智能體輔助應用開發的下一個前沿領域。弄清楚如何為人類編碼者提供最佳AI支持，其回報有望帶來顯著的生產力提升，使人類開發團隊能夠更快、更高質量地交付更多功能。

[注]本文譯自: AI agents are accelerators, not developer replacements