在使用 ChatGPT MyGPT 這類工具時，常會碰到這種情況：明明已經把步驟一、二、三寫得很清楚，甚至快寫到八千字長度上限，它還是不一定照順序做，也不一定會把前一步做完才往下走。1 結果，流程不會自己穩定推進，而是使用者得一路追著它跑，不斷補盯、補問、補救。
把 prompt 寫成 pseudo code 是否就能自動解決呢？
Pseudo code 形式的提示，的確可能改善步驟描述、問題分解與推理表現；2 把部份子工作移交給外部程式處理，也可能讓某些環節更穩（這也是 agent skills 推薦的技巧）。3 但這多半只是局部的改善。
反觀某些工具，處理長串流程的穩定度會明顯高於單靠 prompt 的系統。以 Claude Code 為例，它做一長串動作時，常會在中途停下來，檢查某一步有沒有成立，再決定要不要往下一步走。4
這給了我們一個暗示，某些原本放在 prompt 裡的責任，其實應該移交給外部控制機制。5
這篇文章要談的，就是在多步驟 workflow 下，責任該怎麼重新分配。
在許多系統開發與工程教育脈絡中，C/C++ 曾長期佔據核心位置。後來主流答案逐漸分散，Java、C#、Python、TypeScript、Go 各自崛起，也都一度被期待成為下一個中心。
到了 LLM 時代，這個問題又被拿出來重問一次。從 agent、harness 與同類工具在 TypeScript、Python、Rust 等不同生態中並行發展、彼此競逐，就看得出這仍是秦失其鹿，天下共逐之的局面。1
但如果問題還停在「哪門程式語言最好」，最後多半只會得到一份偏好清單。語言模型對某種語言、生態與框架是否熟悉，當然會影響起稿速度與初稿品質；可是在「生成結果不能直接被信任」的前提下，技術選型真正該看的，是依風險分層，選擇最能支撐驗證與收斂的程式語言 × 驗證鏈組合。
這不是一篇語言排名文；這是一篇重新定義選型判準的文章。
Vibe coding 時，LLM 並不真的「聽話」。很多人因此去找更強的咒語，想拴住這匹脫韁的野馬。
但 prompt 裡寫一句「請遵守 Hexagonal Architecture」，效果其實很有限。它比較像在工地口頭交代一句「請按圖施工」：有提醒，沒有保證。最後沒歪掉，很多時候也不是因為工人真的照做，而是旁邊還有人在監工。
你真的相信 AI 會乖乖聽勸嗎？1
工程上真正有約束力的規矩，不能只停在說明、默契或設計哲學。它得能被系統檢查；必要時，能拒絕、阻斷，甚至直接讓流程停下來。
所以，談 LLM 時代的工程護欄，先抓住一個判準就夠了：這條規矩能不能被機器檢查，並在必要時改變系統的下一步。
Scrum Guide 問世至今已經超過 15 年。到了 GenAI 與 coding agents 時代，Scrum 算不算過時？
我覺得，這個問題不能只用「過不過時」來看。真正值得看的是：當 AI 已經能查 repo、寫 ticket、開 PR、跑測試之後，Agile 裡哪些工作真的被改寫了，哪些其實沒有。
現在很多團隊碰到的情況，不是工作自動做完了，而是塞車的位置換了。
你讓 agent 跑了一整晚。隔天早上，GitHub 上可能已經躺著幾個待 review 的 PR、兩三種看起來都說得通的重構方向、一些測試全綠燈卻仍讓人隱隱不安的修改，外加幾個碰了系統邊界卻未必自知的變更。 OpenClaw（龍蝦）作者 Peter Steinberger 也提過，自己曾讓系統跑上數小時，甚至隔夜處理重構；他甚至認為 “prompt requests” 也會變成新的日常。1
這裡真正變快的，是程式碼產出。沒有一起變快的，則是審查、驗收、風險辨識、責任承擔和後續決策。表面上看起來像是寫得更快，實際上常常只是把瓶頸往後推。
瓶頸既然換了位置，接下來要重看的，就不只是 Scrum 還在不在，而是整個協作方式要怎麼調整。譬如說，很多原本得靠人類口頭交換的內容，現在可以先由機器整理、摘要、比對、補齊，甚至先展開幾種可能方案。
很多人在正式會議前，本來就會先和 AI 討論，再把整理過的結論帶進會議。既然這件事早就在發生，那差別往往只剩下：團隊要不要正式承認它。說穿了，就是要不要把那隻早就在場外跑著的龍蝦，正式接進協作流程裡。
我甚至還有個瘋狂的想法。何不開一個視窗，接上麥克風與喇叭，邀請這位 AI 本尊直接進來會議現場，說不定反而更有效率，也更有火花呢。
還有哪些需要調整的呢？
OpenClaw 作者 Peter Steinberger 接受 36Kr Europe 訪談時提到，多數程式碼其實很無聊，很多時候做的只是把一種資料形狀轉成另一種。這不是他真正關心的事。 1
這句話有點刺耳，但也把一件事講得很坦白：很多工程安排用久了，就會從成本與取捨，慢慢變成預設，變成僵化的教條，沒有人過問它是否還有價值。
現在 LLM 與 coding agent 已經開始直接參與 repo 級搜尋、修改與驗證。很多原本被視為理所當然的做法，也該再檢查一次。分層是不是還在隔離風險，抽象是不是還在縮小修改半徑，某些 interface、mapper 和轉發層，到底在承擔工作，還是只是在延續習慣。
以前這些東西就算有點多、有點繞，通常也還撐得過去。工程師會靠經驗補上下文，靠默契避開麻煩，再把額外成本默默吞下來。
但 agent 介入之後，很多原本人類可以硬撐過去的地方，會直接變成搜尋成本、理解成本，最後讓修改失去準頭。
這篇想處理的問題很直接：今天系統裡哪些結構還在管理複雜性，哪些只是在維持形式？
