不會使用 AI 的工程師就會落后。一位工程師小哥科爾頓?沃奇,說看到這類觀點引發(fā)了自己巨大的精神焦慮。幸好他是一個持懷疑態(tài)度的人,測試完一堆 AI 開發(fā)工具后,發(fā)現(xiàn)也就那么回事。

他的文章在 Hacker 上也引起許多程序員的討論,互動評論量有 600+。

一起來看他的回?fù)簟?span style="display:none">f6N28資訊網(wǎng)——每日最新資訊28at.com
AI 還有很多問題,工程師要學(xué)會引導(dǎo)沃奇小哥平時工作不怎么使用 AI,在社交媒體上總是刷到“AI 提升 10 倍生產(chǎn)力”“不會使用 AI 的工程師就落后了”之類的內(nèi)容,引起了他對自己專業(yè)能力的深度懷疑,讓自己陷入了精神焦慮之中。
他自己說,好在自己是個對任何事情看法都持懷疑態(tài)度的人,就去把 Claude Code、Cursor、Roo Code 和 Zed 等 AI 開發(fā)工具都試了一遍。
結(jié)果發(fā)現(xiàn),AI 寫樣板代碼、一次性腳本等,寫的又快又好,比如 React、JavaScript 的基礎(chǔ)代碼,臨時寫個 ESLint 規(guī)則啥的。
但是,AI 難以理解大型代碼庫的上下文,就算有很好的提示和文件,讓它查找文檔或者修復(fù)破壞的測試的時候,就總是來回折騰,做無用功。
更嚴(yán)重的是,AI 跟不上代碼庫的標(biāo)準(zhǔn)和工具,甚至?xí)摌?gòu)代碼庫,導(dǎo)致嚴(yán)重的安全漏洞。發(fā)現(xiàn) AI 存在這些問題后,他也就沒那么焦慮了,AI 還是需要工程師來引導(dǎo)的。

沃奇小哥說,工程師要學(xué)會將復(fù)雜任務(wù)拆解為更小的單元喂給 AI,避免 AI 在處理長文本(上下文窗口后期)時出現(xiàn)邏輯混亂或“失去理智”的情況。
他還拿 Claude Code 舉例子,雖然能自動完成部分任務(wù),但是可靠性不高,不能完全依賴。工程師要學(xué)會判斷 AI 何時“跑偏”(輸出不符合預(yù)期),此時要及時接手,糾正錯誤或重新引導(dǎo)。
打破“10 倍生產(chǎn)力”神話,無論 AI 還是工程師想要實現(xiàn)“AI10 倍生產(chǎn)力”,意味著工作流程的每個環(huán)節(jié)效率都要 X10。
舉個例子,從產(chǎn)品構(gòu)思、故事點協(xié)商、修復(fù)錯誤、代碼審查、等待部署、測試和 QA,這些工作過往都需要三個月來完成,有 AI 了,就能在 1.5 周內(nèi)完成?
比如代碼審查,需要的工作環(huán)節(jié)就有:(1)給審查者打標(biāo)簽(2)希望他們能盡快處理(但這會很困難,因為他們顯然要審查比以前多 10 倍的代碼)(3)在等待時切換到其他任務(wù)(4)看到通知立即回復(fù),也可以在你審稿人當(dāng)天離線 2 小時后回復(fù)(5)切換回審稿界面(6)閱讀他們的評論(7)回應(yīng)(8)重復(fù)操作
但凡有過項目開發(fā)經(jīng)驗的軟件工程師,都知道這不可能。

