生成式人工智能（GenAI）會取代人類程序員嗎？恐怕不會。不過，使用GenAI的人類可能會取代程序員。但是如今有這么多的大語言模型（LLM），實際效果不一而足。

如果您在努力跟上所有LLM，并非只有您一個人。我們目睹一場激烈的LLM競賽。單單谷歌的GenAI產(chǎn)品就已經(jīng)變得非常豐富——其最新的開放模型Gemma是LLM快速精簡的最新例子，甚至可以稱之為小語言模型。

與DevOps社區(qū)更密切相關(guān)的是我們看到其他用于生成代碼的LLM閃電般的開發(fā)速度，比如Meta最近更新的Code Llama 70B。當(dāng)然，GenAI嚇倒了不少開發(fā)者。最近的一項研究發(fā)現(xiàn)，近一半的開發(fā)者對于自己憑借目前的技術(shù)技能在GenAI界取得成功表示了擔(dān)憂。

但這種擔(dān)心真的有道理嗎？關(guān)于人類程序員已死的說法可能夸大其辭了。人類甚至可能實際上有更多的時間來準(zhǔn)備迎接由GenAI主導(dǎo)的世界。

事實上，開發(fā)者應(yīng)該詢問的更適當(dāng)?shù)膯栴}不是“GenAI會搶走我的工作嗎？”，而是“我該使用哪個LLM？”

太龐大了，編程沒法成功

LLM給軟件開發(fā)界的承諾是有望將碼農(nóng)變成架構(gòu)師。然而，并非所有LLM都天生一樣；值得探討的是，為什么一開始就涌現(xiàn)出了較小巧的LLM。

更強大的主流模型（比如GPT-4和Claude 2）仍然只能勉強解決不到5%的實際GitHub問題。ChatGPT仍然存在嚴(yán)重的幻覺問題：假變量，或者甚至十多年前就已經(jīng)被棄用的概念。此外，它讓沒用的內(nèi)容看起來很有用。您可以嘗試?yán)?ldquo;提示工程”來擺脫這些沒用的內(nèi)容，但是有益的上下文數(shù)量存在一個最佳平衡點——太多會導(dǎo)致更混亂更隨機的結(jié)果，白白耗費了更多的處理能力。

LLM編程方面更大的問題是信任。在過去，主流LLM不加區(qū)別地吸收網(wǎng)上的一切內(nèi)容，就像一個大型數(shù)字吸塵器，至于它們從哪里獲取數(shù)據(jù)缺乏透明度。哪怕一家公司交付的代碼中僅僅1%含有另一家公司的受版權(quán)保護(hù)的代碼，這也是個問題。您可以想象噩夢般的召回場景：交付的產(chǎn)品沒有無線傳輸功能來挑出可疑代碼。

不過，LLM格局正在迅速改變。

LLM對于編碼夠?qū)I(yè)嗎？

當(dāng)Meta在今年早些時候宣布對其Code Llama 70B進(jìn)行更新時，感覺這是大受歡迎的嘗試，有望解決主流LLM對編碼缺乏關(guān)注的問題。它有三種不同大小的版本：70億個參數(shù)、130億個參數(shù)和340億個參數(shù)。它還使用代碼的5000億個token和與代碼相關(guān)的數(shù)據(jù)進(jìn)行訓(xùn)練，包含10萬個token的龐大上下文窗口。

從理論上講，其中最令人興奮的是Code Llama Python，這是專門為Python設(shè)計的Code Llama版本——主要是由于它代表了LLM未來的發(fā)展方向。與Meta的大型科技同行開發(fā)的一些模型不同，這個模型完全致力于為一種特定的語言編程，使用Python代碼的大約1000億個額外的token進(jìn)行訓(xùn)練。業(yè)界更加需要的正是針對特定用例的這種級別的定制建模。

