最近在思考關於 AI 到底如何真正幫助到工程師的問題，尤其是資深工程師，目前對於資深工程師效益其實並不明顯，甚至有時候會覺得 AI 反而是個干擾，因為這些資深工程師已經很熟悉他們的工作流程和工具了，面對問題也有自己長期高效的解決步驟，直接自己做可能更快一點。
那資深工程師真正需要的是什麼？理解規格？如何實作？還是一些細節上的問題？我覺得資深工程師真正需要的，是在已經知道怎麼做的情況下輔助完成無聊的部分。
Spec Driven Development（規格驅動開發）是一個不錯的方向，但是對我而言依然不夠，不夠的原因是產出的風格無法保證，或者規劃程式怎麼寫這部份跟你走不同方向，所以我重新審視一下自己開發步驟
- 先理解規格，確定要做什麼
- Spec Driven Development (可能在只在腦內發生)
- 規劃程式怎麼寫，確定要怎麼做
- 實作程式，完成程式碼
前兩步我認為是完全沒問題的，不管是 AI 做或是自己做，但我真正在意的是第三步，規劃程式怎麼寫，確定要怎麼做，這是我最不希望 AI 亂搞的地方，一方面你不好 Review，另一方面程式風格與現有專案完全不同，最後還是得重新規劃一次，這樣基本等於重寫了，所以我們在細部劃分第三步，找出 AI 能穩定介入的步驟
- 規劃程式怎麼寫，確定要怎麼做
- 自主(AI)規劃程式架構
- 寫出骨架程式碼（含精確的型別定義）
假設一個工程師很清楚他要做什麼的情況下，寫這個骨架程式碼我相信是相當輕鬆的，而且在精確型別約束的情況下 AI 並不容易超出邊界，確保邏輯的同時你也是在 Review，而且 Pure Function 在這裡發揮的價值更高，輸入的型別定義就是它的 Context，不太需要去專案裡到處撈資訊，讓程式碼本身就是提示詞，這也少讓你來來回回跟它作糾正。
型別怎麼寫會變得更重要
在這個流程裡面，型別定義就變得非常重要了，因為它不只是型別定義了，它還是 AI 的提示詞，甚至是整個 Context，所以你要確保它的完整性和精確性，這樣 AI 才能夠在這個框架下穩定地產出你想要的程式碼，另外它也是與實作最貼近的部分，你不會一直忘了改它，因為它就是程式碼的一部分了，這樣就不會有規劃和實作脫節的問題了。
之後考慮的流程
可以再將流程細分一下，找出讓 AI 介入的部分，同時也有檢核點，而非全部做完才一次看（我相信不太會有人真的認真看）
- 先理解規格，確定要做什麼
- Spec Driven Development (AI 協作)
- 確認規格 (檢核點)
- 規劃如何實作 (AI 協作)
- 確認實作規劃 (檢核點)
- 寫出骨架程式碼 (AI 協作同時確認是否符合預期)
- 讓 AI 寫出實作程式碼
- Review 實作程式碼 (檢核點)