https://secondthoughts.ai/p/ai-coding-slowdown
ycombinator 的討論
https://news.ycombinator.com/item?id=44526912
其實都是討論這篇，"衡量 2025 年初人工智慧對經驗豐富的開源開發人員生產力的影響 "。
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
ycombinator 的討論
https://news.ycombinator.com/item?id=44522772
full paper
https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study.pdf
看討論，蠻有趣，各種理由解釋或不信。
但這研究還蠻紮實的。16個人，246個任務。
https://i.meee.com.tw/dkmxs57.png
很有趣的是，每個人都預估生產力有增加，包含開發者本身。開發者寫完後還是認為生產力有增加，但實際生產力是下降的。
個人是ai是有幫助的，但真的限定在某些非常特定情況。

我覺得體感會聲稱增加生產力。來自於好像變輕鬆，不用動腦細胞，去刁那一個邏輯符號但有一情況是，速度快了之後剩下來的是更多的閒置時間或是更多的推倒重來的次數遊戲產業發生過工具革新，結果都是更高更大更久的案子因為工具越強大，越輕鬆，規劃的人反而越放鬆。如果應用在對於新創，本來就是不斷pivot轉向是好事。應用在一些大型案子難找的臭蟲也應該很有幫助但大多數的“一般”狀況，反覆消耗的時間可能剛好抵銷加速最後推論還是大PM全端時代，不只是工程師進化，而是連帶需求端的人都得改變工作模式。

應該是，人都是樂觀的，所以我們評估都是樂觀的。看到ai產出程式碼，我們就覺得很有生產力。但實際解決任務的時間，就整體開發時間，其實不但沒變短反而變長。就我個人不科學的觀察，整體來講ai真的是幫倒忙。兩，三年的實驗經驗下來，對ai短期能夠大突破，沒有信心。

一種猜測是，瓶頸不在生產就會跑到其他地方，結果還是卡在某個地方。（某個環節沒有一起更新，整體還是快不起來）大PM全端，腦機介面賽博飛升，選我正解

和AI一起搞半天，什麼都搞不出來，一怒之下自己寫，結果一小時就完成惹

會不會其實根本不會用？或是沒用過無上限Claude Code

我也覺得是不會用。Claude code 真的很強

樓上的圖是真實使用經驗, 目前對程式領域來講會浪費時間

我覺得這跟prompt技巧和專案多大有很大關係有時得把東西講得詳細 再帶商務邏輯下去慢慢雕code可能 直接寫比較快...

參與的人，prompt水準都很高。有的人cursor經驗很少，但screencast都有留下來研判，這不是問題。其實問題就是，需要一直reprompt，花太多時間在這。code複雜時，失敗率高。其實paper講很多，有興趣可以判讀

覺得這是做研究硬用吧，一般開發哪那麼頭鐵跟ai 耗

看人，懂用 AI 的，會知道哪部份可以丟給 AI 處理效率更高，但一定有那種什麼東西都餵 AI，這也就算了，出來的東西還不驗證就想拿來用... 後面收尾就浪費一堆時間。

當然會 我不發表其它言論就是了

同VL大看法 要知道AI的優勢跟劣勢 盡量擅用AI的優點讓它做一些重覆的無聊雜事 把時間拿來思考規劃如果什麼都要讓AI思考 那很容易只會得到一坨大便

如果IT越變越懶還是外包,歪包都大頭說的算確實perf沒多好AI又不見得會幫你拆解問題跟做實驗 說能全取代是記者說的有問題請去問記者

最近才經歷一個bug丟AI解不出來，但手動debug後20分鐘就發現問題

我給AI產單元測試省我不少時間

用了一陣子 roo code 上 claude 4.5 真心覺得 Claude才是 AI 開發流的唯一解 但是實在是太貴了Cursor 用 Claude 到限流才會去使用Cursor 預設的128 k token 對於中小專案還堪用大專案 + 非 Claude 的model 會改出一些很奇怪的東西用 AI 開發流，要一直在成本跟效能之間找平衡

我覺得應該用今年五月開始的AI作為一個標準。那個時間點從開始每一家都進步非常多。 二三月時我給他開發不如自己寫

這個來源懷疑他們不會用……就……

當初的期待是2x~20x的生產力，今天最好的狀況是1.1x甚至

其實每種專案領域適用 AI 的程度也不一樣有些部分我會用 AI，有些部分直接跳過對我來說自己肉身生產力的瓶頸是認知負荷AI 幫我幹掉細節，我只需要 review，我當日的天花板就上升再來就是 AI 產出的內容總是要在某個地方 review如果你資深，看一眼就知道問題，那產出當下就 review 最好再往後退就是用其他手段 QA，也是有人這樣做但要守得好也是要花很多心力建置測試體系如果都不 review 就是埋地雷，等它哪天炸給你看如果體感 AI 幫不上忙，那可能你工作內容真的 AI 扛不起來有聽過不少公司 AI 專門拿來寫 PoC / demo 的

推 lance , 我覺得也是進步迭代太快的緣故差一個月整個世界就不一樣很多公司都在拚下一個世代的開發方法而且生怕別人搶先 所以有甚麼料就趕快推出來搶市占了

應該要細看：如果是複雜大系統，需求都沒有規格書，AI 對使用者下的promot 通常都在通靈 ，AI 只能協助拼拼湊湊；如果是幾乎從0寫的，甚至有規格書，那AI 的幫助就會是倍數

AI真能省時 但只能省簡單常寫的複雜到用文字難以形容的邏輯 我自己寫還快一點

我覺得是大家還在摸索新的協作模式，現在都還是在現有的工作流程硬套AI 輔助 效率的枷鎖在人啊

叫AI寫扣其實跟帶小開發團隊很像，下的指令與需求，會被怎麼解讀跟實作成跟規劃者預期的一樣，會是更優化，能夠一次到位還是得反覆調整，整個生產力差太多了。

每個人都覺得自己很會用 ai，事實就是一堆人不會用，反而靠ai製造技術債的速度提升了好幾倍，你少數人再厲害根本解不掉ai現在最大的問題就是學不會偷懶 對它來說改十行跟改一行差不多 加上一段其實沒用處的 code 也差不多 人不把關整個程式庫的複雜度就不斷上升

其實樓上這問題,也可以叫 AI 解決, 用 AI 去清理純人工舊專案,那種"前人做的就不要動"的 code 還更多

光不用再寫測試跟文件爽到有剩

ai還在進步

目前把ai當提示符號比較妥當，當解決方式會被牽著鼻子走