看到 vscode blog 的一篇文章 (2025/05 發的): Enhance productivity with AI + Remote Dev, 覺得挺有意思的, 決定來用這篇借題發揮 (咦?) , 聊一下在什麼都要 AI 的時代, 一些基礎的軟體工程 到底還重不重要。
– 這篇文章提到了 “ AI + Remote Dev “, 其實 vscode 點到了很核心的問題。Coding Agent 到底該在哪邊執行? IDE ( vscode ui ) or Remote ( vscode server ) ?
先不講那麼遠, 半年前大家在談的各種 AI IDE ( ex: Cursor ), 很明顯的就是在 IDE 執行的 AI, 不管技術層面的話題, 他的表現就像是有個厲害的同事跟你 Pair Programming, 你跟 AI 直接互動, 共同操作同一個 IDE 來編輯程式碼 ( 真實世界的 Pair Programming 也是要共用 Keyboard / Mouse … 等於是共用同一台 “電腦” )。
而現在當紅的各種 Coding Agent, 更像是 “Out Sourcing” 開發外包, 你把需求規格等等必要資訊都丟給 AI, 不大需要太多的對談, AI 就能完成任務並提交給你 review
這樣的 Coding Agent, 如果不跟你 “共用” 同一台電腦的話，那麼 “他” 的開發環境 ( 要能編輯，編譯，執行，除錯 … ) 會在哪裡?
接著才是這篇文章的主題: 對，就是有這些問題，因此你應該把你的開發環境放在 container 上 ( 就是 dev containers )，而不是直接用你自己 PC / Mac 原生的環境來開發… 只要任何 “人” 有需要，都可以在短短幾秒鐘跑一組開發環境起來， “你” 就能在這統一的環境下進行各種開發任務。
因此，幾種場景跟對應的工具:
① “你” 自己要開發: vscode + remote dev, 直接連通到 container 內部
② “AI” 要開發: (看是誰 Host Agent, 誰負責起一套環境給他) 就地建立一組臨時的開發環境, 執行完任務之後就能刪除
③ “其他” 例如 CI / CD pipeline, 要編譯與部署也都能用同樣環境來執行
看起來很漂亮的結構，也很乾淨的解決所有環境的問題。而這篇部落格文章，就是把特定 AI + Remote Dev 會碰到的設定跟做法都交代清楚。
我看到的是背後的延伸思考, vscode + remote dev 這題去年我就碰過了, 去年我花了些時間把我主要工作環境都轉移到 WSL, 就是高度依賴 vscode 才辦到的。
你說 vscode 何時開始支援 remote dev 這厲害的功能的? 我追的到最早是在 2019/05, 厲害的是當年的設計, 竟然能跟現在的 AI 合作愉快… 我不覺得當年 vscode 團隊就能預測到現在會有這種應用, 更有可能的是 vscode 團隊根本沒再顧慮這件事, 就只是單純的把 “基礎架構” 確實地做好而已。
因為基礎都有打好，所以任何 “合理” 的設計，自然而然就能接上，這才是基礎建設最有價值的地方。AI + Remote Dev 正好是這樣，其他類似的案例也還不少，我就挑幾個跟 AI 相關的來說就好:
ℹ️ SDD ( Spec Driven Development ) - 這也是最近熱門話題之一, 先寫好規格, 就能大幅提高 Agent 替你寫 code 的效率。寫好 Spec 文件是新觀念嗎? 不，三四十年前軟體工程就在談這件事了, 只是當時寫完整文件的成本太高，大家都 “選擇性” 忽略，只專注在真正能交付執行的 Code ..
➡️ 現在 SDD 再次告訴你 SPEC 很重要了，你現在才要開始掌握怎麼寫好規格嗎?
ℹ️ TDD ( Test Driven Development ) 提倡先寫測試再寫程式, 背後隱藏的要求是先定義介面 ( Contract, or Interface )。我自己用這流程，跟 AI 協作的效率大增，因為對我而言，Review Test 比 Review Code 輕鬆 (因為目的更明確，範圍更收斂)。所以如果有完善的測試輔助，AI 寫的很多有問題的 Code 不用我 Review 就會被抓出來，大幅降低了我 code review 的壓力。
➡️ 現在 TDD 再次告訴你寫測試很重要了，你現在才要開始掌握怎麼寫好測試嗎?
其他很多例子，資安、監控、維運等等都一樣，我就不列舉了 ( 例如上週很火的 Vibe Coding + APIKEY 事件也是 )。 這些案例背後核心觀念其實都是幾十年以上的東西了，如果你早就有打好這些基礎，其實靠 AI 來提升效率應該是很有感的吧。如果你是看到 GitHub 前陣子推出 Spec-Kit 才開始認真按照他的要求寫規格，你的效率就落後其他早就有做這件事的人了
– 如果要講結論，我會覺得: 軟體工程 ( 基礎工程 ) 仍然很重要，只是它因為 AI 的問世，換了一種形式存在，依舊持續發揮效益。
AI 越厲害，越會凸顯各個領域的基礎工程的重要性。AI 就是擬人化的智慧服務，你可以用自然語言要求他替你辦事。要解決多個人之間協作的開發效率，不就是 “軟體工程” 這門學問的目的嗎?
如果你要做的事情是重要的 ( 不能出錯，可靠度要夠等等 )，那這些基礎工程其實都省不掉的，可以省掉的是你把它做好的 “時間” 跟 “資源”，都可以因為 AI 大幅降低。重點是你要知道怎麼做，以及在 AI 幫你做這些事 ( 寫 SPEC, 寫 TEST ) 的時候你有能力 Review
這也是為何 AI 時代下，資深的人員比剛入行的人有更大優勢的原因。不是因為他年資久，是因為他已經具備能跟 AI 更好合作的基礎工程知識。
– 文章連結, 我貼在留言.. 祝大家中秋節快樂～
