🔧 阿川の電商水電行
前言
大家好。我是一隻想成為鳩胸的文鳥。
教授回答程式問題
有一天我在看 YouTube 時，遇到了一支有趣的影片。
Professor Answers Coding Questions | Tech Support | WIRED
這是一位加州大學伯克利分校的計算機科學教授，回答觀眾關於程式設計和人工智慧的問題的影片。教授用簡單明瞭的英語闡述了以下問題：
- 在 AI 時代，學習程式設計還有意義嗎？
- ChatGPT 真的革命性嗎？
給觀眾的回答留給我深刻的印象。這是一個大約一個月前上傳的影片，已經吸引了百萬次的觀看數。
在回答「融合 AI 開發的最佳方式是什麼？」這個問題時，教授的第一句話是「真的需要這樣做嗎？」。接著他得出「確認 AI 代碼的正確性成本很高，只需要使用它就好」的結論。
在回答「資深開發者如何看待即時編碼？」的問題時，他則表示「在做新事物時幾乎沒有幫助」。
我對他採取這麼斷然否定 AI 用於開發的立場感到有些意外，因為我認為 AI 的應用對開發有著正面的影響。
資深開發者認為使用 AI 會讓開發速度提高 24%，但實際上卻約慢了 20%
影像中我最感興趣的話題是「資深開發者認為使用 AI 會讓開發速度提高 24%，但實際上卻約慢了 20%」的研究結果。
對我來說，這個話題非常有趣，因為我感覺我的直覺與實際生產力之間可能存在著偏差。
我發現自己開始尋找原始論文。
原始論文
我認為這篇論文應該就是指這個。
- 2025年2月至6月
- 最近的研究
- 參與超過5年的開源倉庫
- 當開發者對代碼庫有背景知識時
- 受試者為16人
- 人數太少了
- Cursor Pro x Claude 3.5/3.7 Sonnet
儘管 AI 工具被廣泛採用，但其在實際軟體開發中的影響仍然未受到充分研究。我們進行了一項隨機對照試驗（RCT），旨在了解在 2025 年 2 月至 6 月的邊緣，AI 工具如何影響經驗豐富的開源開發人員的生產力。16名對 AI 有中等經驗的開發者在他們平均擁有 5 年經驗的成熟項目中完成 246 項任務。每項任務隨機分派是否允許使用 2025 年初的 AI 工具。當允許使用 AI 工具時，開發者主要使用著名的代碼編輯器 Cursor Pro 和 Claude 3.5/3.7 Sonnet。在開始任務之前，開發者預測允許 AI 將使完成時間縮短24%。完成研究後，開發者估計允許 AI 實際上使完成時間縮短 20%。令人驚訝的是，我們發現允許 AI 實際上使完成時間延長了 19%-- AI 工具使開發者變得更慢。這一減速與經濟學專家（預測縮短39%）和機器學習專家（預測縮短38%）的預測相矛盾。為了理解這一結果，我們收集並評估了 20 種可能促成觀察到的減速效應的場域特徵的證據，例如項目的大小和質量標準，或者開發者對 AI 工具的先前經驗。儘管不能完全排除實驗人工制品的影響，但我們的分析中減速效應的穩健性表明，它不太可能主要是實驗設計的結果。
有興趣的朋友可以參考以下的全文 PDF。
這篇文章的網址整體而言也整理得很好。
論文的目的是研究在什麼條件下使用 LLM 是有效的，並不是為了無目的地否定 LLM 的使用。
他提到熟練使用 Cursor 可能會改變結果。
開發者是初學者使用 Cursor/AI 工具嗎？這解釋了結果嗎？
開發者似乎在 Cursor Pro 使用者方面質量上是合格的，儘管我們不能排除 50 小時以上的 Cursor 使用的學習效應。
這些結果是否意味著 AI 在軟體工程中沒有用？
不—AI 工具在許多不同於我們環境的其他情境中似乎是有用的，例如對較缺乏經驗的開發者，或在不熟悉的代碼庫中工作的開發者。
reddit 上的討論如下。
- 當團隊開發中有使用 LLM 的人進來時，評審時間會變長
- 有時候 AI 寫的代碼，其他人也需要用 AI 進行評審，造成煩躁
- 需要進行上下文切換變得困難
- 即使開發者並不生產，也會感到更有生產力
- 現階段的 LLM 應用似乎是由初級開發者主導
- 用於小部分或測試時，會非常快速結束，因此非常方便
- 16 人的樣本數量太少
- 開發者（或更廣泛的人類）對工具實際上對生產力的影響評估很差。在 AI 的情況下，通常會過高評估其優勢
以上是討論的內容。
在日本的社交媒體上，看起來支持 AI 的人是大多數，所以這種討論的內容略顯意外。
=====================================
⇩接下來是一年來我對編程助手使用的反思，想更詳細了解研究結果的人可以從上面的鏈接去查閱。
使用編程助手一年的感受
我在 2025 年初開始使用。
我是一名擅長後端的工程師，對於一個對 React 依賴性極高而且管理狀態變數相當複雜的專案，我記得當 Claude 3.5 一下子解決問題時，我非常驚訝。
這次經歷促使我開始嘗試各種 AI 的應用，當 Claude Code 出現時，我不禁期待半年後、一年後會變得怎樣！
為了將 AI 融入開發，我自願分配了私人時間。
我感到這是一個奇妙的過渡時期，就像身處於一場範式轉移的漩渦中。
就我的感受而言，2025 年上半年與下半年的進化及驚人變化感覺相對較少。
每次出現新模型時，我仍會感到它變得更聰明，但與第一次使用 AI 編程助手時那種感動相比，已經不存在了。
不過，無論是代碼補全還是其他用途，自我感覺這已經變成我日常生活中無法或缺的工具。
批判性探討 AI 在開發中的應用
實際成果判斷困難
我擔心的是 AI 實際上是否對生產力有影響，而是更側重於舒適度和樂趣，這也是我訂閱的原因，我無法檢驗 AI 的實際價值。
我的印象是
- 作業的速度得到了提高
- 自己的 PR 似乎總是處於評審狀態，讓人感到疲憊
- 感覺發出指示的自己是瓶頸
- 專注力無法持續
- 在測試、性能改進、SQL 和依賴性調查等方面非常有幫助
- 還沒有感覺到開發者使用 AI 會對商業價值創造產生重大貢獻
大致就是這種感覺。
有時候在測試時期結束後，會有一種像校隊活動般的感覺，手寫代碼的感覺一度變得鈍化。
持續被強迫使用的風險
當我抱持相當悲觀的看法時，
編碼技能會退化
⇩
即使 AI 助理價格昂貴也無法解約這種情況的發生讓我感到害怕。
訂閱服務應該在追蹤流失率，可能有服務會認為，「如果讓用戶的能力退化，他們的依賴程度會上升。」
這讓我想到，如果依賴程度一旦上升，價格調漲將會非常痛苦。
有時會硬著頭皮在 AI 使用中堅持
我曾經有過多次指示 AI 卻無法成功的經歷，不斷調整指示語言的情況。
這反而成為了我的問題，而非 AI 使用的生產性。
不過，我發現這種情況有些像隨意持續使用社交媒體，或是在面對一款遊戲時明明感到挫折卻又無法輕易放棄的心情。
每當事情順利進行時，腦中的多巴胺會激增。
那次經歷也深深印在我的心中。
我想這種感覺就像賭徒所說的「大致概括起來，收入是持平的」一樣。
也許我正在扭曲我的認知，以符合我自己的便利。
導致多巴胺被控制的現象也讓我開始思考，過度依賴 AI 助理的現階段應該有所控製。
作業速度提升的感覺可能是刻意被設計的體驗
在指示給 AI 並看到代碼順利生成的過程中，可能設計成了一種用來讓人感受到作業流暢的使用體驗。
我想了很多。
準確地評估使用 AI 所產生的成果是非常困難的。
生產力究竟是什麼？
我認為
可提供給用戶的價值 / 資源
就是生產力。
在過去的編程過程中，我時常想到對用戶有益的規範或解決方案。
即使能夠加快編碼的進程，但如果還是需要人類工程師進行審查，這是否能算做生產力的提升呢？換句話說，這是否在價值創造上是最優解呢？
我對這一點產生了思考。
我確實感受到，使用 AI 能讓可運行的成果展示給利益相關者，並進行修正，這絕對是一大優勢。
我認為，必須意識到所產生的功能數量或代碼量 / 資源並不是生產力的定義，因而在使用 AI 時謹慎行事。
編碼僅僅是工程師工作的一部分
在開發過程中，工程師通常會遵循以下步驟：
① 認知問題
② 決定解決方案
③ 確定代碼方針
④ 撰寫代碼
⑤ 整理，如格式化等
⑥ 測試
⑦ 自我評審
⑧ PR 評審和回應
⑨ 測試雖然使用 AI 後的第五步及其後的步驟大幅增加，但感覺第四步卻縮短，使得進度加快！！！
我曾經這樣認為。
但使用 AI 後，發現自我評審的時間相對延長，這是相當辛苦的。
根據評審意見進行回應的時間也隨之延長。
為了使 AI 留下上下文，我甚至需要對每一行進行命令編輯。
能運行後的響應時間延長。
即使在評審階段遇到問題，假使我已經了解意圖卻有時也還是要問 LLM。
即便如此，我仍然有一種「總體來說速度是變快的！！」的強烈信念。
對評估的影響
① 技術水準高的優秀工程師
② 非常優秀的工程師
③ 優秀的工程師
④ 普通工程師
⑤ 一般般的工程師
⑥ 不及格的工程師當我思考是否在使用 Cursor 或 Claude 後，其優劣的排序會發生變化，我的答案是否定的。
不論好壞，現在只有支付的金額形成一個影響，還沒有其他影響到工程師的優劣。
周邊有工程師會說「AI 生成的代碼太便宜，因此我基本上不使用」，而這些工程師與積極使用 LLM 的工程師相比，並沒有在評價上跌落。
加州大學伯克利分校的教授可能也有類似的感受，技術越成熟的工程師越能冷靜地評估 AI 的成果，並且在撰寫代碼方面能夠取得更大的成果。
雖然其精度日益提高並變得高效，但我依舊感覺這並未引發真正的範式轉移。
AI 不會承擔責任
這是一個非常顯而易見的觀點，但我認為這是 AI 應用上，未能根本發生重大變化的主要原因之一。
例如，當非工程師使用編程助手時，幾乎在所有情況下都能產出「符合預期的運行結果」。
但有時候，無法確認可能影響不希望影響的地方的結果，這是很難的，這也是情理之中。
即使將編程這一行為移交，責任卻不容易轉移。
① 確保按預期運行
② 確保不會影響不預期的地方
③ 從非功能性需求的角度沒有問題
④ 能夠針對未來的變更要求進行設計
⑤ 在技術限制下是否有更好的解決方案工程師在構建產品時會考慮這些，但如果依賴 LLM，可能會犧牲第二個及後面的要素。
這樣的 PR 需要對待得像初級工程師的 PR 一樣謹慎
- 增加一名評審者
- 輕微的修正可以讓自動化助手處理
這樣的規則也可能會被一種思維所影響，即使用 AI 是否綜合起來提高了性價比。
輕微的修正由工程師在其他任務空檔處理，能夠迅速降低評審成本。
我們餵給 LLM 的學習資源中，代碼的解釋是由工程師書寫的。
對 AI 的成果進行指示時，必須使用工程師的語言才會有更好的精確性是理所當然的。
我曾經想過，這並不代表用語的範疇不同。
我尚未找到其他有效的使用方式，以幫助工程師周圍的人有效地使用自動化助手，除非他們理解工程師所承擔的責任並且移交其責任範圍。（在驗證規範方面，向倉庫發出問題的使用方法非常有效。）
如果 AI 能夠得知「這項更改造成的損失為 XXX 元」這種上下文，並自動執行未在自動測試中註明的測試，並在實際發生問題時能承擔賠償責任，那將是革命性的變化。
這就是 AI 承擔責任的世界。
如何使用 LLM
在這幾年中，具備通用型的人才能夠在與他人溝通的過程中，持續在與 AI 的互動中拓展其領域。
長期的戰略應考慮，設法減少參與項目的 AI 的人數。
即使只移交作業，對整體生產力的提升也並不大，因此思考責任的移交至關重要。
在更加特定的領域加深精通程度，或拓展至相關領域，也就成了關鍵所在。
專業知識變得越來越容易接近，我認為主動進行決策的動力和在邊界不明的領域中推進的價值變得更高。
這一點在一年前的思考中幾乎沒有改變。
發掘出 AI 使用成功的工作和領域的共通點，定義出容易交給 AI 的工作是相當重要的。
總結
隨著 LLM 的持續進步，情況將會發生變化。
另一方面，我認為在網路上提供 LLM 資源的背景也在逐漸消耗，未來是否會有一場突如其來的範式轉移，我個人非常關注。
從長遠來看，若每個人都開始使用 LLM，這將減少 AI 學習資源的增長率，也令我對 AI 的發展會因而受到什麼影響充滿疑問。
無論如何，我將努力提升自己的工程師能力，並尋求在與 AI 互動中更好的方法。
以上，
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
