最近在社群上看到不少人轉發這句話：
“You’re not a senior software engineer in 2026 unless you can rebuild Claude Code (the most basic of agents).”
—— Geoffrey Huntley, if your team is too busy doing their ‘normal job’ to experiment with AI, you’re preparing them to be replaced，2026/10/09
先講清楚我的位置：我帶的團隊現在就在做 Agent Infrastructure，我自己也每天使用 AI coding tools。這篇不是 AI 懷疑論，更不是想否定 AI 對 software engineering 的影響。相反地，我認為 AI 正在大幅改變工程師的工作方式，但我不同意的是：為什麼能不能重建 Claude Code，會成為判斷一個人是不是 senior software engineer 的門檻？
Huntley 自己在文章裡提到：
“It’s not that hard to build a coding agent. 300 lines of code running in a loop with LLM tokens.”
如果一個基本 coding agent 只需要幾百行程式碼就能實作，那這件事到底是在衡量 engineering seniority，還是在衡量一個人對 AI tools 的熟悉程度？
這兩者不是同一件事。如果大家都開始準備如何實作一個 300 行的 coding agent，這個門檻很快就可能變成下一道 LeetCode。我們只是把面試題目換了，卻沒有解決真正的問題。
AI Literacy、AI Proficiency 與 Engineering Seniority 是三件不同的事
我認為現在很多討論混淆了三種能力。
AI Literacy：你是否理解 Context Window、Tokenization、Inference、Tool Calling，以及 LLM 的基本限制。
AI Proficiency：你是否能有效使用 Claude Code、Codex 等工具，在真實的 Codebase 中完成工作。
Engineering Seniority：你是否能在複雜、不完整的條件下，運用 Domain Knowledge 做出成熟的工程判斷，理解 Trade-offs，並對結果負責。
這三種能力有關聯，但不能畫上等號。
一個 junior engineer 可能非常擅長 Claude Code，能夠快速產出大量高品質的程式碼。
一個 senior engineer 可能不熟悉 Tokenization 的細節，卻能夠在系統設計時，提前識別架構風險、相容性問題與未來的維護成本。
我們不能只因為前者更熟悉 AI 工具，就認定他更 Senior。同樣地，也不能因為後者有十幾年工作經驗，就假設他的每個判斷一定更好。Seniority 不是年資，也不是工具熟練度，而是經過實際問題驗證的 Engineering Judgment。
AI 讓產出變便宜，但不代表驗證也變便宜
AI 改變了 software engineering 的一個重要經濟條件：
Code Generation 的成本正在快速下降。
過去需要幾天才能完成的 prototype，現在可能幾個小時內就能產生。AI 可以生成大量的程式碼、相當完美的 test cases、module refactoring，甚至協助完成複雜的跨檔案修改或者跨 feature 修改。但有一件事情沒有以相同速度變便宜：
判斷這些產出是否真的符合系統需求。
這裡的驗證不只是確認 code 能不能 compile，或 unit tests 有沒有通過，而是：
- 這個設計是否符合現有系統的架構 / design pattern？
- 它是否引入新的 security 或 reliability risks？
- 是否破壞原本隱含的 compatibility contract？
- 在 production 的實際條件下是否仍然成立？
- 三個月後，這個決策會不會成為新的 technical debt？
AI 可以幫助我們加速部分驗證工作，但它不會自動知道每個系統所有的隱含約束。而且當產出的程式碼越來越多，驗證的範圍與複雜度也可能跟著增加。這也是為什麼我認為，在 AI 時代，domain knowledge 不但沒有失去價值，反而變得更重要。
Domain knowledge 給你的不只是知識，而是判斷能力
我會把 domain knowledge 帶來的價值分成三個部分。
Taste — 知道什麼是好的設計
當幾個方案看起來都可行時，工程師能夠根據系統限制、未來演進方向與維護成本，判斷哪個方案比較適合。
Test — 知道該驗證什麼
工程師知道系統可能在哪裡出錯，也知道哪些看似正常的訊號，其實無法證明功能真的正確。
Priority — 知道什麼值得做
我個人認為這可能是最重要，也最容易被低估的能力，取捨的能力。
AI 可以讓你更快完成一個 feature，但如果這個 feature 本來就不值得投入，那麼更快完成它，並不代表創造了更多價值。
其中 Test 特別值得拿出來討論。我用一個 AOSP 的例子說明。
可以 compile 並且 run 但卻沒有達成預期效果的 SELinux 規則
假設需求很簡單：讓一個 Android App 執行在自己的 SELinux domain 裡，而不是使用既有的共用 domain。AI tools 可能可以很快的在 seapp_contexts 加入這樣一條規則：
user=_app isPrivApp=true name=com.example.myapp domain=myapp_app type=privapp_data_file levelFrom=user這條 policy 看起來很合理：它指定了 App 名稱，也指定了想要的 SELinux domain，接下來的驗證結果可能是：
| What to verify | result |
|---|---|
| SELinux Policy 編譯 | 通過 |
| 裝置開機 | 正常 |
| App 功能 | 正常 |
dmesg | grep avc | 沒有相關 Denial |
所有訊號看起來都正常，但問題是：App 真的執行在 myapp_app Domain 裡嗎？ 不一定。
在 Android 的 seapp_contexts 選擇邏輯中，規則並不只是依照檔案順序或 Package Name 的精確程度來決定優先權。以這個案例涉及的選擇條件來說，seinfo 的優先順序可能高於 name。如果 App 使用 platform signature，並透過 mac_permissions.xml 取得 seinfo=platform，系統中又存在這類規則：
user=_app seinfo=platform domain=platform_app type=app_data_file levelFrom=user那麼在相關條件都符合的情況下，App 可能優先 match 這條規則，而不是你新增的、指定 Package Name 的規則。實際結果仍須依 Android 版本、完整 policy 與 selector 條件確認。如果最後 App 落在 platform_app，而這個 domain 已經允許它所需的操作，那麼：
- App 可以正常執行。
- SELinux 不一定會產生 Denial。
- 新增的
myapp_app規則可能根本沒有被使用。
這時候，compile 成功、App 正常、沒有 AVC denial，都無法證明你的需求已經達成。你需要直接檢查 process 的實際 security context：
adb shell ps -AZ再確認相關 process 是否真的執行在預期的 domain。還有另一個容易忽略的地方：Android App 可以宣告額外的 process，例如：
android:process=":daemon"這會讓實際 process name 與主要 App process 不同。對依賴 name= selector 的規則而言，也必須確認這些 process 是否正確匹配。這個例子的重點不是 AI 一定會產生錯誤的 SELinux 規則。真正的重點是：所選擇的驗證方式 (what to verify)，可能根本無法驗證 policy 真的有被正常啟用。
懂 AOSP 與 SELinux 的工程師，會知道應該確認實際 process domain，而不只是觀察 compile、boot 與 AVC logs。這種判斷來自 domain knowledge，而不是對 tokenization 的理解。
同樣的問題也會出現在 Agent Infrastructure
換一個我現在更常接觸的領域。
之前做 agent runtime 有 authorization layer，負責確認 agent 是否有權限呼叫特定工具。系統裡有完整的 authorization implementation，也有相對應的 unit tests。在一次 code change 之後，意外造成主要 execution path 不再呼叫 authorization。結果就變成：
- Authorization code 還在。
- Authorization unit tests 全部通過。
- Agent 仍然可以正常呼叫工具。
- 但真正的 enforcement 已經從執行路徑上消失。
這跟前面的 SELinux 案例有相同的 failure pattern。
The signal you are checking does not cover the property you think it covers.
測試全部通過，不代表 security enforcement 一定有接到實際的執行路徑，非常有可能單純就是沒 cover。沒有 AVC denial，也不代表 SELinux rule 一定有生效。
這種問題不是靠產生更多 Code 就能解決的。你必須理解系統的 trust boundary、control flow，以及真正需要驗證的 security invariant。對 Agent Infrastructure 而言，這可能意味著你需要做 negative tests，確認沒有授權時請求確實被拒絕，甚至刻意移除 enforcement，檢查測試是否能偵測到問題。
這就是我所說的 engineering judgment。
AI 是乘數，domain knowledge 是被乘數
AI is the multiplier. Domain knowledge is what it multiplies.
還記得我在 podcast 上面說過，AI 能夠放大一個工程師的產出能力，但放大之後的成果品質，仍然取決於工程師能不能理解問題、判斷方向，以及驗證結果。一個具有深厚 domain knowledge 的 senior engineer，使用 AI 後可能不只是寫得更快，而是能夠：
- 更快探索不同的架構方案
- 更早識別錯誤假設
- 更有效率地驗證技術風險
- 把時間從 code generation 轉移到 engineering decisions
不過，我也不認為這代表 senior engineer 在所有情境下都比 junior engineer 更有價值，這裡還有一個經常被忽略的因素：
What does your team actually need right now?
團隊需要的能力，取決於它現在處於什麼階段
假設有兩位工程師，
第一位是 junior engineer，非常擅長 Claude Code，能夠在一天內完成別人可能需要一週的工作。
第二位是 senior engineer，擁有深厚的 domain knowledge、成熟的 architecture judgment，但使用 AI tools 的熟練程度普通。
誰對團隊更有價值？
答案是： It depends.
當團隊需要的是 Execution
如果 business direction 已經非常明確，architecture 已經決定，requirements 清楚，工作也已經拆解成明確可執行的 tasks。
那麼團隊現在最需要的，可能就是 execution speed。
在這個階段，一個能夠有效使用 AI tools、快速交付高品質成果的 junior engineer，可能比上述另一位 senior engineer 帶來更高的邊際價值。因為現在的 bottleneck 不是判斷方向，而是執行速度。當然，這個前提是交付品質能被有效驗證，且系統有適當的 review 與 safety nets。
當團隊處於 0-to-1 階段
但如果是一個 startup company/startup project，產品方向仍然模糊，architecture 還沒有成形，甚至連這個 idea 值不值得投入資源都不確定。這時候，execution speed 可能不是最重要的問題。真正重要的是：
- 現在這個問題是不是正確的問題？
- 這個 idea 值不值得投入？
- 哪些技術決策會限制未來的選擇？
- 現在應該 build、buy，還是根本不需要做？
- 哪些假設必須先驗證，才能避免浪費整個團隊的時間？
在這種環境下，具有成熟 engineering judgment 的 senior engineer，往往能帶來更高的價值。因為一個錯誤的方向，即使執行得再快，也只是更快地浪費資源。
真實世界通常不是二選一
大部分 Engineering Organizations 都不會永遠停留在同一個階段。
有些團隊正在探索方向，有些正在建立 architecture，有些正在大規模交付，有些則在維護成熟系統。所以真正的 engineering leadership 問題，不是「Junior + AI 跟 Senior + AI 誰比較強」，而是：
What is the right mix of execution capacity and engineering judgment for the problems we’re solving?
好的 engineering organization 需要兩者。
AI 改變了 execution 的經濟條件，也可能改變團隊的人才配置比例，但這不代表 engineering judgment 不再重要，更不代表我們應該用「能不能重建 Claude Code」來重新定義 seniority。
為什麼「理解 AI 底層」也不是通用門檻
拿 Git 來做類比 -
一個 senior engineer 應該知道怎麼使用 Git，也應該理解 rebase、merge、conflict resolution，以及錯誤操作可能帶來的風險，但我們不會要求所有 senior engineer 都必須能夠重新實作 Git。
AI Tools 也是一樣。如果你只是使用 Claude Code 開發產品，你應該知道：
- Context 太多或品質不佳時，模型可能遺漏重要資訊
- AI 產生的 code 即使通過測試，也可能不符合真正的需求
- 自動 context compaction 可能遺失關鍵的設計約束
- Agent 執行工具時，可能產生超出預期的副作用
你需要知道這些 failure modes，並能夠採取有效的處理方式，但你不一定需要深入研究 tokenizer implementation、KV cache management 或 prefill/decode optimization。
如果你的工作是設計 Agent Runtime、LLM Serving Infrastructure，或最佳化推論成本，那當然不一樣。因為這些知識直接影響你的 Architecture Decisions。又或者你本來就對這些很有興趣想要多了解，即使跟你目前手上的工作並沒有相關，那我會鼓勵你多深入鑽研。
The depth of knowledge required should be determined by the problems you are responsible for solving.
不能因為某個技術現在很熱門，就把它當成所有 senior software engineers 的共同門檻。
Huntley 說對的部分
我並不是完全不同意 Huntley。
首先，AI fluency 正在成為 software engineers 越來越重要的能力。工程師如果完全拒絕理解或使用 AI tools，長期來看很可能降低自己的競爭力。其次，他強調 senior engineers 應該具備 taste，並且能夠把工程經驗傳承給下一代，這一點我也認同。另外，如果你正在建立 AI Infrastructure，那麼理解 Agent loop、tool calling、context management 與相關底層機制，確實是工作所需的能力。我想我們真正的分歧在於：
這些能力是某些工程工作的必要條件，但不應該自動成為所有 senior engineers 的定義。
AI proficiency 很重要。
AI internals 在適當的領域也很重要。
但 engineering seniority 仍然應該由工程師的判斷能力、技術影響力，以及解決複雜問題的能力來衡量。
那麼回到面試，我們如何驗證一個 senior engineer 的能力？
與其要求候選人從零實作一個 coding agent，我個人會更想看到他如何處理一個看起來已經成功、但可能存在隱藏問題的系統，例如：
這段 AI 產生的 code 已經通過所有 unit tests、lint 與 type checking。你還會驗證什麼？為什麼？
或者回到前面的 SELinux 案例：
Policy 編譯成功、裝置正常開機、App 功能正常，也沒有 AVC denial。你如何確認 App 真的執行在預期的 SELinux domain？
我不只是想知道候選人能不能找到答案，我更想了解他的思考過程：
他是否能識別驗證盲點？能否提出合理的假設？知道該收集什麼證據？當新證據出現時，是否願意修正自己的判斷？
這比背出某個 framework API，或重建一個簡單的 coding agent，更接近我對 senior engineering 能力的期待。當然，任何固定題目都可能被準備。因此真正有效的面試，應該讓候選人面對新的限制與證據，觀察他如何調整判斷，而不是只檢查標準答案。
工具會變，engineering judgment 才是長期資產
有人可能會說，domain knowledge 也會過期，這個反駁是合理的; 十年前有效的技術方案，今天可能已經不適用。AI 也正在改變 Software Engineering 的方法與最佳實踐，但我認為需要區分兩件事：
Implementation knowledge 會過期，但理解 constraints、trade-offs 與 failure modes 的能力，通常更具有延續性
你今天學會怎麼寫一條 seapp_contexts 規則，未來可能會遇到不同的 policy mechanism。但你學到的「一個設定存在，不代表它真的在 Runtime 生效」，仍然可以應用到其他系統。
你今天熟悉某個 Agent framework，明年它可能就被新的 framework 取代。但你對 authorization boundary、failure recovery、state consistency 與 observability 的理解，仍然會影響你如何設計下一套系統。這些能力也需要持續更新，不能只靠過去的經驗。
AI 會讓工程師更快產出。
AI 也會讓優秀的工程師擁有更大的 Leverage。
但當每個人都能快速產生看起來合理的程式碼時，真正的差異不再只是誰能寫得更快，而是誰能判斷什麼值得做、什麼設計比較好、什麼風險尚未被驗證，以及什麼時候不應該繼續投入。
AI Doesn’t Define Seniority. Engineering Judgment Does.
And AI makes that judgment more valuable, not less.