在一次深入的寫程式過程中，你意識到自己想先讓 beta 測試者試用一些新功能。你請你的代理程式幫應用程式加上功能旗標（feature flagging）。它向你推薦 LaunchDarkly 的實驗功能解決方案，並提出一個看起來合理的實作計畫。你只是快速瀏覽了一下 Markdown 文件，就接受了它的建議，接著它開始寫程式碼。
這是一個很真實的情境，因為 Claude、ChatGPT 和 Gemini 都會推薦 LaunchDarkly。但當你把這些問題交給你的代理程式時，回應其實只來自一個只被詢問一次的模型。它和任何提示詞一樣，都會受到訓練偏誤與非決定性的影響。根據我的研究，工具推薦結果可能會有相當大的差異。
依賴項是如何被選擇的
不管它是不是公認的領導者，模型最喜歡的工具都會帶著同樣的自信出現，而你也會用同樣輕鬆的方式閱讀那份計畫，然後大概也會用同樣的心態回一句：「看起來合理。」
那就是一個依賴項決策。而這個決策大多已經交給你的代理程式了。
一方面，這是合理的。你相信那個代理程式能規劃並撰寫程式碼來打造你的應用程式，所以也合理地相信它在其他決策上同樣可靠。你也可以審查它寫出的程式碼，並提出替代方案。越來越多工程師會像快速看一眼實作文件那樣，草草檢查程式碼。
事實上，在 AI Engineer World’s Fair 上，有多場議程不是宣告程式碼審查已死，就是表明想要終結它。由於人工審查成了瓶頸，工程師們正朝向可被信任的自動化審查方案邁進。多陣列織都會需要一種強而有力的方法，也許要達到數學證明的層級，正如 Erik Meijer 可能會在他的主題演講中提到的。
許多依賴項也不只存在於你的程式碼庫裡，它們還有超出任何審查流程可完全看見範圍的生命週期。在這個現代時代之前，也就是大約短短兩年前，依賴項的採用並沒有那麼學術化地嚴謹。不過通常會有多雙眼睛一起看，決策也會花上明顯更長的時間。
在 2024 年之前，尋找新工具通常是從網路搜尋或傳訊息給協作者開始。你會研究替代方案、檢查維護問題，並仔細審視開源授權。可能會有 RFC，或至少有隊友先快速確認一下直覺。為專案挑選新工具時，背後會有對話與資料蒐集。
即使在 AI 代理程式幾乎寫完大部分程式碼的情況下，有些工程師或團隊仍可能採用較不自動化、但研究更充分的決策流程。不過，現代工具並不鼓勵這麼做。事實上的做法就是那個功能旗標的故事：問代理程式、拿到建議、然後開始開發。
頂尖模型如何排名開發工具
隨著越來越多工程師開始把研究工作交給代理程式，我一直在追蹤在常見類別中會推薦哪些工具，例如應用程式資料庫、託管代管主機服務，當然還有像 LaunchDarkly 這類實驗平台。我會在頂尖模型上多次執行同一組提示詞，並每月把結果公開發佈在 llmrank.fyi。
每個類別的排名都是最新 Claude、ChatGPT 和 Gemini 模型結果的平均值。雖然 LaunchDarkly 已連續三個月穩居 實驗平台排行榜第一名，但第二名和第三名每次都不同。當你看模型之間的差異時，變化更大。舉例來說，最新資料顯示 Gemini 和 Claude 都把 Split.io 排在第二，僅次於 LaunchDarkly；但 ChatGPT 完全沒有提到這個產品。如果你問你的代理程式多個功能旗標選項，結果會因為你使用的模型不同而不同。
模型之間有很多這類分歧。一個有趣的例子是，我問了「對開發者友善的 AWS 競爭對手」。ChatGPT 的回應中有 100% 都包含 Azure；Gemini 的任何答案都沒有把 Azure 列進去。陰謀論四起。
這些模型之間的差異很重要，因為這不只是一般的 AI 雜訊。我使用的方法代表的是推薦分布，而不是工程師從代理程式那裡偶爾得到的一次性結果。根據大約 50,000 次成對執行比較，三個模型在約 58% 的情況下共享相同的前三名分組（不論排序）。換句話說，它們一致的程度，只比至少有一方不同意稍微高一點。
這些分歧真正代表什麼
工程師對非決定性輸出並不陌生。兩次程式碼審查可能會給出稍微不同的回應。這是可預期的變化，即使是在同一個模型裡也是如此。依賴項推薦則更隱晦一些。它們會帶著權威性的計畫出現，而且在同一模型內相當一致。
Gemini 97% 的時間都會提供相同的第一名推薦。ChatGPT 和 Claude 也都在這個比例的一個百分點之內。它們都很一致，只是彼此之間常常不一致。至少，在你採用之前，值得再聽聽第二個模型的意見。
根據 Menlo Ventures 的報告，Claude 佔據約 54% 的企業 AI 市占率。它同時也是最常出現的離群值。Claude 最有可能給出與另外兩者不同的前三名。你的代理程式剛剛自信推薦的工具，可能正是第二個意見會提出反對的那一個。
採用模型所推薦的依賴項，成本通常只是一個按鈕點擊。但若你之後才後悔而要移除這個依賴項，工作量就大得多——即使你讓模型道歉並協助修正錯誤也是如此。可能已經有其他系統開始依賴這個工具所提供的能力，你也必須一併更新它們。這就是那 42% 的情況：如果當時有第二個意見，會把你帶往別的方向。
AI Engineer World’s Fair 的許多議程都把焦點放在模型之外。Harness engineering、context optimization 和 software factories 都是在改善工作流程，並產生更可預測的結果。依賴項是模型分歧最清楚顯現的地方之一，但大概不會是唯一一個。找出這些落差，並用這些新的工程學科把它們補起來。
不是每個工程團隊都會採用多模型方法。預設路徑仍會是大多數依賴項決策持續發生的地方。而這也正是開發者工具公司會不會出現的地方。如果你和產品或行銷團隊合作，這就是他們可能還不知道存在的資料缺口。
那個功能旗標決策，以及成千上萬個類似決策，無論你有沒有想過，都還是會被做出來。42% 的分歧數字會隨著模型趨同或分歧、以及市場變化而改變。唯一不變的是，決策總會落在某個地方：是交給你的代理程式、單一模型、子代理程式、模型路由演算法，還是某個有人參與的流程？這些方案都在 AI Engineer World’s Fair 上被倡議。最好的跡象就是，我們正在討論這件事。
原文出處：https://dev.to/dailycontext/coding-agents-play-favorites-with-your-dependencies-2dl6
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
