Todd's Notes

我好奇在 AI 時代下的 Code 理解是否還重要

Created · Updated

Contents
  1. 背景
  2. 探索
    1. Agentic Code Review
    2. Understanding is the new bottleneck
  3. Uncle Bob AI
    1. 為什麼我們要在乎 Bad Code，既然 Agent 可以快速的完成任務？
    2. 為什麼透過工具而非 Steering (prompts) ？
    3. 自動化測試會有太多層的時候嗎？
    4. 多代理下各個 Agent 的角色
    5. 在實作前會進行什麼規劃？
    6. 有什麼東西和過往是不同的，可以被丟棄的？
    7. Spec Driven ？
    8. 在 AI 時代如何進行學習？
    9. 如何判斷 AI 寫出糟糕的東西？

背景

我覺得 2026 年更是一個 AI Coding 更爆炸的時候。雖然再更之前就已經很多人透過 AI Coding 了。

但我覺得在 2026 年是更瘋狂的時候，各家科技大廠要求員工必須使用 AI 進行 Coding。

開始有許多的聲音出現 Code 不需要被理解，人會是 Bottleneck 等的聲音出現。

到現在仍然還是很懷疑，目前更多的同意是細節可以不需要去看，但是在架構層面會需要再去深入思考理解。

在這段期間確實有感 Code Review 的困難，公司內部的 PR 成長的量非常的巨大，在以前可能需要多個 Sprint 才會完成的任務，可能過幾天就會有 PR 的出現。

並且 PR 的行數也非常的大，在 Review 的時候遭遇到了許多的困難。

後來在公司中導入了 Stacked PR 期望能加快 PR 的 Review 速度，以及在透過 AI 協助 Code Reivew，建立一些自動化的 Review 方式。

雖然有所幫助，但還是時常陷入懷疑，自己算不算已經過時了，還繼續走著 Code Review 的流程。問了蠻多的人，好像很多人都已經放棄進行 Review 或看 Code 了。只要把測試寫的多一點，人工再進行測試就足夠了，人會卡到開發的時程。

探索

Agentic Code Review

看過了 addyosmani 的文章 Agentic Code Review ，是我較為認同的，對 Code 的重要程度進行分類，然後決定 Review 的程度。

像是公司的內部工具就可以完全不看、不理解，這也不重要、幾行的 IDE 設定檔也不需要花費心力去查看。

一次性用的行銷網站，後續也不需進行維護，那這個完全交給 AI 也很合適。

作者提出先瞭解發 PR 的替我，看它影響的程面，在決定花多少心力去 Review 它。

Writing got cheap, understanding didn’t。

我們的工作仍然是交付可靠的軟體。

Understanding is the new bottleneck

Understanding is the new bottleneck

作者主要提出了為什麼我們應該仍要去理解 Code 且該如何幫助我們更快速的理解。

AI 不只是加快我們完成任務的工具，更是幫助我們去理解成長的工具。

為什麼會需要理解？

理解 != 驗證

在之前我們看 Code 是為了避免 AI 犯錯，但在目前這個時候其實 AI 的犯錯率已經大幅下降了，許多的錯誤也可以透過 Test 去抓到，再由後續人工進行 QA。

作者提出理解是為了 更好的參與下一個 Loop ，在理解過系統、知道架構如何、是如何進行設計的，才能提出更獨到的想法以及見解。

相比不去理解的人，可以去更流暢的連結自己的認知，並帶進下一個 Loop 中。

在過往我們有技術債，但現在我們有 認知的債務(Cognitive debt) ，跟技術債一樣，當累積到一定程度後，它就會爆炸，變得難以去處理。

如何加速理解？

時代也已經不同，在過往我們會一行行的去看 Code 嘗試理解，但現在我們也可以透由 AI 的輔助去進行理解。

Explain Diff 去瞭解 Code Change 的改動。

Skill 主要分成：

  1. Background
  2. Intuition
  3. Code
  4. Quiz

Backtround 簡單的說明更改的相關系統，供不熟悉的人可以更為理解。

Intuition 此次變更得核心，透過圖表或是互動式得操作範例，讓人可以理解。

Code 以易於理解得方式整理該閱讀得部分，避免是從檔案從頭看到尾。

Quiz 透過測驗了解自己是否知道此次得變更情況。

Uncle Bob AI

LIVE: Uncle Bob on Software Fundamentals in the Age of AI

Mutation Test: 將程式中的大於變小於、等於變不等於 等操作，修改原本的測試邏輯，預期測試要都 Fail。如果有倖存的就代表需要解決它。

Bob 目前的工作流程： 抽查程式、透過其它工具或是測試約束 Agent 完成工作。Agent 處理 Code 很快，自己寫很慢，所以我們複雜其它周圍的事情，交給他們寫 Code。

