軟件開發(fā)的真正瓶頸不是寫代碼吧

AI 寫代碼已經(jīng)不稀奇了，寫得又快又多的人也越來越多。但在“高效開發(fā)”的神話背后，代碼評審越來越難做、協(xié)作越來越混亂、質(zhì)量控制越來越吃力，才是團隊真實的日常。為此，本文作者從“寫代碼從來不是瓶頸”這一觀點出發(fā)，深入探討了當前 LLM 對軟件開發(fā)流程的實際影響。
原文鏈接：https://ordep.dev/posts/writing-code-was-never-the-bottleneck
作者 | Pedro Tavareλ 
編譯 | 鄭麗媛
出品 | CSDN（ID：CSDNnews）
投稿或?qū)で髨蟮?| zhanghy@csdn.net
多年來，我一直堅信：寫代碼，從來都不是軟件開發(fā)中的瓶頸。
真正的瓶頸是什么？是代碼評審，是通過帶教與結(jié)對編程傳遞知識，是測試與調(diào)試，是溝通與協(xié)作帶來的“人類開銷”……這些環(huán)節(jié)層層疊加，嵌套在一張張工單、一場場會議和一次次敏捷儀式的迷宮中。這些流程本意是為了提升開發(fā)質(zhì)量，卻往往比編寫代碼本身更耗費時間和精力，因為它們需要深思熟慮、共識理解和合理判斷。
如今，隨著大語言模型（LLM）能更快地生成可運行的代碼，一種新的觀點開始流行起來：編碼曾是瓶頸，而我們終于攻克了它。
但事實并非如此：借助大語言模型，生成新代碼的邊際成本正在趨近于零——但理解、測試并信任這些代碼的代價呢？你需要對此投入的時間和精力，可能比以往任何時候都要高。

大語言模型只是轉(zhuǎn)移了工作量，而沒有消除
像 Claude 這樣的工具，確實能加速初始實現(xiàn)過程，但最終結(jié)果往往是：系統(tǒng)中流入了更多代碼，給負責審查、集成和維護的人員帶來更大壓力。
這一點在以下幾種場景中尤為明顯：
● 代碼提交者對生成的代碼是否完全理解，尚不明確；
● 生成的代碼引入了團隊不熟悉的模式，或違反既有規(guī)范；
● 邊界情況、隱藏副作用不容易被察覺。
最終我們會面臨這樣一個局面：代碼更容易產(chǎn)出，但驗證、理解和維護卻更復雜，致使團隊整體效率未必能因此提升。
這也不是什么新問題，畢竟“復制粘貼式開發(fā)”這個調(diào)侃，開發(fā)者們早已不陌生。只是大語言模型帶來的生成速度和規(guī)模，進一步放大了這種復制粘貼的習慣。

寫代碼不難，理解代碼才難
有句話說得好：“代碼的最大成本在于理解，而不是編寫。”
大語言模型確實縮短了代碼產(chǎn)出的時間，但要想真正理解其行為、排查細微 Bug、保證其長期可維護性，依然是一個高成本的智力任務(wù)。尤其當審查者難以判斷哪些代碼是 AI 寫的、哪些是人寫的，甚至連“為什么要這么實現(xiàn)”都無法理解時，維護難度只會進一步上升。

軟件開發(fā)的本質(zhì)，從來都不是孤島
本質(zhì)上來說，軟件工程是一個高度協(xié)作的工作過程，依賴于共同的理解、目標一致性以及老帶新的經(jīng)驗傳承。但現(xiàn)在，當代碼生成速度遠超過討論和審查速度時，團隊可能會陷入一個誤區(qū)：默認代碼是“對的”，即“假設(shè)”質(zhì)量達標，而不是認真驗證以“確保”質(zhì)量達標。
這種心態(tài)會給審查者和導師帶來巨大壓力，導致整體流程在看似“自動化”的表象下，其實更加脆弱和緩慢。

LLM 確實很強，但并未解決根本問題
沒錯，大預言模型的確能顯著提升原型開發(fā)、框架搭建和部分自動化流程的效率。但它無法替代清晰的思考、細致的審查和合理的架構(gòu)設(shè)計。如果說有什么不同的話，只能說隨著生成代碼增多，這些能力變得更加重要。
沒錯，編碼成本確實下降了；但作為一個團隊，一起搞懂代碼的成本，并沒有變低——這才是我們真正的瓶頸，不要再自欺欺人了。

網(wǎng)友熱議：寫得快，不代表就是對的；生成得多，不代表質(zhì)量就夠
以上這篇文章在 HN 上引起了開發(fā)者們的高度關(guān)注和討論，越來越多的一線工程師開始意識到，大模型正在放大軟件工程中最難啃的那塊骨頭：理解、審查和協(xié)作。
一位資深開發(fā)者在評論區(qū)分享了自己的真實經(jīng)歷：他在帶實習生的過程中發(fā)現(xiàn)，借助 LLM，他們的代碼產(chǎn)出速度大幅提升，一天的量抵得上過去一兩周。但表面效率提升背后，是一場認知負債的積累：
● 實習生寫的代碼“像是對的”，但其實錯得離譜；
● 看起來干凈的提交，實際隱藏著無數(shù)邊界問題；
● 代碼結(jié)構(gòu)復雜得不合理，審查意見很難被真正理解；
● 讓修改也不是改原有的 PR，而是重新提交一個全新方案，結(jié)果又是新的復雜問題。
這并不是個例。另一位開發(fā)者也表達了類似的看法：雖然 LLM 可以加速代碼生成，但真正耗時的是后續(xù)的代碼清理、Bug 排查、安全審查、重構(gòu)和優(yōu)化——這些過程沒法“自動化”，也沒人愿意做。
此外，還有開發(fā)者從更高的視角指出：“寫代碼，早已不是稀缺技能了。”他提到，如今和幾十年前不同，行業(yè)已經(jīng)從“誰能寫出系統(tǒng)”演進到“誰知道該做什么系統(tǒng)”了。當年比爾·蓋茨能靠寫代碼吃飯，是因為那是當時最稀缺的能力；而現(xiàn)在，代碼早已“過剩”，市場需求和判斷力才是制勝關(guān)鍵。
這也再次印證了原文的觀點：寫代碼的邊際成本在下降，但“理解代碼、協(xié)作構(gòu)建”的邊際成本反而在上升。所以，當我們在談?wù)?LLM 提升了“效率”時，不妨多問一句：它提升的是誰的效率？在哪個環(huán)節(jié)？代價又是什么？
● 是初級工程師提 PR 更快了，還是高級工程師花了更多時間清掃后路？
● 是產(chǎn)品交付周期縮短了，還是產(chǎn)品質(zhì)量變得不可控了？
● 是每人能生成更多代碼了，還是真正讀懂這些代碼的人更少了？
大模型沒錯，它確實是很強大的工具，但任何工具都只是放大器 —— 它放大的可能是你的能力，但也可能會放大你的短板。