PTT評價

[討論] 2025初的AI程式工具實際上會降生產力

看板Soft_Job標題[討論] 2025初的AI程式工具實際上會降生產力作者
oopFoo
(3d)
時間推噓24 推:24 噓:0 →:73

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是有幫助的,但真的限定在某些非常特定情況。

--

※ PTT 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.224.192.162 (臺灣)
PTT 網址
※ 編輯: oopFoo (36.224.192.162 臺灣), 07/11/2025 15:05:56

NDark07/11 16:25我覺得體感會聲稱增加生產力。

NDark07/11 16:27來自於好像變輕鬆,不用動腦細胞,去刁那一個邏輯符號

NDark07/11 16:28但有一情況是,速度快了之後剩下來的是更多的閒置時間

NDark07/11 16:28或是更多的推倒重來的次數

NDark07/11 16:30遊戲產業發生過工具革新,結果都是更高更大更久的案子

NDark07/11 16:31因為工具越強大,越輕鬆,規劃的人反而越放鬆。

NDark07/11 16:32如果應用在對於新創,本來就是不斷pivot轉向是好事。

NDark07/11 16:34應用在一些大型案子難找的臭蟲也應該很有幫助

NDark07/11 16:35但大多數的“一般”狀況,反覆消耗的時間可能剛好抵銷加速

NDark07/11 16:40最後推論還是大PM全端時代,不只是工程師進化,而是連帶需

NDark07/11 16:40求端的人都得改變工作模式。

oopFoo07/11 16:51應該是,人都是樂觀的,所以我們評估都是樂觀的。看到ai

oopFoo07/11 16:51產出程式碼,我們就覺得很有生產力。但實際解決任務的時間

oopFoo07/11 16:52,就整體開發時間,其實不但沒變短反而變長。

oopFoo07/11 16:55就我個人不科學的觀察,整體來講ai真的是幫倒忙。兩,三

oopFoo07/11 16:56年的實驗經驗下來,對ai短期能夠大突破,沒有信心。

NDark07/11 17:00一種猜測是,瓶頸不在生產就會跑到其他地方,結果還是卡在

NDark07/11 17:00某個地方。(某個環節沒有一起更新,整體還是快不起來)

NDark07/11 17:02大PM全端,腦機介面賽博飛升,選我正解

wei11507/11 17:19和AI一起搞半天,什麼都搞不出來,一怒之下自己寫,結果

wei11507/11 17:19一小時就完成惹

jack52907/11 18:08會不會其實根本不會用?或是沒用過無上限Claude Code

FrAnKw07/11 18:27我也覺得是不會用。Claude code 真的很強

wsad5023207/11 18:34https://i.imgur.com/dkYXe8x.jpeg

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

Ekmund07/11 19:00我覺得這跟prompt技巧和專案多大有很大關係

Ekmund07/11 19:00有時得把東西講得詳細 再帶商務邏輯下去慢慢雕code

Ekmund07/11 19:00可能 直接寫比較快...

oopFoo07/11 20:53參與的人,prompt水準都很高。有的人cursor經驗很少,但

oopFoo07/11 21:00screencast都有留下來研判,這不是問題。其實問題就是,需

oopFoo07/11 21:02要一直reprompt,花太多時間在這。

oopFoo07/11 21:05code複雜時,失敗率高。其實paper講很多,有興趣可以判讀

twistfist07/11 21:30覺得這是做研究硬用吧,一般開發哪那麼頭鐵跟ai 耗

VL100307/11 23:43看人,懂用 AI 的,會知道哪部份可以丟給 AI 處理效率更高

VL100307/11 23:44,但一定有那種什麼東西都餵 AI,這也就算了,出來的東西

VL100307/11 23:44還不驗證就想拿來用... 後面收尾就浪費一堆時間。

superpandal07/12 00:42當然會 我不發表其它言論就是了

VScode07/12 00:58同VL大看法 要知道AI的優勢跟劣勢 盡量擅用AI的優點

VScode07/12 00:59讓它做一些重覆的無聊雜事 把時間拿來思考規劃

VScode07/12 00:59如果什麼都要讓AI思考 那很容易只會得到一坨大便

dildoe07/12 03:56如果IT越變越懶還是外包,歪包都大頭說的算確實perf沒多好

dildoe07/12 03:58AI又不見得會幫你拆解問題跟做實驗 說能全取代是記者說的

dildoe07/12 03:58有問題請去問記者

windmagic07/12 05:28最近才經歷一個bug丟AI解不出來,但手動debug後20分鐘

windmagic07/12 05:28就發現問題

devilkool07/12 23:29我給AI產單元測試省我不少時間