為什麼我們要在乎 Bad Code，既然 Agent 可以快速的完成任務？

在之前未建立 Harness (Loop) 等方式時，交由 Agent 進行開發，當它寫了不好的 Code 的時候，仍然不理它持續進行，他發現 Agent 工作變的困難且變慢，會無間弄壞其它的部分，然後要回去修復。

Agent 會被 Bad Code 影響，最後空轉無法前進。

為什麼透過工具而非 Steering (prompts) ？

Agent 的上下文只關注前面幾句和最後面幾句，中間的完全就消失了。所以當 prompts 很長的時候，就沒有用了。

而靜態工具並不會有這些問題，你設定的每一個都會被正確執行。

自動化測試會有太多層的時候嗎？

會有，當 Agent 如果因為這些限制 (test, type check etc)變的比人還慢的時候，那優勢就會消失了，不過 Bob 目前仍然覺得比他快很多，捨棄一些速度換來高品質。

多代理下各個 Agent 的角色

  1. 可以並行的執行任務
  2. 每個 Agent 中間內容遺失的問題減少

缺點是每個新 Agent 都需要重新釐清上下文。

sequenceDiagram
    Specifier->>Worker: Write Code base Gherkin document
    Worker->>Cleaner: Do Code Review & Fixup
    Cleaner->>Hardener: Do Mutation Test
    Specifier->>QA: Test base QA Document
Note

Specifier 會產出 Ghernkin 文件以及 QA 文件。

Worker 基於 Specifier 的文件進行開發的實作。

Cleaner 對於 Worker 的產出進行 Review 和複雜度的分析進行修正等。

Hardener 進行 Mutation Test。

最後 QA 基於 Specifier 產出的 QA 文件進行操作的測試。

在 Context 中如果給與了一些與工作不相干的上下文，會造成 Agent 的工作混淆，例如和 Agent 告知每次 UI 改動都需要進行測試，儘管後續的工作是不相關的，但只要在上下文中，就可能導致 Agent 的工作方向偏移。

Bob 透過開新的 Agent 清除 Context，避免 Agent 的工作混淆。

在實作前會進行什麼規劃？

Bob 會 Review Agent 目前的程式的架構，通常會重新自行切分各模組或是各依賴關係，寫成 rule 讓 Agent 遵照執行。

目前會透過 Agent 產生 UML 圖，讓他可以看見各模組彼此間的依賴關係。

有良好的隔離以及設計的模組，對於人類更好理解，對於 Agent 也是，它可以更關注單一的模組。

良好的模組(Structure, Name, Interface etc)可以幫助 Agent 閱讀，無須閱讀更底層的程式實作邏輯。 Agent 也會閱讀 Test 去瞭解，去瞭解達成的事。

有什麼東西和過往是不同的，可以被丟棄的？

  1. Agent 的短期記憶力很好，所以會將原本的 Function 複雜度的閥質提高。
  2. TDD 的做法是因為人類，不必強加於 Agent 上。

Spec Driven ？

Spec Driven 跟以前的瀑布流是相同的，定義了 Spec，然後將它完成，但是有太多之外的事情，無法思考完整，你得不停的去修改 Spec。

使用敏捷的架構，一個個 Story 進行。

Agent 喜歡 Plan，完善規格，把每一個細節都寫的很詳盡，最後崩潰。

Change 的成本目前很低，以不停的調整進行，直到達成可能是比較好的方式。

Bob 說不會在 Repo 中留下 Spec 的文件，他認為這些所謂的規格都是暫時性的，會不斷的進行修改和消失，他只將最終成果當成規格。

我對此感到疑惑：

  1. 一般的工程師該如何在沒有規格的情況下進行開發，他如何確認目前的方向與需求是一致的？
  2. 那他該如何與他人進行協作？

或許他目前都是以個人開發為主，沒有所謂的 UIUX 團隊、商業分析團隊等，而是自己去理解需求然後交付成果？

那對在公司企業需要與他人進行協作的工程師該如何去處理這個情形？

在 AI 時代如何進行學習？

AI 擅長在前線(寫程式)，但對於策略層面處理的很糟糕，但在這個時代的人該如何再沒有經歷過前線而仍然可以學習到策略層面的事務？

Bob 給出的答案是，必須要寫 Code，透過寫 Code 學習 Agent 正在處理什麼事情。

在訓練(學習)的時候，把自己當成 Agent，使用 Agent 使用的工具，儘管這會非常的沒有生產力。

如何判斷 AI 寫出糟糕的東西？

Bob 發現 AI 在開發的過程出現了掙扎的現像。