效率陷阱：為何過度追求AI生產力會摧毀你的工程文化
AI驅動的工程生產力神話
人工智能在軟件開發中無處不在。從GitHub Copilot到Claude Code，各公司正以驚人的速度將AI整合到其工程工作流程中。
其承諾是：更快的代碼交付、更少的瓶頸和更高的生產力。然而，這種對效率的工業時代迷戀根本誤解了軟件工程的本質。
說明顯而易見的事情，軟件交付不僅僅是產出代碼——它還涉及以創造價值的方式解決困難且獨特的問題。諷刺的是，通過AI對效率的無止境追求，可能會使軟件團隊的效率下降，而不是提高。
代碼管道並不是裝配線
開發者生產力長期以來都是一個有争議的話題。在一個極端的情況下，有人認為代碼的生產應該被視為一條裝配線，借鑒弗雷德里克·溫斯洛·泰勒和亨利·福特等人的生產力理念。這根本誤解了知識工作的本質。
如果你優化開發者的工作流程，消除在非編碼活動上“浪費”的時間，或者通過交付的代碼行數來衡量成功，或許你會感覺自己的工程團隊很有生產力，但這不太可能推動組織的成功。與在工廠裝配小部件不同，一流的軟件交付需要深入的問題解決能力、協作和長期思考。
優先考慮AI以提升速度的公司，可能會加速錯誤的事情。它們不僅沒能改善軟件，反而會以空前的速度產生更多低質量的代碼，累積技術負擔。加快糟糕決策的速度並不是勝利，而是一種負擔。
但同時，也值得承認為何生產力會成為如此熱議的話題。太多組織仍然遭受信息技術項目超支和預算失控的困擾。對高層領導層關於最新技術的承諾並未如預期迅速實現。如果這聽起來很熟悉，那麼在承諾釋放一波新的AI驅動生產力之前，值得暫停思考。
我們所說的AI優先軟件交付是什麼？
我們已經可以看到關於AI在編碼方面潛力的一些宏大聲明。就我個人而言，我不相信我們距離“未來六個月內AI將撰寫90%的代碼”的世界有多近，儘管Anthropic首席執行官達里奧·阿莫迪這樣說。但即便如此，這些承諾與其他關於AI的宏大聲明是一致的。
這些生產力的承諾風險在於將高管的注意力引向錯誤的方向，而不是幫助推動商業價值。
我相信，我們正處於因AI而產生的巨大變革的邊緣。對於開發者而言，這種變化將類似於從組合語言轉向高級語言的轉變。在那時，許多人預測COBOL將消除對程序員的需求。然而，實際上並未發生這樣的事情——而是根本性的變化在於我們對軟件交付過程的思考方式。AI也將帶來類似的變化。
在Thoughtworks，我們已經有團隊在探索所謂的“提示到代碼”的可能性，這裡有巨大的潛力。我們看到AI編碼助手在處理重複或模板化代碼的任務中表現出色；它們可以幫助生成測試和檢測錯誤。事實上，在整個軟件交付生命周期中，我們認為有機會利用這種新型AI工具。
這一切並未改變我對AI工具的看法，AI工具應被視為對人類努力的補充，而非開發者的替代品。
我們僱用了幾千名員工來從事軟件交付。毫無例外，沒有一位員工是基於他們能多快編碼而被僱用的。相反，我們的開發者是因為他們的問題解決能力而被聘用的。
從個人角度來看，我經常發現我最好的想法是在我外出散步時出現的。這種知識工作無法用典型的生產力指標來衡量，但對於我作為專業人士的成功至關重要。
而這正是問題所在：如果你是通過生成代碼的速度來衡量軟件交付的成功，那麼你就會注定失敗。你的團隊將因為錯誤的事情而獲得獎勵，反而應該專注於這些AI工具如何使你的團隊更有效。以下是我成功利用AI的四個關鍵建議：
1. 使用AI處理日常工作——自動化重複性任務（例如，編寫測試用例和格式化代碼），但讓人類掌控架構、設計和問題解決。
2. 投資於工程卓越，而不僅僅是速度——衡量成功不在於編寫的代碼行數，而在於軟件質量、系統韌性和DORA指標。
3. 將AI視為助手，而非權威——鼓勵工程師將AI作為頭腦風暴的工具，而不是答案機器。最優秀的開發者會挑戰、完善和改進AI生成的建議，而不是盲目接受。
4. 優先考慮學習和批判性思維——而不是專注於AI驅動的輸出，培養重視好奇心、導師角色和深厚技術理解的工程文化。
Rachel Laycock是技術諮詢公司Thoughtworks的首席技術官。她為SiliconANGLE撰寫了這篇文章。
這篇文章引發的思考讓人反思當前AI技術在軟件開發中的運用。隨著AI技術的飛速發展，如何平衡效率與創造力，成為了許多企業需要面對的重要課題。過度依賴AI可能會導致創新能力的下降，這對任何一個希望在市場中保持競爭力的公司來說，都是一個潛在的風險。因此，企業在推動AI應用的同時，也應重視人類創造力的價值，從而實現真正的技術進步。
以上文章由特價GPT API KEY所翻譯及撰寫。而圖片則由FLUX根據內容自動生成。
