Fast Models Need Slow Developers：
1,200 tokens/s 之後，紀律更重要

先講結論：快模型會放大工程習慣

這支 talk 不是單純說「模型很快」。真正的重點是：當模型從 Sonnet / Opus 類型的 40 到 60 tokens/s，跳到 Cerebras 與 OpenAI 合作的 Codex Spark 約 1,200 tokens/s，原本建立在慢生成上的工作方式會失效。以前你有時間邊等邊想、邊看邊修；現在模型可以在你還沒重新定義任務前，就把 context、diff 和錯誤假設全部放大。

因此「slow developers」不是要故意變慢，而是要把慢放在正確的位置：規格切分慢一點、驗證更頻繁、每個 agent session 都有外部狀態、每一輪輸出都能被比較與挑選。

for step in agent_work:
  generate_fast(model="Codex Spark")
  run_validation("lint + tests + typecheck")
  write_progress("progress.md")
  update_plan_if_evidence_changed()

if task.has_many_plausible_solutions:
  spawn_subagents(count=5)
  collect_variants(target=75)
  human_selects_best_diff()

persist_memory(files=[
  "agents.md", "plan.md", "progress.md", "verify.md"
])

快速生成讓「等模型」不再是瓶頸；瓶頸轉移到你能不能即時驗證、剪枝、記錄與做取捨。 — 本頁依 YouTube RSS、watch metadata 與影片描述整理

1,200 tokens/s 改變的是 feedback loop

影片描述給的關鍵數字很有殺傷力：Codex Spark 約 1,200 tokens/s，而 Sonnet / Opus family 約 40 到 60 tokens/s，約二十倍差距。這代表原本要十分鐘填滿的 context，現在三十秒就可能被消耗完。速度本身不是問題；問題是缺少 guardrail 時，錯誤方向也會用同樣速度擴散。

在這個 regime 裡，validation 和 linting 應該變成每一步都做的背景節奏。以前因為等待成本高，工程師常把檢查留到一段工作之後；但如果生成幾乎即時，沒有理由不讓測試、lint、typecheck 連續介入，提早把錯誤關掉。

多 agent 不是為了熱鬧，而是為了產生可比較的變體

高速模型讓「大量候選解」突然變得實際。影片描述提到，可以讓五個 sub-agent 產生七十五個 component variations，再由人挑出最好的方向。這不是把 decision making 交給模型，而是把模型當成搜尋引擎：快速展開設計空間，人再用產品品味、程式碼品質與維護成本做篩選。

這種做法的前提是任務可被清楚切片，而且每個候選結果能快速比較。若沒有一致的驗收標準，多 agent 只會產生更多噪音；有標準時，它才會變成平行探索。

四份外部記憶，把 session 從「重來」變成「接續」

當 context 三十秒就可能被燒完，不能把全部狀態押在聊天視窗裡。Sarah Chieng 提到的四檔外部記憶系統很務實：agents 記錄角色與分工，plan 記錄當前策略，progress 記錄已完成與卡點，verify 記錄驗證結果與剩餘風險。

這套做法的目的不是文件潔癖，而是讓下一個 session 不需要重新理解世界。高速 agent 最怕的不是慢，而是每次都從零開始、用很快的速度重複做錯。

實務啟發：把慢放在生成之前與驗證之後

來源與限制

本頁使用 YouTube RSS、watch 頁 metadata、oEmbed 與影片描述整理；YouTube timedtext 介面未回傳可用字幕 track，本機也沒有可用的 yt-dlp，因此沒有逐字稿。章節時間為依 18:02 影片長度與描述重點整理的內容地圖，非官方 timecode。