最近看看我的推文，幾乎都在聊 LLM 的事情。我完全被它迷住了。只要有空，我會立刻要求 LLM 做事或提問。尤其是讓 AI 寫程式碼，簡直就像沉迷於剛開始玩的社群遊戲一樣，連一丁點時間都不想浪費。
使用 AI 寫程式碼真的很有趣。我試著開發 RDBMS，但感覺就像「接下來要做什麼？」「要加入 PostgreSQL 相容介面嗎？」「蛤？做得到嗎？」「完成啦！」這樣，功能一個接一個地冒出來。當然，一開始並不是完美的，所以在撰寫單元測試的過程中，會不斷出現漏洞，但即便如此，其開發速度還是遠遠超過了我的預期。最重要的是，感覺就像工作之餘多了一個聊天對象一樣，卻能輕鬆寫出將近十萬行的程式碼，這已經超越了感動，讓人感到敬畏。
有在關注我的社群媒體發文的人應該知道，我長期以來不信任軟體開發工程學。我認為那不是一個程式設計師學了就能怎麼樣的東西，而是一門針對群體在進行程式設計時的群體行為的工程學科，我強烈懷疑它是否適用於各種各樣的程式設計現場。然而，當我使用多個 AI 代理時，我發現自己需要一種感覺，例如不看程式碼就能猜到錯誤的存在，或是逐漸擴大可信任的範圍，我不禁意識到自己正在採取一種軟體開發工程學的方法。雖然我沒有採用錯誤密度或收斂曲線之類的指標，但我意識到從宏觀角度來看，我離它並不遠。
即使是外行人，在面對 AI 代理時，也可能會大喊「寫出沒有錯誤的軟體ーー！！」，但只要具備軟體開發的知識，耐心地下達指令，並透過對話來區分被丟出來的工作，然後重新下達指令，大多數問題都能解決。重複這樣的作業，會讓人感到安心，因為到目前為止所培養的直覺並沒有白費，但同時也強烈感受到 AI 代理自行解決這種程度的問題只是時間問題。在這一點上，我對程式設計師的未來工作前景感到非常悲觀。
AI 代理寫的程式碼說實話就像恐怖谷效應一樣，不太會讓人想要維護，但前提是軟體工程師本來就不想維護程式碼。只是因為這段程式碼在工作中能產生金錢，所以才不得不維護，而讀程式碼是維護方式中的最後手段，這就是職業程式設計師（工匠程式設計師喜歡以程式碼本身為目的，高興地修改特定的程式碼，我覺得他們喜歡就好，我的本性也比較偏向那邊）。程式設計是在構建時的作業，而軟體工程則是為了使其持續產生價值而進行的持續性行為，毫不客氣地說，為了在不讀不想讀的程式碼的情況下保證品質，這幾十年來所做的努力結晶。
x.com
規則發生了很大的變化，所以有些東西可以活用，有些東西則不能活用，以下列出我目前所感受到的一些技巧：
情境工程就是組織理論
無論是讓 AI 寫程式碼，軟體不變的真理是，程式碼總是會持續巨大化。我認為 LLM 的上下文長度在未來也會增加，但軟體程式碼的成長速度一定會超過它。即使 LLM 能夠迴避上下文的問題，但最終能夠順利聚焦的上下文範圍是有限的，從稻草堆中找針的問題一定會如影隨形。當然，團隊成員無法將生產環境程式碼的全貌都塞進腦袋裡，所以大家會不約而同地進行職責分工。而這種職責分工，換個角度來看就是情境工程。 也就是說，如果將整個專案的樣貌都丟進上下文，就會因為太大而無法思考，所以會進行工作的區分，例如「在這個工作中，希望你在這個模組的這個功能中加入這樣的功能，執行該任務時不需要知道不必要的資訊」，這種工作分配方式在大多的職種中都會對新人進行，並不僅限於 AI 代理。 使用 AI 代理後就會發現，它們將 0 變成 1 的速度非常快，簡直病態。它們是在這種基準測試環境下被培養出來的，所以代替人類解決痛苦的錯誤只是附帶的。將 0 變成 1 的速度很快，是因為為了執行該任務，需要記在腦海中的現有程式碼是零，所以極少需要擔心接點。程式設計師也是一樣，情境越小的程式設計師越喜歡建立微服務，因為微服務可以縮小需要記在腦海中的情境。 微服務是一個極端的例子，但在構建軟體時，區分內部範圍的行為，就是限定他人需要關心的範圍，而一直以來被稱為「關注點分離」的東西，也同樣是應該放入 AI 代理腦海中的資訊分離。 關於「軟體架構」是什麼，至今尚未達成完全的共識，但我的感覺是，它是將在其上工作的人們應該放入腦海中的情境進行區分的東西。即使老闆一句話就導入了值物件，但如果底層程式設計師應該記在腦海中的情境沒有改變，那就不能說架構師做了正確的工作。 將任務區分為 AI 代理容易工作的方式，與將軟體內部區分為人類容易工作的方式非常相似。以現在的直覺來看，我認為在這個層面上，應該擔心的事項比想像中還多，所以會使用情境更大且更聰明的高階模型，但如果能夠順利地將其卸載到調查代理等，或許即使是便宜的模型也能順利運作。
LLM 很貴
大家都說高階模型明顯能吐出更好的程式碼，但高階模型每 1M 個 Token 的價格卻是 10 美元、20 美元的世界。使用該情境進行的工作可能會耗費程式設計師數小時的時間，所以我認為這樣做是划算的，但如果能將工作委託給便宜的模型，那就再好不過了。價格競爭到最後，現在的高階模型可能會變得非常便宜，可以像流水一樣使用，但到那時，一定也會出現當時的高階模型，並宣傳說可以解決其他模型無法解決的難題。結果，我認為在編寫程式碼時，將不太困難的任務交給便宜的模型這種狀態，在未來也會持續存在。甚至連便宜模型中的極致，也就是本地 LLM，作為卸載對象也很有吸引力，由高階模型定義的任務，再由本地 AI 代理群來承包，這是一個很實際的說法，雖然現在的本地 LLM 還不知道能完成多麼複雜的程式碼編寫任務，但如果用便宜的 AI 來寫，卻因為無法除錯而放棄時，就將該知識連同升級到更聰明的模型，這種說法可能很快就會變成常識。本地和高階以子代理呼叫的形式協同工作，而軟體開發公司實際上可能最終會變成一個由少數幾人組成的團隊，他們大量擁有並持續運行本地 LLM。AMD 的 Ryzen AI Max 系列可能很快也會大幅漲價，畢竟競爭對手是有血有肉的人類程式設計師。
AI 代理不穩定
我不太清楚哪裡的實作不好，所以無法斷定，但原因不明的停止或間歇性的錯誤等莫名其妙的事情總是會持續發生。甚至連核心沒有崩潰，但編輯器的反應速度卻變成以分鐘為單位的情況都不稀奇。而且改寫的品質也參差不齊，改寫目標的行號變得亂七八糟，經常造成嚴重的破壞。雖然壞掉後它們會自發性地注意到並去修復，所以並不是那麼致命，但即使如此，還是有在不穩定的情況下使用不穩定東西的訣竅，就我所知，ラルフループ（Lalr loop）以及隨之而來的進度追蹤是有效的。
x.com
用一句話來說，ラルフループ就是將 AI 代理的啟動本身放入迴圈中。但要在提示中指示它將這次的進度寫入某處，並在迴圈開始時讀取該進度。這樣，AI 代理就會在接收到「到目前為止的進度」作為上下文後，完成「這次的任務」。這樣做的好處是，即使 AI 代理在途中停止或因 OOM 而死掉，它還是會以某種方式繼續運行。雖然進度備忘錄可能會變得太大，但只要在提示中寫入適時摘要和壓縮，就總會有辦法的。 但如果只有單一迴圈，所有的任務都會由單一的高價模型來執行，所以可以將設計和區分任務的階段交給高價模型，將看起來很簡單的任務交給便宜的 AI 代理來做，像這樣，迴圈本身的內容可以變得非常複雜，畢竟我們是在編寫程式來呼叫程式碼編寫 AI 代理，這簡直就是元程式設計。我還沒有達到這個境界……但讓 LLM 自己來改善迴圈本身，總有一天也會變成理所當然的事情吧。
bsky.app
antirez 先生為了加速程式碼所給出的提示中，指示「5. Use this file to track progresses」這一點很有趣，只要作業在途中結束，也會參考相同的文字並繼續執行，因此文字中包含上次的進度是非常合理的。
自我審查 5 次
程式碼編寫 AI 代理輸出的程式碼有 9 成都能順利運行，但只要量夠大，每次讓它自我審查，就能發現改善的地方。雖然我希望它能從一開始就寫出不需要審查的完整程式碼，但既然人類也很難做到，那麼 LLM 也有在其他情況下不審查就無法發現的缺點吧。人類可能需要花費時間來反省自己寫的程式碼，但海外的工程師寫道，程式碼編寫 AI 代理在進行自我審查時，大多在 5 次後就會收斂。
從成本方面來看，當然代價不菲，但即便如此，還是比人類便宜很多，而且只要將其納入機制中，人類就沒有介入的餘地了。我不知道 5 這個數字有什麼具體的意義，而且將來可能會變成別的數字，但就我的體感而言，即使讓 AI 代理寫的程式碼審查數次，還是會出現可以改善的地方，LLM 的專長就是反省。（有時也會看到為了讓對話成立而強行提出的審查意見，所以可能也需要審查審查意見本身）。即使程式碼編寫 AI 代理寫的程式碼，如果要在生產環境中使用，最後還是要由人類來審查，這種情況可能還會持續一段時間，但即使如此，在人類審查之前，先讓機器自己審查 N 次，可能會變成常識。看來創造者和咎責者如果分開，就能互相提升。用多家公司的 AI 代理來審查，或許也會出現新的觀點。
因為篇幅有點太長了，所以先在這裡發布。