GDG Cloud Taipei：在 AI Native 時代，還需要軟體工程嗎？
Denny Huang(SITCON 共同創辦人、GDG Cloud Taipei 主辦人)一開場就丟出一個挑釁性的問題：他在 SITCON Summer Camp 教學生 SDLC，但在 coding agent 的時代，這件事還有意義嗎？
他的答案，就是整場演講的核心論點：
在 AI Native 時代，output 產生得更快——正因為如此，人類的判斷、邊界、交付與驗證，反而變得更關鍵，而不是更不重要。
把 CI 當成一個「Harness」
核心概念是重新定義 CI。它不只是 push → test → deploy：
CI 是把人類的判斷、AI 的 output，以及系統的邊界，轉化成可驗證的工程契約。
SDLC 的每一個階段，都對應一個 Harness 的提問：
| 階段 | Harness 的提問 |
|---|---|
| Request & Analysis | 我們解決的還是同一個問題嗎？ |
| Design | 邊界與契約還站得住腳嗎？ |
| Coding | 新的變更是否已經穩定下來？ |
| Testing | 這個 output 能被採用/使用嗎？ |
| Maintenance | 下一個接手的人能安全地繼續嗎？ |
教學上的實驗
Denny 沒有先教方法論，反而反其道而行：只給學生 pain point，讓他們直接用 coding agent 動手，然後讓他們親身經歷混亂。SDLC 的價值，就是從那場混亂裡由內而外被發現的。之後才進入演化(增加功能)與協作(組間互換專案)的階段。
真實的專案是：SITCON Flickr Photo Finder，一個讓主辦單位能找到活動照片的工具。所有照片都以一份 Google 試算表作為 single source of truth 進行索引，並由多個並行的 sub-agent(Claude、Gemini、Codex)負責標記——這個設計刻意做到跟模型無關，不依賴單一供應商。
Git 歷史說的話
這個專案的 git growth report 很有說服力：10 天內從 0 行成長到約 32,000 行。但最讓我印象深刻的數字是：124 次 docs commit，對比 109 次 feat commit——文件比功能還多。Harness 讓寫文件成為流程的一部分，而不是事後補上的東西。
我帶走的想法
- 用 sub-agent 做模擬使用者訪談。 在啟動 agent 之前，orchestrator 會先檢查 workspace(
git status --short)並閱讀 repo 裡的關鍵文件；確認之後，才會啟動 6 個並行的 agent，各自扮演不同角色(社群、設計、行銷、公關、metadata、infra)，並以那些文件為根據。 - ADR(Architectural Decision Record)作為架構的記憶。 agent 在不同 session 之間沒有記憶，而 ADR 就是讓過去決策的脈絡得以留存的機制。它就像 MEMORY.md，只是專門用在架構上。
- 把 Testing 當成一道「採用邊界」。 明確定義哪些事可以自動發生，哪些必須暫停等待人類判斷。他們真實遇過的案例：透過統計分布偵測到 lazy output(AI 敷衍了事的輸出)——某個相簿裡的人數計數值集中得可疑，因而觸發了一次稽核。
- 關於 evals。 當 output 是 AI 生成的，TDD → tests → Skill → Evals 這條流程是合理的。對 Java/Spring Boot 來說，JUnit + AssertJ + Mockito 本身就已經是足夠可驗證的規格。但也要留意這些陷阱：對 eval 過度擬合、只測量容易測的東西而不是重要的東西、產生錯誤的信心，以及維護成本——eval 跟 test 一樣，也會隨時間變得過時。
這跟兩天前的 WordPress Meetup 直接呼應：AGENTS.md / MEMORY.md / SKILL.md 這套框架，再次以新興標準的姿態出現。