除此之外,軟件工程開發(fā)最終目的是做一個用戶喜愛的產(chǎn)品,產(chǎn)品經(jīng)理要審核、論證開發(fā)可行性,要進(jìn)行用戶訪談,同樣的,設(shè)計師和測試人員也一樣要做相應(yīng)的工作。
這些流程環(huán)節(jié)要是提升 10 倍生產(chǎn)力的話,就要招聘 10 倍的產(chǎn)品經(jīng)理及相關(guān)人員。
除了工作流程上的問題,就算 AI 寫代碼效率提升了 10 倍甚至 100 倍,但是實際工程師工作核心不是敲代碼,而是閱讀和思考,比如等待編譯、頁面刷新或測試運行。
很顯然,AI 并不會提升這些環(huán)節(jié)效率。
更不用說 AI 生成的內(nèi)容還存在缺陷、虛構(gòu)甚至低于代碼庫標(biāo)準(zhǔn)等問題了。而且隨著代碼庫規(guī)模增大,AI 出現(xiàn)這些問題的頻率也會隨之上升。
而且,AI 還存在過度構(gòu)建的問題。以上情況發(fā)生時,工程師必須得重新提示,或者親自去修改代碼。
回到原點,end。
換個角度,就算熟練運用 AI 寫代碼了,存在的問題可能就是工程師習(xí)慣性依賴 AI,不做深度審查和判斷,那代碼庫規(guī)模擴大,問題更加復(fù)雜時,工程師就會面臨個人的“生產(chǎn)力瓶頸”時刻。
那照這么說,AI 在實際軟件工程開發(fā)中并沒有那么強的作用。
真正有用的,還是工程師。那實際工作中有“10 倍工程師”么?
根據(jù)沃奇小哥的觀察,或許“10 倍工程師”只會出現(xiàn)在特定情況下,但是他沒有見過有工程師能持續(xù)完成比普通工程師多十倍的工作量,高級工程師比普通工程師也不過快 2 倍而已。
總的來說,就是 AI 工具可以在敲代碼、寫腳本等具體工作任務(wù)中幫忙提升效率,甚至可以是 10-100 倍生產(chǎn)力提升。
但是,工作畢竟是復(fù)雜的,會面臨各種問題。比如應(yīng)用程序太大,無法在上下文中運行,開始出現(xiàn)不一致的顯示和功能;網(wǎng)站被黑,要學(xué)習(xí)保障安全的相關(guān)知識等等。
因此程序員們在現(xiàn)實工作中終究會面臨回報急劇遞減的階段。
而這些,AI 都無法解決。所以是誰在宣傳 AI10 倍生產(chǎn)力神話呢。
或許是剛接觸 AI 的新手,AI 幫忙解決某些代碼問題就覺得 AI 好厲害。也或許是 AI 創(chuàng)業(yè)公司的老板或者投資者,鼓吹他們的 AI 產(chǎn)品。
也或許是,一些 AI 培訓(xùn)商業(yè)機構(gòu),稱三個月編程訓(xùn)練營就能培養(yǎng)出媲美 4 年制大學(xué)水平的工程師。
更有可能的是,自己的老板,讓工程師陷入可能被 AI 替代的焦慮之中,這樣他們就不會辭職、尋找其他工作或要求加薪。

說了這么多,沃奇小哥就是想大家安心,回歸理性,別陷在“AI 取代工程師”的焦慮情緒之中。
不會 AI 也沒關(guān)系,選擇自己喜歡的工作方式來產(chǎn)出就好了。不喜歡 AI,就不要強迫自己去使用;喜歡 AI 編程,就享受這種感覺和方式。
他還順帶“點”了一下老板們,成為一名優(yōu)秀的 AI 領(lǐng)導(dǎo)者,要知道什么:
1、放棄 PUA:讓工程師們焦慮只會降低工作意愿,這是一種短期思維。工程師們因此發(fā)生的技術(shù)失誤最終還是公司買單。
2、摒棄“10 倍效率”幻想:過度追求效率會導(dǎo)致質(zhì)量低下。工程師和代碼庫都需要“休息”。(小哥還順帶表揚了自己的公司,說自己很幸運的在一個沒有這種問題的團隊里。)
3、信任工程師:不要因為工程師沒有使用足夠的 token 而責(zé)備他們。工程師們是受過高等教育的專業(yè)人士,如果出現(xiàn)超級驚人的生產(chǎn)力提升工具,他們會主動向領(lǐng)導(dǎo)申請專業(yè)版。
關(guān)于科爾頓?沃奇為何這位小哥這么在意 AI 編程工具在工作中的應(yīng)用。
原來,他自己曾經(jīng)就是一家開發(fā)教育類 AI 工具公司的聯(lián)合創(chuàng)始人。

2014 年,還在普渡大學(xué)讀大二的科爾頓?沃奇和兩位小伙伴一起創(chuàng)辦了 Mimir,這是一個大學(xué)計算機科學(xué)課程評分和師生反饋的 AI 工具,能夠幫助教授上傳課程大綱和作業(yè)、記錄工作、評分并與學(xué)生互動評論。
到 2017 年,他們這個產(chǎn)品就有七十所大學(xué)使用了,包括凱斯西儲大學(xué)、約翰霍普金斯大學(xué)和密歇根大學(xué)。
同年,他們?nèi)司腿脒x了福布斯教育類 30 歲以下 30 強榜單。
這個項目也入選了 Y Combinator 創(chuàng)業(yè)加速器,在 2019 年,Mimir 被 HackerRank(美國一家知名的在線編程平臺)收購,小哥就以工程經(jīng)理的身份加入,帶領(lǐng)團隊推進(jìn)新的項目計劃。
怪不得他能從項目負(fù)責(zé)人的視角出發(fā),對 AI 在真實工作場景的應(yīng)用提出這么獨到的分析。
話說回來,小哥也是告訴大家,happy work, happy life。
參考鏈接
[1]https://news.ycombinator.com/item?id=44798189
[2]https://colton.dev/blog/curing-your-ai-10x-engineer-imposter-syndrome/
[3]https://www.forbes.com/profile/mimir/?list=30under30-education
[4]https://www.linkedin.com/in/colton-voege-15a039b2
本文來自微信公眾號:量子位(ID:QbitAI),作者:奕然
本文鏈接:http://www.www897cc.com/showinfo-45-26001-0.html工程師實測各類 AI 工具:打破“10 倍生產(chǎn)力”神話
聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系,我們將在第一時間刪除處理。郵件:2376512515@qq.com