不知道從什麼時候開始，我每天最花時間的工作不是寫 infra config，是在 review Claude Code 生出來的東西。

我的日常大概是這樣：Jira 開一張票，把背景餵給 Claude Code，它給我一個 diff，我開始一行一行看。聽起來很美，但說穿了就是把以前的「寫 code」換成「看 code」，而且後者比前者更耗腦。HN 上最近有篇文章講到類似的狀況，作者說他每天工作用 Claude Code、下班用 Codex，做久了開始覺得累，累的點在 review 的密度，而且這種疲勞很難跟別人解釋。

生成速度跟驗證速度的落差，才是真正的問題。模型給你 200 行的 Terraform module，你要全部讀完嗎？你要，但讀完要 15 分鐘，模型生出來只要 30 秒。這個速度差在初期看起來是賺到，做久了你會發現 throughput 有一個隱藏上限，就是你的眼睛和腦子。

更麻煩的是 95% 到 100% 的收尾。模型可以把一個 Terraform resource 寫到「差不多可以」，但 tags 的命名規則、lifecycle 的 prevent_destroy 要不要開、provider version constraint 鎖到哪個 minor version，這些細節它不知道你的 conventions 是什麼。要嘛你寫進 prompt，要嘛你最後手動補。每個 issue 的最後 5%，常常是你花最多時間的地方。有時候這個收尾的時間比直接自己從頭寫還長。

還有一個我覺得很微妙的問題，model quirk。每個模型都有自己的慣用句型和生成偏好。Claude 傾向加很多 comment，有時候一個 bash script 的 comment 比 code 還多。Codex 生的 Python 習慣用特定的 f-string 格式。GPT-4o 給 Kubernetes YAML 的時候喜歡幫你猜 resource limits。這些都不是錯，但當你一天要 review 幾十個 diff，你會開始注意到「這個口癖又來了」，然後下意識地去找它的盲點，而不是看 code 本身的邏輯對不對。說穿了就是你在學每個模型的習慣，這個認知負擔是累積的。

HN 討論區裡有個留言說得蠻準：如果 review AI 的輸出沒有比自己寫快，就自己寫。實務上我遇到的狀況是，對於熟悉的東西（比如我每天都在摸的 Kubernetes manifest）review 速度是快的，因為我知道要看哪裡。但遇到陌生領域，review 時間直接暴增，因為你要先搞懂 AI 在幹嘛，才能判斷對不對。

跟 AI 對話久了，感覺有點像一直吃 fast food，口感每次都差不多，你知道它下一個字大概是什麼，你知道它下一段要怎麼收尾。可預期感久了就變成一種低度疲勞。

我沒有要說停用 AI，自己還在用。只是想記錄一下，這個 burnout 的源頭很具體，是生成速度跟驗證速度永遠對不齊。那篇有 334 個 upvote 的文章裡，作者最後說他需要休息一下。我覺得他需要的可能是一套更好的 review 流程，而不只是休息。