[討論] 亞麻工作談：兩次 re-org 後，我對 AI coding 最大體會已刪文
用 AI 寫 code，前期真的很爽。
很多東西丟進去，很快就有東西跑出來。
UI、CRUD、測試、refactor，體感都比以前快很多。
但我自己用一陣子之後，慢慢發現一個問題：
AI 很會讓你在前兩週覺得自己效率翻倍。
但如果專案稍微變大，後面很可能就開始失控。
---
我自己最常遇到的大概是這幾種：
原本正常的頁面，被改一輪之後反而壞掉
UI 理解一直有落差，你以為講清楚了，它其實理解成別的東西
前面講過的規則，過幾輪就忘
context 很快塞滿，品質開始往下掉
換個 session 之後，像失憶一樣，很多東西都要重講
所以我後來慢慢有個感覺：
我後來慢慢有個感覺：AI coding 不穩，很多時候不一定是模型本身不行。
我自己看身邊同事在用 AI，很多時候還是這種模式：
開個 chat、丟需求、等它吐東西，不對就再重講一次。
這樣不是不能用，
但很難長期穩定產出。
---
我自己真正意識到這件事，是去年 Amazon 兩次 re-org 之後。
我原本做的是 Payment 系統，
每天處理上百萬筆交易，這塊我做了三年，算是很熟。
但某次 re-org 之後，我被拉去做一個新任務：
在既有的廣告 backend 裡，
接一條新的交易流程。
我第一次打開 codebase 的時候，心裡只冒出一句話：
What the hell did I just get myself into.
主專案很大，很多團隊共用，service 之間互相依賴，
很多邏輯不是你看一兩個檔案就能懂的。
更現實的是，時程也不長。
第一個月要有 beta。
第二個月要完整上線。
那時候我就很清楚，
如果我還是用以前那種方式慢慢看、慢慢接、慢慢查，
風險會很高。
不是那種「辛苦一點還是做得完」的高，
而是你根本很難在有限時間裡，建立足夠的全局理解。
所以我那時候做了一個決定：
先不要急著叫 AI 幫我生 feature。
先把自己的 AI 使用方式整理起來。
---
我後來給自己定了一條原則：
任何需要手動重複做，而且超過兩三步的事情，
都要想辦法系統化。
所以我開始做的事情，大概像是：
把常用操作整理成固定 command
把環境資訊、測試方式、規則整理成可重用的 context
可以平行驗證的事情就拆出去跑
比較明確地管理 session、規則和回饋
讓 AI 不只是回答問題，而是進入我的開發流程裡
這些東西聽起來都不炫，
但真正讓我後面速度差很多的，反而是這些。
---
老實講，第一週這樣做的時候壓力很大。
因為表面上看起來，你沒有立刻產 feature。
我還記得那時候 manager 問我一句話：
"You haven't worked on any feature?"
那時候的壓力，其實真的很大。
因為在別人眼裡，你像是在花時間整理工具，
不是在推進事情。
---
但我那時候心裡很清楚，
如果這套東西沒有先立起來，
後面只會一直卡在：
context 爆掉
規則忘記
改一處壞三處
測試一直重跑
每次都從頭解釋
這種狀況短期看起來還能撐，
但在大 codebase 裡，很容易越做越亂。
所以我後來回頭看，那一週反而是最值得投資的一週。
---
我現在對 AI coding 最大的感想，不是它能多快幫你生出 code。
而是專案一旦變複雜，
真正影響效率的，往往已經不是模型會不會寫，
而是你有沒有一套穩定的方法，讓它持續在對的軌道上工作。
我現在不太相信
「只要模型夠強，一切自然會變順」這件事。
我自己的經驗比較像是：
模型變強當然有幫助，
但如果 workflow 沒跟上，
最後只是更快把專案搞亂。
---
回頭看，去年那次 re-org 留給我最大的收穫，
不是我用了什麼模型。
而是我終於搞懂：
真正的門檻，
不是你會不會下 prompt。
而是你有沒有能力，把 AI 變成一套能長期運作的工作方式。
--
---
寫工程師在 AI 時代的轉變
也分享 AI 工作流、創業思維與矽谷職場
矽谷叔叔 Uncle Sam
learncodebypicture.com/facebook/
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 99.185.46.190 (美國)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1773816142.A.F3F.html
討論串 (同標題文章)
完整討論串 (本文為第 1 之 3 篇)：