軟體工程師的工作不僅僅是寫程式碼。AI 面臨著一系列的挑戰，比如深入洞察人類以及開展協作。人類在面對復雜的非線性問題時能夠深入思考，而 AI 這方面的能力很欠缺。AI 難以理解人類設計師考慮的情感共鳴和語境是否合適等問題。此外，準確地預測使用者需求需要一定程度的直覺和適應能力，在沒有人類協助的情況下，AI 尚未能掌握這些能力。
原文連結：https://www.htormey.org/can-you-replace-your-software-engineers-with-ai/
未經允許，禁止轉載！
作者 | Harry Tormey 譯者 | 彎月
責編 | 夏萌
出品 | CSDN（ID：CSDNnews）
答案是否定的。在可預見的未來，人工智慧並不能取代軟體工程團隊。原因在於，當前用於評估大型語言模型和自主代理的基準並未完全捕捉到軟體工程師每天處理的任務的復雜性。即使根據這些簡化後的基準，大型語言模型和自主代理所表現出的效能也不盡如人意。
軟體工程師的工作不僅僅是寫程式碼。AI 面臨著一系列的挑戰，比如深入洞察人類以及開展協作。人類在面對復雜的非線性問題時能夠深入思考，而 AI 這方面的能力很欠缺。AI 難以理解人類設計師考慮的情感共鳴和語境是否合適等問題。此外，準確地預測使用者需求需要一定程度的直覺和適應能力，在沒有人類協助的情況下，AI 尚未能掌握這些能力。
話雖如此，大型語言模型和自主代理的發展正在迅速推進，AI 承擔的任務越來越多，越來越高效，而且能力越來越強。本文旨在深入探討評估AI工程師發展的基準。
AI 的發展前景：工程師Devin
最近，Cognition 實驗室的在一篇部落格文章中介紹了一名自主 AI 軟體工程師 Devin，文章中有一則視訊，介紹了 Devin 掌握的一些技能，例如開發和部署應用程式、修復錯誤、處理開源計畫問題、為已建立的軟體計畫做貢獻，以及完成Upwork上的真實任務。
這些視訊展示了Devin在一個沙盒式計算環境中使用一系列的開發者工具（如shell、程式碼編輯器和瀏覽器）來完成這些任務。該實驗室的網站還包含了一個連結，裏面記載了希望「雇用」Devin的等候者名單。
在視訊中，似乎 Devin 完成的任務都很厲害，但實際上，這些任務都非常簡單，類似於初級開發者教程或編程面試題。舉個例子，其中一段視訊展示了Devin修復了一個編程競賽演算法程式碼庫中的一個常見錯誤，但其實這是大型語言模型訓練數據集和評估基準中的一個很常見的問題。
Devin的任務與初級開發者責任的比較
盡管Devin完成的任務看起來很高端，但實際水平還不如軟體團隊中初級開發者面臨的真實挑戰。例如：
開發面向使用者的功能：與Devin的演示不同，初級開發者通常需要在應用程式中構建復雜的功能。這些任務需要與團隊合作，遵循設計系統，並確保應用程式滿足實際使用者的需求。
解決復雜的後端問題： 初級開發者還要解決生產環境中的復雜問題，例如修復擁有多個資料庫和伺服器的系統中的錯誤。 這些工作遠比Devin展示的任務要復雜得多，需要更深入的分析和解決問題的能力。
基準和現實：評估AI的軟體工程技術水平
有關Devin，讓我印象深刻的是以下聲明：
「我們在SWE-bench上對Devin進行了評估，這是一個具有挑戰性的基準，要求 AI 代理解決GitHub開源計畫中（如Django和scikit-learn）發現的真實問題。
Devin正確地解決了 13.86% 端到端的問題，遠超之前1.96%的水平。以前即便指出具體需要修改哪個檔，成績最好的模型也只能解決4.80%的問題。」
為了正確理解這一成就，關鍵是看看人們如何測試大型語言模型在編程挑戰中的表現。有一個很有名的例子，OpenAI 的 HumanEval，他們透過164個Python問題測試了該模型的基本編程水平，每個問題都要編寫一個函式，而且還要透過測試，比如統計字串中的大寫字元。雖然看著很厲害的樣子，但實際上這些任務遠不及日常軟體工程師的工作水平，更像是面試題，不是真實世界會遇到的問題。
SWE-bench：為什麽說這是更好的軟體工程AI測試基準
相比之下，SWE-bench提供的測試大型語言模型能力的基準更現實。其中包括來自實際的GitHub議題以及拉取請求的2,294個任務，要求大型語言模型瀏覽和修改程式碼庫，以解決真實問題。這個基準要求對程式碼有更深層次的理解和互動，更準確地反映了軟體工程的復雜性，而不像HumanEval等測試基準那麽簡單。
我們來深入看看SWE-bench論文，更仔細地觀察其中提到的Python程式碼庫、他們的數據來源以及測量效能的方法。該論文中給出了如下餅圖，顯示了問題的分布及其來源：
熟悉Python開發 的人可能對其中一些庫並不陌生 。下面，我們來看看他們選擇和抓取這些問題時使用的標準：
在SWE-bench測試中，AI 需要解決提供的程式碼庫中所描述的問題。AI 需要以修補程式檔的形式送出修改後的程式碼，並在其中指定必要的程式碼改動。如果在套用修補程式後，相關的程式碼透過測試，則認為 AI 的解決方案是成功的。該基準的有效性取決於AI成功解決的問題數量。
盡管這比HumanEval略好一些，但作為基準仍然不夠理想。現實生活中的軟體工程涉及復雜的系統和技術，例如Kubernetes、Docker和像AWS等這類的雲服務，這些在簡單的基準測試中很難復制。這說明了常見的大型語言模型測試場景與工程師實際面臨的細致、多方面的任務之間的差距。
SWE-bench：檢查測試數據
我們可以透過Huggingface存取SWE-Bench的訓練數據，這些數據儲存在一個「.parquet」檔格式中，這種格式不像HumanEval數據那樣容易檢視。我使用pandas庫建立了一個Python指令碼來載入和顯示這些數據。透過指令碼，我看到了其中包含的問題，與Django相關的問題一共有850個，下面是一個例子：
標題：在django-admin中添加一個選項，表示始終輸出顏色。
描述：使用Django管理命令，當前可以使用--no-colors標誌禁用顏色。
我想要的是一個相反的標誌：一個--force-colors標誌，指示Django在預設禁用顏色的情況下（通常是當輸出透過管道傳遞到另一個命令時）輸出ANSI顏色序列。
下面是一個真實的用例：我有一個自訂的Django命令來匯入數據。我自己執行這個命令，而且我希望向數據管理員發送一個顏色的日誌（使用HTML應該很合適）。我可以使用https://github.com/theZiz/aha 實用程式，但由於Django會在透過管道傳遞輸出時禁用顏色，所以無法使用這個實用程式。
針對這個特定的用例，*nix命令有一個特殊的標誌，例如 $ ls --color=always
建立時間：2018-07-22 17:15:08
修補程式大小：71行
盡管這是一個六年前的問題，但它反映出了我會實際遇到的真實軟體工程任務。
面對大型語言模型無法一次性處理的大型程式碼庫的挑戰，SWE-Bench透過使用兩種關鍵技術來解決：
稀疏檢索：選擇一組有限的相關檔供AI瀏覽，這有助於處理復雜的程式碼。
Oracle檢索： 這種方法使用已知可解決問題的檔，盡管這不太現實，因為一般情況下工程師不知道哪些檔需要編輯。
使用稀疏檢索比較實際，Oracle檢索有點不太公平，因為這等於是暗示大型語言模型修改哪些檔。就效能而言，Claude 2這類的模型在Oracle檢索的提示下解決了約4.8％的問題，而沒有提示時只解決了1.96％。
這就是為什麽相比之下，Devin 在沒有具體指導的情況下，成功率為 13.8％，在我看來已經很了不起了。
總結：AI與人類工程師是合作者的關系，而非競爭對手
由於工程人員數量不足，許多產品功能、更新和重要的錯誤修復都無法及時釋出。大公司的季度規劃中經常遇到這種情況。此外，我們對未來技術需求的預測能力經常被高估。由於例行任務都可以透過 AI 自動化，工程師的工作重點將轉向更復雜和更富創造力的任務，從而為創新帶來新的機會。
2024年，技術崗位市場陷入低谷，就業難的問題很普遍。然而，我認為這些問題的根源並不是AI造成的。相反，如果沒有當前AI的增長，情況可能會更糟。AI的繁榮正在推動初創公司的投資和崗位增加，防止了可能更嚴重的就業市場衰退。
然而，這種發展前景提供了良好的機會。我們可以透過開發更好的基準和訓練數據，訓練 AI 自動完成例行任務，而我們則可以集中精力處理更具創造性和價值的工作。
推薦閱讀：
4 月 25 - 26 日，由 CSDN 和高端 IT 咨詢和教育平台 Boolan 聯合主辦的「全球機器學習技術大會」將在上海環球港凱悅酒店舉行，特邀近 50 位技術領袖和行業套用專家，與 1000+ 來自電商、金融、汽車、智慧制造、通訊、工業互聯網、醫療、教育等眾多行業的精英參會聽眾，共同探討人工智慧領域的前沿發展和行業最佳實踐。