之所以需要強調(diào)“理論上令人興奮”，是由于像Code Llama這樣的LLM對開發(fā)者到底有多有用還有待觀察。去Reddit看看，就會發(fā)現(xiàn)早期的結(jié)論似乎是，該模型因諸多問題而令人沮喪，其中包括復(fù)雜的提示格式、過于嚴(yán)格的護(hù)欄，最重要的還有幻覺問題。最后一點是另一個不爭的事實，提醒人們：任何模型的好壞完全取決于訓(xùn)練它所使用的數(shù)據(jù)。

不管是否存在缺陷，Meta的定制LLM方法已經(jīng)引起了人們的重視，即大語言模型并不是AI輔助代碼生成取得成功的唯一途徑。我們看到，業(yè)界越來越青睞使用規(guī)模較小、更專門化的LLM編寫代碼，比如BigCode、Codegen和CodeAlpaca。StarCoder是另一個LLM，盡管只有155億個參數(shù)，但在評估基準(zhǔn)測試中的表現(xiàn)卻勝過PaLM、LaMDA和LLaMA等超大模型。

這每一種選擇都有優(yōu)缺點，但最重要的是，小模型用起來比大模型安全得多。如果您在用C++編程，果真需要您的LLM充斥著一大堆不相關(guān)的知識（比如“誰是美國第三任總統(tǒng)？”）嗎？數(shù)據(jù)池越小，保持內(nèi)容的相關(guān)性就越容易，模型的訓(xùn)練成本就越低，無意中竊取他人受版權(quán)保護(hù)數(shù)據(jù)的可能性也就越小。

2024年的DevOps團(tuán)隊?wèi)?yīng)該徹底調(diào)研市面上所有可用的LLM選項，而不是默認(rèn)選擇最明顯的選項。甚至可能有必要針對不同的用例使用不止一種LLM。

但回到當(dāng)前存在的問題……

GenAI會取代人類嗎？

這些GenAI工具有可能代替真正的程序員嗎？除非模型提供的編程答案具有的準(zhǔn)確性提高到了可接受的誤差范圍內(nèi)（即98%-100%），否則可能代替不了。

不過為了便于討論，我們假設(shè)GenAI確實達(dá)到了這個誤差范圍。那么這是否意味著軟件工程的角色將發(fā)生轉(zhuǎn)變，您只需審查和驗證AI生成的代碼，而不是編寫代碼？如果四眼原則（four-eyes principle）適用的話，這樣的假設(shè)可能是錯誤的。這是內(nèi)部風(fēng)險控制最重要的機制之一，要求任何實質(zhì)性風(fēng)險的活動（比如交付軟件）都要由第二個、獨立的、有能力的人進(jìn)行審查和復(fù)核。除非AI被重新歸類是一種獨立的、有能力的生命體，否則它短期內(nèi)應(yīng)該沒有資格成為四眼原則中的另一雙眼睛。

如果GenAI將來有能力進(jìn)行端到端開發(fā)和構(gòu)建人機界面，那也不會是在不久的將來。LLM可以充分地與文本和圖像元素進(jìn)行交互。甚至現(xiàn)在就有工具可以將網(wǎng)頁設(shè)計轉(zhuǎn)換成前端代碼。然而與編碼相比，AI單獨承擔(dān)與圖形和UI/UX工作流程相關(guān)的設(shè)計要困難得多，盡管并非不可能。編碼也只是開發(fā)的其中一部分。剩余的工作就是另辟蹊徑，弄清楚誰是受眾，將想法轉(zhuǎn)化為可以構(gòu)建的產(chǎn)品，然后加以完善和改進(jìn)，這正是人類發(fā)揮作用的地方。

不管LLM變得有多好，對于程序員來說，有一條原則應(yīng)該始終不變：像對待自己編寫的代碼一樣對待每一段代碼。請同行評審，詢問同事“這是好的代碼嗎？”。永遠(yuǎn)不要盲目相信代碼。