編輯：編輯部
【新智元導讀】一次意外右手骨折，Claude工程師的工作竟被AI挽救了。近兩個月的時間，他們一起結對程式設計，甚至在一周内肝出3000行代碼。他瘋狂暗示，未來1-3年，就是「AI工程師」的天下。
原來，摔斷胳膊也是一件幸事......
當事人表示，「我再也不想回到過去了」。
這是為何？
事情是這樣的，幾個月前，Claude工程師Erik Schluntz騎車上班的路上，意外摔斷右手，打上了石膏。
為了生計，他不得已用左手打字。
即便如此，Schluntz依舊在Anthropic舊金山的辦公室裡，一周狂肝了3000行代碼。
為AI編碼點贊
誰也不曾想，這背後竟是AI立了大功。
他通過結合語音轉文字技術，與Claude AI結隊，整整寫了2個月的代碼。不過，必須承認的是，其中有許多是「樣闆代碼」。
為此，Schluntz還撰寫了一篇長文，題為——AI替代了我的右手。
文章中，他表示，「通過這件事，體驗到了人類幾乎不再需要自己編寫代碼的未來」。
老實說，我愛上了這種感覺。
另一位Anthropic工程師表示，通過從這件事，我們可以獲得軟體工程未來幾年的關鍵一瞥。
即使右手不能使，AI是完全可以讓你成為一個10倍程式猿。
那麼，Erik Schluntz如何在受傷期間，能夠讓AI為他高效編碼呢？
初始設定
首先，文章開篇他最先介紹了，自己如何對AI進行設定，最終決定使用了Claude AI。
Schluntz在摔斷手之前，也曾使用類似Copilot等AI代碼生成工具，但主要還是「手寫」。
2105年哈佛碩士畢業，Cobalt機器人公司創始人、Anthropic AI技術研究員
此外，他也使用過「語音轉文字」，但也主要在手機上發短信，并未在電腦中嘗試過這一功能。
好在，Mac内置語音控制在NLP處理上非常出色。
唯一不足的是，在聽寫任何與代碼相關的内容時，Siri表現得很糟糕。畢竟，一些符号和詞彙，大大超出其識别範圍。
就比如：
Schluntz：Eval
Siri：Eval？你想說的是Evil嗎？
當然，目前有一些專門針對代碼的優秀語音轉文字系統，比如Talon。
但由于Schluntz對AI代碼生成非常感興趣，于是決定嘗試，用自家AI去完成這項艱巨的任務。
這裡沒有使用Copilot，是因為其自動補全功能，對作者來說異常慢，需要開發者先寫出半行代碼，才能實作。
畢竟摔傷了一隻手，「動嘴」還是比「動手」快。
這時，隻需将大塊代碼庫内容一鍵複制粘貼到Claude AI中，然後通過語音指令進行轉換。
舉個栗子，Schluntz會說「重構ABC函數以接受輸入XYZ」或「為這些新函數ABC編寫單元測試，并檢視XYZ的示例測試」。
雖然Claude并不總是能在第一次嘗試時成功，但它能很好地接受後續指令和調整——
「我感覺就像是，和AI進行『結對程式設計』，而由另一個人操作鍵盤」！
調教Claude
「被迫」這樣寫代碼後，Schluntz很快就弄清楚了，什麼樣提示會生成有效代碼，什麼會是無效。
有時候，它非常神奇，但有時候，就連作者本人恨不得把電腦扔出窗外。
他不得不在IDE和Claude之間頻繁地複制粘貼，并手動拼接被Claude輸出長度限制截斷的代碼片段。
甚至，有幾次他對Claude「提高了嗓門」，隻因AI「忘記了」Schluntz之前的指令。
接下來，就看看Schluntz如何調教的Claude。
要具體，并舉例說明
如果你隻給出一個基本請求，LLM可能會給出一個中規中矩的通用答案，可能并不适用于你的特定代碼庫。
這時， 就需要給出「非常明确的指令」，來獲得更優的結果。
比如，詳細說明你期望的輸入和輸出，使用哪些庫等。
Schluntz發現，将指令放在輸入的開頭和結尾效果最好，可以確定AI不會「遺忘」重要的上下文。
最好是，能夠提供代碼庫示例，供AI參考。特别是，在編寫單元測試、處理樣闆代碼時，AI表現特别好。
通過示例，AI還可以學習如何使用代碼庫中的内部工具函數。
這當中，遷移和重構，是最完美的應用場景。
Schluntz會手動遷移一個執行個體，然後用它作為示例讓Claude轉換其餘的輸入。
通過這種方式，他可以快速重構大約3,000行代碼。
讓Claude掌舵
大多數人把LLM當作StackOverflow的替代品：他們雖是在詢問方向，但仍然自己在駕駛。
Schluntz則反其道而行之。
「如果你能夠給Claude正确的基礎構模組化塊，它往往可以一次性完成整個任務」。
在周末的機器人項目中，Schluntz和朋友Survy給Claude提供了一段控制單個電機和讀取藍牙遊戲搖桿的代碼。
通過這些構模組化塊，Claude能夠一氣呵成地編寫出所有遠端控制機器人的代碼，節省了大量時間和繁瑣的資料處理！
令人驚訝的是，這與常見的建議完全相反，即一次隻向LLM提出一個問題。
尤其是，在Schluntz不熟悉的領域，Claude往往在任務分解方面表現得尤為出色。
過于具體的請求也能奏效，但有時會導緻失去整體視角，類似于在沒有整體背景的情況下，給出狹隘的建議。
RTFM == Read This For Me
電機控制器，有一份100頁的說明書，内容繁瑣且複雜。
但Schluntz和Survy将其上傳到Claude，然後提問，迅速解決了其中一個問題。
在以前，這可能需要一個小時的仔細閱讀，并查找相關術語和教程。
機械同理心
「你不需要成為工程師才能成為賽車手，但你必須擁有機械同理心。」
——三屆F1世界冠軍Jackie Stewart
漸漸地，Schluntz開始建立起一種非常好的直覺，Claude能正确處理哪些事情，以及哪些事情仍需要人類做。
了解這種差別，讓他在兩個方向上都避免了很多挫敗感。
Schluntz學會了哪些地方可以進行簡化處理：
- 「我正在使用一個名為pygame的Python庫……」 簡化為 「在pygame中……」
- 「當我運作你的代碼時，我收到了這個錯誤資訊……你認為我現在應該怎麼做」 簡化為直接複制堆棧追蹤（stack trace）。
他甚至還學會了，轉換或重構大塊代碼可以帶來顯著效果。例如，在每一行之間添加計時器（timing instrumentation）。
另一方面，Schluntz學到如果一個LLM在兩次嘗試中，無法修複一個錯誤，那麼它永遠也不能修複。這時就需要自己動手了。
他還對Claude可能會犯的錯誤，有了很好的直覺。
有一次，Claude給了一段代碼，它循環周遊motor1, motor2, motor2, motor4，遺漏了motor3。
作者的朋友注意到這一點，并說 「這一定是幻覺」！但Schluntz能感覺到，「Claude絕不會犯這種錯誤」。
果然，當他們檢查輸入時，發現這個錯誤确實存在于最初放入Claude的原始代碼中。
為自己建構臨時工具
當Schluntz帶着機器人繞着後院轉了一圈後，它輸出了一份包含GPS坐标和其他資料的CSV檔案。
他想檢查這些資料與實際情況的準确性，但并沒有很高效的方法，要弄清楚如何檢視和分析這些GPS坐标可能需要一個小時。
甚至，他可能會手動在手機上檢查GPS坐标，用眼睛死死盯着這些數字，害怕漏掉其中一行。
這次，Schluntz将CSV檔案的前兩行提供給Claude。
它立即生成了一個網頁APP，可以在衛星圖像上渲染上傳的GPS坐标CSV檔案！
擁有恰好符合我需求的完美調試工具，而不用依賴print語句或預先建構的可視化工具，徹底改變了局面。
AI讓軟體開發變得如此便宜，以至于它可以為特定任務建立一次性工具！
總的來說，這些經驗和教訓讓Schluntz在使用AI寫代碼時，變得更高效！
沒有AI工具，這就像是放棄編譯器，改為手寫彙編語言一樣。
未來會怎樣？
在文章的最後，Schluntz将AI程式設計劃分為三個階段：
過去1-2年
過去的幾年裡，AI在軟體工程中的最大用途是，在IDE中使用Copilot自動補代碼，或是通過ChatGPT查詢代碼知識（以往需要去StackOverflow尋找答案）。
以及，通過一些智能體，在沒有人類監督情況下輔助程式設計，執行多個步驟，但這些并不實用。
今年
2024年，這三個領域都在發生變革。
諸如Zed、Cursor和各種VSCode擴充這樣的IDE，深入地整合了大模型，擁有更完美的上下文，還能處理更大塊的代碼生成。
Claude Artifacts、ChatGPT的Data Analyst取代了Jupyter Notebook。它們已經成為作者的原型開發工具，和一次性代碼的首選解決方案。
最後，一批如Cognition、Factory、CodeGen等智能體初創公司，正在端到端地自動化某些工作流程。
未來1-3年
Schluntz認為，未來1-3年，會出現真正的「AI工程師」。
也就是說，這三個領域可能會融合成一個産品——「AI工程師」，一個可以在自主模式和同步模式之間連續工作的系統：
1. 自主模式适用于範圍明确的任務
AI将完全獨立工作，具備編寫和運作代碼、使用外部工具、搜尋網絡資訊、通路内部文檔以及從過去錯誤中學習的能力。它會不斷疊代任務，直到完成或遇到瓶頸。這将占據80%的工作量。
2. 配對程式設計模式适用于最難的任務
人類将在高層次上指導AI，而AI負責處理低層次的實作細節。互動将是高度多模态的，人類和AI将在文本描述、視覺圖表、口頭讨論和直接操作彼此代碼之間無縫切換。你可能會共享螢幕，讓AI跟随并給出建議和意見，或者AI共享它的螢幕，而你在它操作時給予指導。
除此之外：
- AI工程師将擁有與你作為員工時相同的所有背景資訊和知識
AI将連接配接到公司的知識庫，通路你的設計檔案和客戶訪談記錄。無論是自主操作還是與人類配對，AI都能在需要時無縫地提取這些資訊以做出決策。
- AI工程師将是主動的而不是阿谀奉承的
如果你提出一個設計建議，AI會提供使用者訪談記錄，并提出更好的建議。
AI工程師将為其工作中的簡單和可預測部分派遣更便宜的子智能體，進而降低計算成本和延遲。就像你可以浏覽日志檔案而不必逐字閱讀一樣。
在Schluntz看來，AI工程師在特定方面将比大多數人類工程師更聰明，但有時會缺乏常識或者需要重新集中注意力并接受指導。
實際上，這與今天經理和産品經理與工程師合作的方式并沒有太大差別。
我們還需要工程師嗎？
正如電腦的發明并沒有讓會計師失業，而是提升了他們的工作，使他們能夠在更高的抽象層次上進行思考。
會計師仍然需要知道如何做數學運算和了解計算，但像電腦和電子表格這樣的工具使他們能夠創造比以前更多的價值。
類似的，AI也會降低建立軟體的門檻，就像任何人都可以使用Excel做個人會計一樣。
學生們可以在宿舍裡啟動完整的應用程式和業務，小型工作室也可以為自己建立量身定制的軟體工具。
這時，創造力将會是唯一的瓶頸。
人類工程師不會消失。
我們仍然需要在高層次上進行優先級排序，了解問題的整體架構和範圍，并審查AI的工作，尤其是在系統變得更大時。
不同的是，我們将會把更多的時間花在思考建構什麼上，而不是重複性地考慮「如何」建構。
如今，Schluntz已經擺脫了石膏的「束縛」，但他依然會将大部分代碼交給Claude去寫。
軟體工程的未來
巧合的是，Cognition AI的總裁Russell Kaplan昨天也發表了長推，預測在AI越來越擅長寫代碼的時代，軟體工程行業将如何發展。
Congnition AI正是第一個AI軟體工程師Devin的開發商。
在Kaplan看來，研究實驗室将對下一代模型的編碼和推理進行更多改進。很快，模型在程式設計上就會變得非常出色。
為什麼呢？
除了通用人工智能的進步外，程式設計還有一個獨特的優勢：通過「自我對弈」實作超越人類的資料擴充潛力。
模型可以編寫代碼，然後運作它；或者編寫代碼，編寫測試，并檢查一緻性。
這種類型的自動監督在大多數領域是不可能實作的，因為我們在接近人類專業知識極限時，面臨着後訓練的資料壁壘。而代碼不同——它可以通過經驗和自動化進行測試。
是以，軟體工程在幾年内将會發生根本性的變化。
真正的編碼智能體将能夠完成端到端的任務，并與今天的AI Copilot相輔相成。
在這個新世界中，每個工程師都将成為工程經理，并配有一支由智能體組成的實習生大軍。
工程師隻需将把基本任務委派給編碼智能體，然後就能把更多的時間花在解決更高層次的問題上：了解需求、架構系統以及決定建構什麼。
這将引領我們進入一個前所未有的軟體繁榮時代。
很快，曾經難以開發且成本高昂的軟體将變得更加易于擷取（提高10倍），「一次性軟體」也将會大量湧現。
未來的軟體工程師将比現在多得多，隻是工作方式會有很大不同：更多的自然語言，以及更少的樣闆代碼。
當然，對于這種變化，工程師們很快就能夠适應，就像他們從彙編語言過渡到Python時一樣。
除了直接的生産力提升之外，這還會對初創公司産生實質性的「二階效應」。
首先，面向開發者的公司也将針對編碼智能體進行「營銷」。畢竟，你的智能體會決定使用哪個雲服務和選擇哪個資料庫。
曾經作為優先考慮的使用者友好CLI，将轉變為智能體友好的UI/UX界面。
産品品質的門檻也将提高。在開發者能夠更快傳遞的世界中，半成品或功能不完整的MVP将不再被接受。
随着編碼智能體的興起，測試基礎設施将變得更加重要和普及。因為編碼智能體會編寫更多的測試，同時也會依賴這些測試來檢查他們的工作。
随着智能體使代碼遷移變得更容易，轉換成本将不再是科技公司的護城河。公司甚至将智能遷移助手與産品進行捆綁銷售，來簡化使用流程。
無論具體情況如何，總體趨勢是明确的：現在是成為開發者的最佳和最高效的時代。
參考資料：
https://x.com/ErikSchluntz/status/1820501663998001160
https://x.com/alexalbert__/status/1820503813180280964
https://erikschluntz.com/software/2024/07/30/code-with-ai.html
https://x.com/russelljkaplan/status/1820460524460802256