緣由
自己從幾年前開始用ai輔助開發，那時候還是一段code貼到gpt給我反饋，再貼回IDE，現在都已經是IDE內建了，自己有些想法，也剛好閱讀到這邊文章，順便分享
[Martin Fowler 論AI by 高見龍]<=原文
https://kaochenlong.com/vibe-coding-vs-software-engineering
從裡面截取幾段我也很認同的觀點到這邊筆記，有些觀念也值得去追尋
AI的衝擊類似的例子就是從組合語言到最早的高階語言的轉變
The comparable thing would be the shift from assembly language to the very first high-level languages.
工程師必須從根本性的改變開發思維，如果還執著在底層記憶體的操控，就不能到更新的領域做出應用
我雖然沒經歷過組語時代，但是我在高階語言開發，去看低階語言真的開發速度真的很慢，簡單的功能要寫一大堆，高階語言就是捨棄了一些底層的細節，
去換來更強大的開發能力，我也不知道哪些已有的原則應該被割捨，只能告訴自己我可能是錯的，不要執著，才能去順應變化~
AI 其中最重要的部分是從決定論到非決定論的轉變。
The biggest part of it is the shift from determinism to non-determinism.
同樣問題，可能會一直得到不同的回覆，在軟體產業一直以來我們都很習慣確定性的世界，我們寫的測試之所以有意義，是因為程式碼是確定性的，如果測試通過了，它就應該一直通過。但當你的工具本身是非確定性的，傳統的測試方法夠用嗎？ 當你用 AI 寫程式，你怎麼知道它這次寫對了，下次還會寫對？
我的理解就是AI是一位老爸，相對於孩子的我可以跟他學習，但也必須知道老爸的每句話不一定都是對的，但原則上通常不會錯太多
有趣的事，公司有用ai跑code review，同一個分支每次commit都可以看到不同的問題，想說為啥不一次說完所有問題就好，每解完一個問題commit，才提出另一個地方也有問題XD，畢竟ai就是機率性的回覆，也只能這樣了
Vibe Coding「我認為它適合用來探索、適合用來做拋棄式的東西，但你不會想把它用在任何需要長期維護的專案上」
I think it’s good for explorations, it’s good for throwaways, disposable stuff, but you don’t want to be using it for anything that’s going to have any long-term capability.
明明只是幾條曲線和標籤，卻寫成了一堆難以理解的座標點和路徑。想要手動調整幾乎不可能。這就是 Vibe Coding 的問題。當你不看程式碼的時候，你放棄了理解它的能力。而當你不理解一段程式碼，你就無法修改它。你唯一能做的就是…呃，重新來過。
如果真的沒有去理解或整理ai的產出，只靠他自己生成和debug，終究只能短期可行，只要有在看ai code的人，都應該知道如何控制輸出是很重要的事
「當你使用 Vibe Coding 時，你實際上拿掉了一個非常重要的東西，那就是『學習迴圈』。」
When you’re using vibe coding, you’re actually removing a very important part of something, which is the learning loop.
如果你不看輸出，你就沒有在學習。當你完全不看 AI 產生的程式碼時，等於跳過了這整個學習迴圈。當想法直接變成結果，中間的「程式碼」變成了一個你不關心的黑箱。短期來看這真的超爽的，簡單幾句話就能很快地做出東西，但長期來看這是可能是在斷送自己的成長。也許在未來，AI 會強到你完全不需要理解程式碼。但在那之前呢？在那之前，你是要當一個「會用 AI 但不會寫程式的人」，還是一個「會寫程式、也會用 AI 讓自己更強的人」？
這段話可能我也認同，但也質疑，因為當我只是大略的看ai code，並沒有真正的吸收，任務完成了可以交差了，像以前數學老師把東西在黑板講了一次，但是真的給你練習題，還是一片空白，
問題是如果我確實的做，我花了大量時間研究，自己當下變成限制ai瓶頸的人，也限制自己的產出，或許我還在執著時，沒想到1,2年後ai已經進步到不需要看code
所以在這個時間點，到底同事那種只用ai產出，也沒去理解的人，是正確或是錯誤，只能等未來才能判斷了
資深工程師會跟他們說：「你要先理解這段程式碼在做什麼。」「就算它能跑，你也要知道為什麼能跑。」
I feel we’ve been, there was a few years where we were going back and forth of people mindlessly copying, pasting snippets.
AI 可以產生的不只是一個片段，而是整個函數、整個類別、甚至整個專案。無腦複製貼上的誘惑更大了。Stack Overflow 至少還有一個優勢：社群驗證。在 Stack Overflow 上，一個答案會被其他人 upvote 或 downvote。會有人留言說「這個做法有問題」、「在這個情況下不適用」。你可以看到答案的分數，知道有多少人覺得它是好的。AI 給的答案沒有這種驗證
還有印象，以前在Stack Overflow找答案，下面的確會有人附議，或是提出更好的方式，但現在真的就是ai回應什麼就採用，應該沒有人還會上網在搜尋了
「如果你要產生大量品質可疑但能運作的程式碼，那麼重構就是一個讓它變得更好、同時保持它能運作的方法。」
If you’re going to produce a lot of code of questionable quality, but it works, then refactoring is a way to get it to a better state while keeping it working.
真正的重構是「小步前進」。每一步都很小，每一步都保持行為不變。這樣你可以隨時驗證、隨時回到上一步。所以，比較好的做法可能是用 AI 來幫你產生初始的程式碼，然後用你自己的重構技能來改善它。或者，訓練 AI 做小步重構，而不是大改。叫 AI 重構之前，一定要先有測試。如果有完整的測試，你可以讓 AI 改完之後跑一次測試，馬上知道有沒有改壞。如果沒有測試，那就跟把眼睛矇起來打架一樣，你不會知道什麼時候會被揍一拳。
這也是TDD又被拿出來提的原因，其實在我的開發中，只要涉及核心業務邏輯，幾乎都是用這個方式，ai生成模組，自己訂好各種基本和邊緣情況的單元測試，再來看看能不能讓ai優化演算法或記憶體，並且保持測試都通過
「我不認為 AI 會消滅軟體開發。我認為它會用一種非常顯著的方式改變它，就像從組合語言到高階語言的改變一樣，但核心的技能還是在的。」
I don’t think AI is going to wipe out software development. I think it’ll change it in a really manifest way, like the change from assembly to high-level languages did, but the core skills are still there.
有些東西是不變的，對問題的好奇心、對品質的追求、與人溝通的能力、持續學習的態度。回到一開始的問題：「AI 時代寫程式，你到底是在學習還是在偷懶？」答案取決於你怎麼用它。
軟體的核心就是解決業務上的問題，中間牽涉到的就是裡面寫到的東西，這些的確是ai取代不了的
什麼是「好的使用方式」？
- 讓 AI 解釋程式碼：「這段程式碼在做什麼？每一行分別是什麼意思？」
- 讓 AI 生成程式碼後，自己試著修改：「如果我想加一個功能，要改哪裡？」
- 遇到錯誤時，先自己想想為什麼，再問 AI：「我猜是因為 XXX，對嗎？」
- 比較不同的解法：「還有沒有其他寫法？各有什麼優缺點？」
什麼是「壞的偷懶」？
- 無腦複製貼上，不看程式碼在做什麼
- 程式碼能跑就不管了，不思考有沒有更好的寫法
- 遇到錯誤就把錯誤訊息丟給 AI，不自己嘗試理解
- 永遠只用 AI 的第一個答案，不質疑、不驗證
測試在 AI 時代變得更重要了
寫測試是為了驗證「AI 寫的程式碼」是否正確。你可能不完全理解程式碼是怎麼運作的，
但你知道你要的結果是什麼。測試變成了你和 AI 之間的「契約」，也就是說不管 AI 怎麼寫，
只要這些測試通過，我就當你是對的。
前提單元測試是自己設計的，不是ai設計，用不準的量尺去測量東西，必然得到不準的結果
把 AI 當老師，不要當代寫。
與其說「幫我寫一個 XXX」，不如說「解釋一下怎麼寫 XXX」。讓 AI 教你，而不是幫你做。你可以讓 AI 生成程式碼，但生成之後要自己讀懂它。問 AI：「這一行在做什麼？」「為什麼要用這個方法而不是那個？」「如果輸入是 null 會怎樣？」
這樣你才是在學習，而不是在偷懶。
建立你自己的驗證機制
因為你有經驗，你應該知道什麼地方容易出錯。針對這些地方建立檢查清單。每次用 AI 生成程式碼，跑過這個清單。比如說：
- 有沒有處理 edge case？
- 錯誤處理完整嗎？
- 效能有沒有問題？
- 有沒有安全漏洞？
- 跟現有的架構風格一致嗎？
Code review困境
雖然我資歷不深，但現在也會去看同事的產出，有些code很明顯就是ai原生輸出，沒有太多調整就commit，
東西一樣能跑，功能也正確，但很明顯就不是給人閱讀的code，這樣的東西到底要當作未來常態，
還是當作個人行為，以後當我是資深同事時，也很難拿捏標準去評論，也可能就是目前的執著，再以後來說根本就不是問題了~