acgotaku07/12 23:47用了一陣子 roo code 上 claude 4.5 真心覺得 Claude

acgotaku07/12 23:48才是 AI 開發流的唯一解 但是實在是太貴了

acgotaku07/12 23:49Cursor 用 Claude 到限流才會去使用

acgotaku07/12 23:51Cursor 預設的128 k token 對於中小專案還堪用

acgotaku07/12 23:52大專案 + 非 Claude 的model 會改出一些很奇怪的東西

acgotaku07/12 23:56用 AI 開發流,要一直在成本跟效能之間找平衡

lance7017607/13 06:04我覺得應該用今年五月開始的AI作為一個標準。

lance7017607/13 06:04那個時間點從開始每一家都進步非常多。 二三月時我給

lance7017607/13 06:04他開發不如自己寫

Romulus07/13 06:27這個來源懷疑他們不會用……就……

oopFoo07/13 08:10當初的期待是2x~20x的生產力,今天最好的狀況是1.1x甚至

oopFoo07/13 08:12倒退。讓agent自己在我電腦胡搞,這個紅線我踩的很死,NO

oopFoo07/13 08:14prompt,context engineering,各種best practices都試了

oopFoo07/13 08:15這兩年,所謂的突破,我是沒看到,有進步,但實在有限,最

oopFoo07/13 08:17大的進步是context window大很多真的是比較好做事。

CRPKT07/13 09:00其實每種專案領域適用 AI 的程度也不一樣

CRPKT07/13 09:01有些部分我會用 AI,有些部分直接跳過

CRPKT07/13 09:02對我來說自己肉身生產力的瓶頸是認知負荷

CRPKT07/13 09:03AI 幫我幹掉細節,我只需要 review,我當日的天花板就上升

CRPKT07/13 09:04再來就是 AI 產出的內容總是要在某個地方 review

CRPKT07/13 09:05如果你資深,看一眼就知道問題,那產出當下就 review 最好

CRPKT07/13 09:06再往後退就是用其他手段 QA,也是有人這樣做

CRPKT07/13 09:06但要守得好也是要花很多心力建置測試體系

CRPKT07/13 09:07如果都不 review 就是埋地雷,等它哪天炸給你看

CRPKT07/13 09:09如果體感 AI 幫不上忙,那可能你工作內容真的 AI 扛不起來

CRPKT07/13 09:10有聽過不少公司 AI 專門拿來寫 PoC / demo 的

NDark07/13 10:51推 lance , 我覺得也是進步迭代太快的緣故

NDark07/13 10:51差一個月整個世界就不一樣

NDark07/13 10:52很多公司都在拚下一個世代的開發方法

NDark07/13 10:52而且生怕別人搶先 所以有甚麼料就趕快推出來搶市占了

alihue07/13 10:54應該要細看:如果是複雜大系統,需求都沒有規格書,AI 對

alihue07/13 10:54使用者下的promot 通常都在通靈 ,AI 只能協助拼拼湊湊;

alihue07/13 10:54如果是幾乎從0寫的,甚至有規格書,那AI 的幫助就會是倍

alihue07/13 10:54

O18707/13 11:33AI真能省時 但只能省簡單常寫的

O18707/13 11:33複雜到用文字難以形容的邏輯 我自己寫還快一點

hooll11107/13 13:20我覺得是大家還在摸索新的協作模式,現在都還是在現有的

hooll11107/13 13:20工作流程硬套AI 輔助 效率的枷鎖在人啊

TAKADO07/13 14:57叫AI寫扣其實跟帶小開發團隊很像,下的指令與需求,會被怎

TAKADO07/13 14:57麼解讀跟實作成跟規劃者預期的一樣,會是更優化,能夠一次

TAKADO07/13 14:57到位還是得反覆調整,整個生產力差太多了。

lturtsamuel07/13 20:13每個人都覺得自己很會用 ai,事實就是一堆人不會用,

lturtsamuel07/13 20:14反而靠ai製造技術債的速度提升了好幾倍,你少數人再

lturtsamuel07/13 20:14厲害根本解不掉

lturtsamuel07/13 20:18ai現在最大的問題就是學不會偷懶 對它來說改十行跟改

lturtsamuel07/13 20:18一行差不多 加上一段其實沒用處的 code 也差不多 人

lturtsamuel07/13 20:18不把關整個程式庫的複雜度就不斷上升

acgotaku07/14 02:26其實樓上這問題,也可以叫 AI 解決, 用 AI 去清理純人工

acgotaku07/14 02:27舊專案,那種"前人做的就不要動"的 code 還更多

Boska07/14 03:20光不用再寫測試跟文件爽到有剩

greenx07/14 09:40ai還在進步