一次意外右手骨折，Claude 工程師的工作竟被 AI 挽救了。近兩個月的時間，他們一起結(jié)對編程，甚至在一周內(nèi)肝出 3000 行代碼。他瘋狂暗示，未來 1-3 年，就是「AI 工程師」的天下。
原來，摔斷胳膊也是一件幸事......
當(dāng)事人表示，「我再也不想回到過去了」。這是為何？
事情是這樣的，幾個月前，Claude 工程師 Erik Schluntz 騎車上班的路上，意外摔斷右手，打上了石膏。
為了生計，他不得已用左手打字。即便如此，Schluntz 依舊在 Anthropic 舊金山的辦公室里，一周狂肝了 3000 行代碼。
誰也不曾想，這背后竟是 AI 立了大功。
他通過結(jié)合語音轉(zhuǎn)文字技術(shù)，與 Claude AI 結(jié)隊，整整寫了 2 個月的代碼。不過，必須承認(rèn)的是，其中有許多是「樣板代碼」。
為此，Schluntz 還撰寫了一篇長文，題為 ——AI 替代了我的右手。
文章中，他表示，「通過這件事，體驗到了人類幾乎不再需要自己編寫代碼的未來」。
老實說，我愛上了這種感覺。
另一位 Anthropic 工程師表示，通過從這件事，我們可以獲得軟件工程未來幾年的關(guān)鍵一瞥。
即使右手不能使，AI 是完全可以讓你成為一個 10 倍程序猿。
那么，Erik Schluntz 如何在受傷期間，能夠讓 AI 為他高效編碼呢？
初始設(shè)置
首先，文章開篇他最先介紹了，自己如何對 AI 進行設(shè)置，最終決定使用了 Claude AI。
Schluntz 在摔斷手之前，也曾使用類似 Copilot 等 AI 代碼生成工具，但主要還是「手寫」。
2015 年哈佛碩士畢業(yè)，Cobalt 機器人公司創(chuàng)始人、Anthropic AI 技術(shù)研究員
此外，他也使用過「語音轉(zhuǎn)文字」，但也主要在手機上發(fā)短信，并未在電腦中嘗試過這一功能。
好在，Mac 內(nèi)置語音控制在 NLP 處理上非常出色。
唯一不足的是，在聽寫任何與代碼相關(guān)的內(nèi)容時，Siri 表現(xiàn)得很糟糕。畢竟，一些符號和詞匯，大大超出其識別范圍。
就比如：
Schluntz：Eval
Siri：Eval？你想說的是 Evil 嗎？
當(dāng)然，目前有一些專門針對代碼的優(yōu)秀語音轉(zhuǎn)文字系統(tǒng)，比如 Talon。
但由于 Schluntz 對 AI 代碼生成非常感興趣，于是決定嘗試，用自家 AI 去完成這項艱巨的任務(wù)。
這里沒有使用 Copilot，是因為其自動補全功能，對作者來說異常慢，需要開發(fā)者先寫出半行代碼，才能實現(xiàn)。
畢竟摔傷了一只手，「動嘴」還是比「動手」快。
這時，只需將大塊代碼庫內(nèi)容一鍵復(fù)制粘貼到 Claude AI 中，然后通過語音命令進行轉(zhuǎn)換。
舉個栗子，Schluntz 會說「重構(gòu) ABC 函數(shù)以接受輸入 XYZ」或「為這些新函數(shù) ABC 編寫單元測試，并查看 XYZ 的示例測試」。
雖然 Claude 并不總是能在第一次嘗試時成功，但它能很好地接受后續(xù)指令和調(diào)整 ——
「我感覺就像是，和 AI 進行『結(jié)對編程』，而由另一個人操作鍵盤」！
調(diào)教 Claude
「被迫」這樣寫代碼后，Schluntz 很快就弄清楚了，什么樣提示會生成有效代碼，什么會是無效。
有時候，它非常神奇，但有時候，就連作者本人恨不得把電腦扔出窗外。
他不得不在 IDE 和 Claude 之間頻繁地復(fù)制粘貼，并手動拼接被 Claude 輸出長度限制截斷的代碼片段。
甚至，有幾次他對 Claude「提高了嗓門」，只因 AI「忘記了」Schluntz 之前的指令。
接下來，就看看 Schluntz 如何調(diào)教的 Claude。
要具體，并舉例說明
如果你只給出一個基本請求，LLM 可能會給出一個中規(guī)中矩的通用答案，可能并不適用于你的特定代碼庫。
這時，就需要給出「非常明確的指令」，來獲得更優(yōu)的結(jié)果。比如，詳細說明你期望的輸入和輸出，使用哪些庫等。
Schluntz 發(fā)現(xiàn)，將指令放在輸入的開頭和結(jié)尾效果最好，可以確保 AI 不會「遺忘」重要的上下文。
最好是，能夠提供代碼庫示例，供 AI 參考。特別是，在編寫單元測試、處理樣板代碼時，AI 表現(xiàn)特別好。
通過示例，AI 還可以學(xué)習(xí)如何使用代碼庫中的內(nèi)部工具函數(shù)。這當(dāng)中，遷移和重構(gòu)，是最完美的應(yīng)用場景。
Schluntz 會手動遷移一個實例，然后用它作為示例讓 Claude 轉(zhuǎn)換其余的輸入。
通過這種方式，他可以快速重構(gòu)大約 3,000 行代碼。
讓 Claude 掌舵
大多數(shù)人把 LLM 當(dāng)作 StackOverflow 的替代品：他們雖是在詢問方向，但仍然自己在駕駛。Schluntz 則反其道而行之。
「如果你能夠給 Claude 正確的基礎(chǔ)構(gòu)建模塊，它往往可以一次性完成整個任務(wù)」。
在周末的機器人項目中，Schluntz 和朋友 Survy 給 Claude 提供了一段控制單個電機和讀取藍牙游戲手柄的代碼。
通過這些構(gòu)建模塊，Claude 能夠一氣呵成地編寫出所有遠程控制機器人的代碼，節(jié)省了大量時間和繁瑣的數(shù)據(jù)處理！
令人驚訝的是，這與常見的建議完全相反，即一次只向 LLM 提出一個問題。
尤其是，在 Schluntz 不熟悉的領(lǐng)域，Claude 往往在任務(wù)分解方面表現(xiàn)得尤為出色。
過于具體的請求也能奏效，但有時會導(dǎo)致失去整體視角，類似于在沒有整體背景的情況下，給出狹隘的建議。
RTFM == Read This For Me
電機控制器，有一份 100 頁的說明書，內(nèi)容繁瑣且復(fù)雜。但 Schluntz 和 Survy 將其上傳到 Claude，然后提問，迅速解決了其中一個問題。
在以前，這可能需要一個小時的仔細閱讀，并查找相關(guān)術(shù)語和教程。
機械同理心
「你不需要成為工程師才能成為賽車手，但你必須擁有機械同理心。」
—— 三屆 F1 世界冠軍 Jackie Stewart
漸漸地，Schluntz 開始建立起一種非常好的直覺，Claude 能正確處理哪些事情，以及哪些事情仍需要人類做。了解這種區(qū)別，讓他在兩個方向上都避免了很多挫敗感。
Schluntz 學(xué)會了哪些地方可以進行簡化處理：
「我正在使用一個名為 pygame 的 Python 庫……」 簡化為 「在 pygame 中……」
「當(dāng)我運行你的代碼時，我收到了這個錯誤信息…… 你認(rèn)為我現(xiàn)在應(yīng)該怎么做」 簡化為直接復(fù)制堆棧追蹤（stack trace）。
他甚至還學(xué)會了，轉(zhuǎn)換或重構(gòu)大塊代碼可以帶來顯著效果。例如，在每一行之間添加計時器（timing instrumentation）。
另一方面，Schluntz 學(xué)到如果一個 LLM 在兩次嘗試中，無法修復(fù)一個錯誤，那么它永遠也不能修復(fù)。這時就需要自己動手了。
他還對 Claude 可能會犯的錯誤，有了很好的直覺。
有一次，Claude 給了一段代碼，它循環(huán)遍歷 motor1, motor2, motor2, motor4，遺漏了 motor3。
作者的朋友注意到這一點，并說 「這一定是幻覺」！但 Schluntz 能感覺到，「Claude 絕不會犯這種錯誤」。
果然，當(dāng)他們檢查輸入時，發(fā)現(xiàn)這個錯誤確實存在于最初放入 Claude 的原始代碼中。
為自己構(gòu)建臨時工具
當(dāng) Schluntz 帶著機器人繞著后院轉(zhuǎn)了一圈后，它輸出了一份包含 GPS 坐標(biāo)和其他數(shù)據(jù)的 CSV 文件。
他想檢查這些數(shù)據(jù)與實際情況的準(zhǔn)確性，但并沒有很高效的方法，要弄清楚如何查看和分析這些 GPS 坐標(biāo)可能需要一個小時。甚至，他可能會手動在手機上檢查 GPS 坐標(biāo)，用眼睛死死盯著這些數(shù)字，害怕漏掉其中一行。
這次，Schluntz 將 CSV 文件的前兩行提供給 Claude。它立即生成了一個網(wǎng)頁 App，可以在衛(wèi)星圖像上渲染上傳的 GPS 坐標(biāo) CSV 文件！
擁有恰好符合我需求的完美調(diào)試工具，而不用依賴 print 語句或預(yù)先構(gòu)建的可視化工具，徹底改變了局面。
AI 讓軟件開發(fā)變得如此便宜，以至于它可以為特定任務(wù)創(chuàng)建一次性工具！
總的來說，這些經(jīng)驗和教訓(xùn)讓 Schluntz 在使用 AI 寫代碼時，變得更高效！
沒有 AI 工具，這就像是放棄編譯器，改為手寫匯編語言一樣。
未來會怎樣？
在文章的最后，Schluntz 將 AI 編程劃分為三個階段：
過去 1-2 年
過去的幾年里，AI 在軟件工程中的最大用途是，在 IDE 中使用 Copilot 自動補代碼，或是通過 ChatGPT 查詢代碼知識（以往需要去 StackOverflow 尋找答案）。
以及，通過一些智能體，在沒有人類監(jiān)督情況下輔助編程，執(zhí)行多個步驟，但這些并不實用。
今年
2024 年，這三個領(lǐng)域都在發(fā)生變革。
諸如 Zed、Cursor 和各種 VSCode 擴展這樣的 IDE，深入地整合了大模型，擁有更完美的上下文，還能處理更大塊的代碼生成。
Claude Artifacts、ChatGPT 的 Data Analyst 取代了 Jupyter Notebook。它們已經(jīng)成為作者的原型開發(fā)工具，和一次性代碼的首選解決方案。
最后，一批如 Cognition、Factory、CodeGen 等智能體初創(chuàng)公司，正在端到端地自動化某些工作流程。
未來 1-3 年
Schluntz 認(rèn)為，未來 1-3 年，會出現(xiàn)真正的「AI 工程師」。
也就是說，這三個領(lǐng)域可能會融合成一個產(chǎn)品 ——「AI 工程師」，一個可以在自主模式和同步模式之間連續(xù)工作的系統(tǒng)：
1. 自主模式適用于范圍明確的任務(wù)
AI 將完全獨立工作，具備編寫和運行代碼、使用外部工具、搜索網(wǎng)絡(luò)信息、訪問內(nèi)部文檔以及從過去錯誤中學(xué)習(xí)的能力。它會不斷迭代任務(wù)，直到完成或遇到瓶頸。這將占據(jù) 80% 的工作量。
2. 配對編程模式適用于最難的任務(wù)
人類將在高層次上指導(dǎo) AI，而 AI 負(fù)責(zé)處理低層次的實現(xiàn)細節(jié)?；訉⑹歉叨榷嗄B(tài)的，人類和 AI 將在文本描述、視覺圖表、口頭討論和直接操作彼此代碼之間無縫切換。你可能會共享屏幕，讓 AI 跟隨并給出建議和意見，或者 AI 共享它的屏幕，而你在它操作時給予指導(dǎo)。
除此之外：
AI 工程師將擁有與你作為員工時相同的所有背景信息和知識
AI 將連接到公司的知識庫，訪問你的設(shè)計文件和客戶訪談記錄。無論是自主操作還是與人類配對，AI 都能在需要時無縫地提取這些信息以做出決策。
AI 工程師將是主動的而不是阿諛奉承的
如果你提出一個設(shè)計建議，AI 會提供用戶訪談記錄，并提出更好的建議。
AI 工程師將為其工作中的簡單和可預(yù)測部分派遣更便宜的子智能體，從而降低計算成本和延遲。就像你可以瀏覽日志文件而不必逐字閱讀一樣。
在 Schluntz 看來，AI 工程師在特定方面將比大多數(shù)人類工程師更聰明，但有時會缺乏常識或者需要重新集中注意力并接受指導(dǎo)。
實際上，這與今天經(jīng)理和產(chǎn)品經(jīng)理與工程師合作的方式并沒有太大區(qū)別。
我們還需要工程師嗎？
正如計算器的發(fā)明并沒有讓會計師失業(yè)，而是提升了他們的工作，使他們能夠在更高的抽象層次上進行思考。
會計師仍然需要知道如何做數(shù)學(xué)運算和理解計算，但像計算器和電子表格這樣的工具使他們能夠創(chuàng)造比以前更多的價值。
類似的，AI 也會降低創(chuàng)建軟件的門檻，就像任何人都可以使用 Excel 做個人會計一樣。
學(xué)生們可以在宿舍里啟動完整的應(yīng)用程序和業(yè)務(wù)，小型工作室也可以為自己創(chuàng)建量身定制的軟件工具。
這時，創(chuàng)造力將會是唯一的瓶頸。人類工程師不會消失。
我們?nèi)匀恍枰诟邔哟紊线M行優(yōu)先級排序，理解問題的整體架構(gòu)和范圍，并審查 AI 的工作，尤其是在系統(tǒng)變得更大時。
不同的是，我們將會把更多的時間花在思考構(gòu)建什么上，而不是重復(fù)性地考慮「如何」構(gòu)建。
如今，Schluntz 已經(jīng)擺脫了石膏的「束縛」，但他依然會將大部分代碼交給 Claude 去寫。
軟件工程的未來
巧合的是，Cognition AI 的總裁 Russell Kaplan 昨天也發(fā)表了長推，預(yù)測在 AI 越來越擅長寫代碼的時代，軟件工程行業(yè)將如何發(fā)展。
Congnition AI 正是第一個 AI 軟件工程師 Devin 的開發(fā)商。
在 Kaplan 看來，研究實驗室將對下一代模型的編碼和推理進行更多改進。很快，模型在編程上就會變得非常出色。為什么呢？
除了通用人工智能的進步外，編程還有一個獨特的優(yōu)勢：通過「自我對弈」實現(xiàn)超越人類的數(shù)據(jù)擴展?jié)摿Α?/p>
模型可以編寫代碼，然后運行它；或者編寫代碼，編寫測試，并檢查一致性。
這種類型的自動監(jiān)督在大多數(shù)領(lǐng)域是不可能實現(xiàn)的，因為我們在接近人類專業(yè)知識極限時，面臨著后訓(xùn)練的數(shù)據(jù)壁壘。而代碼不同 —— 它可以通過經(jīng)驗和自動化進行測試。
因此，軟件工程在幾年內(nèi)將會發(fā)生根本性的變化。
真正的編碼智能體將能夠完成端到端的任務(wù)，并與今天的 AI Copilot 相輔相成。在這個新世界中，每個工程師都將成為工程經(jīng)理，并配有一支由智能體組成的實習(xí)生大軍。
工程師只需將把基本任務(wù)委派給編碼智能體，然后就能把更多的時間花在解決更高層次的問題上：理解需求、架構(gòu)系統(tǒng)以及決定構(gòu)建什么。
這將引領(lǐng)我們進入一個前所未有的軟件繁榮時代。
很快，曾經(jīng)難以開發(fā)且成本高昂的軟件將變得更加易于獲?。ㄌ岣?10 倍），「一次性軟件」也將會大量涌現(xiàn)。
未來的軟件工程師將比現(xiàn)在多得多，只是工作方式會有很大不同：更多的自然語言，以及更少的樣板代碼。
當(dāng)然，對于這種變化，工程師們很快就能夠適應(yīng)，就像他們從匯編語言過渡到 Python 時一樣。
除了直接的生產(chǎn)力提升之外，這還會對初創(chuàng)公司產(chǎn)生實質(zhì)性的「二階效應(yīng)」。
首先，面向開發(fā)者的公司也將針對編碼智能體進行「營銷」。畢竟，你的智能體會決定使用哪個云服務(wù)和選擇哪個數(shù)據(jù)庫。
曾經(jīng)作為優(yōu)先考慮的用戶友好 CLI，將轉(zhuǎn)變?yōu)橹悄荏w友好的 UI / UX 界面。
產(chǎn)品質(zhì)量的門檻也將提高。在開發(fā)者能夠更快交付的世界中，半成品或功能不完整的 MVP 將不再被接受。
隨著編碼智能體的興起，測試基礎(chǔ)設(shè)施將變得更加重要和普及。因為編碼智能體會編寫更多的測試，同時也會依賴這些測試來檢查他們的工作。
隨著智能體使代碼遷移變得更容易，轉(zhuǎn)換成本將不再是科技公司的護城河。公司甚至將智能遷移助手與產(chǎn)品進行捆綁銷售，來簡化使用流程。
無論具體情況如何，總體趨勢是明確的：現(xiàn)在是成為開發(fā)者的最佳和最高效的時代。
參考資料：
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
本文來自微信公眾號：微信公眾號（ID：null），作者：新智元，原標(biāo)題《AI 編碼無需人類插手！Claude 工程師摔斷右手，竟一周狂肝 3000 行代碼》
廣告聲明：文內(nèi)含有的對外跳轉(zhuǎn)鏈接（包括不限于超鏈接、二維碼、口令等形式），用于傳遞更多信息，節(jié)省甄選時間，結(jié)果僅供參考，IT之家所有文章均包含本聲明。