What is happening → what to do
Look things up by symptom, not by title. The link under "what to do" jumps to the section that describes the mechanism. The full table of contents is at the bottom.
This table assumes Claude Code (Anthropic's coding agent). hook, CLAUDE.md, subagent and auto memory are the names of its features.
| What is happening | What to do |
|---|---|
| Every time the AI runs the tests, tens of thousands of output lines flood the context |
Route all test runs through a single wrapper script, write the full output to a log file, and return only a summary of the failures to the AI. → What I stopped reading The Art of Not Reading #1: The Art of Not Reading Test Output |
| The more knowledge notes the AI saves, the more every future session has to read |
Use a PreToolUse hook that runs right before a memory write to make the AI read a checklist first, and keep the instruction file (CLAUDE.md) down to a single line: "read before you write." |
| The tests pass, but it's unclear whether they actually protect anything |
Write a one-page policy on mutation testing (deliberately breaking the code to see whether the tests catch it), and have the AI read it whenever you ask it to review the tests. |
| The AI sometimes uses a registered skill and sometimes doesn't |
Keep the command as an ordinary script, block incorrect invocations with a PreToolUse hook, and point the AI to the documentation it should read. |
| Once work is handed to a sub-agent, you can't see what's happening until it finishes |
Define, in YAML, which tasks may be delegated to a sub-agent and which input files must exist before launch, then check that with a hook before it starts. |
| The more rules you add to the instruction file, the less the earlier rules get followed |
Rewrite each "don't do X" rule, one at a time, as an automated test (Minitest) that can detect a violation. |
| Memory shared across parallel sessions gets messy, and having them read the policy doesn't help |
Move the same policy file into a PostToolUse hook and show it alongside the diff right after the save. Keep the content unchanged — only change the timing. |
| Even after writing down how to handle a failure, the AI makes the same mistake again next time |
Summarize the retry policy in a few lines in a file, and have a hook that detects the failure insert it automatically. |
| Even reading the handoff notes and completion report, the inconvenient parts are missing |
Every time, place mechanically obtained numbers — from something like git diff --stat — right next to the completion report. |
| Numbers the machine counted turn into different numbers by the time they reach the report |
Attach a fixed prefix to the line with the number, and have a hook check that it was copied verbatim. |
| Interrupting the AI mid-task throws off everything it does afterward |
Instead of a person interrupting mid-task, let a PostToolUse hook that returns the policy right after a save, and a hook that detects failure and sends the work back, do the intervening. The person waits for a natural break. |
| At the end of a session, it's undecided what needs reading and what doesn't |
Don't read the deliverable or the work log — judge pass or fail solely by the exit code of the tests or linter. |
| A proposal you already rejected comes back again in the next session |
Consolidate every rejected decision into a single document, using a fixed format. |
| Even with a one-line prohibition written down, it gets both over- and under-interpreted |
In the single document that collects rejected decisions (for example non_goals.md), add a "reason" heading to each prohibition, next to the conclusion. |
| The prohibition is written correctly but not followed, and each time someone asks about it |
In the rejected-decisions document, add a "scope" heading to each prohibition and list, one line at a time, the borderline cases that cause confusion. |
| Give the same instructions to several sub-agents and each one comes back in a different shape |
In the list of tasks that may be delegated to a sub-agent, explicitly state the input files that must be prepared before launch. |
| Prohibitions with no automated test pile up, staying nothing more than text on a page |
In the rejected-decisions document, add a "machine-checked" heading to the list and mark, item by item, whether a corresponding automated test (Minitest) exists. |
| Every piece of AI work ends with "please open the screen and check it" |
Prepare a single Playwright smoke test, and judge pass or fail by the record left in the database rather than by how the screen looks. |
| Every time the AI says something slightly off, you're the one explaining and fixing it |
Instead of a person explaining and correcting each slip, write the correction into a hook's stderr (exit 2) and into automated-test failure messages, so that is the route by which it reaches the AI. |
| The list of rejected decisions keeps growing and looks headed for the point where nobody reads it |
Add a "not adopted" section at the end of the rejected-decisions document, and record rejected proposals there. |
| The instruction file's "always run this" lines never seem to shrink |
Use an automated test to cross-check whether every command the instruction file marks "always run" also exists in a pre-commit hook. |
| Even after writing out exactly how to do it, the fix doesn't come back that way |
Instead of dictating the procedure, define, per use case, the input files that must exist before a sub-agent can be launched. |
| Reporting a bug means writing out the steps and symptoms yourself, every single time |
Set up a bug report form where the person only types one sentence describing the symptom, and let JavaScript automatically collect the URL, action history, and browser information. |
| Typing "give me a plan first" every time is its own recurring chore |
No new implementation is needed. Put a single design document in place, and the AI will read the existing documents and follow the same format. |
| The lines you most want followed are written the most emphatically, yet you can't tell whether that helps |
Stop trying to measure the effect — instead count the lines in the instruction file that use emphasis, and add an automated test (a ratchet) that fails once that count exceeds a threshold. |
| A sub-agent's deliverable comes back in a different shape than you expected |
For each sub-agent use case, define the acceptance criteria for its deliverable — file name, format, required fields — in a single document. |
| Finding a mistake makes you want to demand, "did you actually read this?" |
Instead of demanding an answer, fix the second sentence of every request to the question template "isn't it the case that ...?". |
| Replying "that's not it" to the answer you got back doesn't make it any better |
Instead of pointing it out yourself, present prohibitions that come with no alternative through a PostToolUse hook, shown alongside the diff right after the save. |
| The AI talks about a file's contents as though it had opened it, when it hasn't |
Have the AI write matching markers in both the referenced document and the code, and verify with an automated test that the markers actually exist. |
| The AI keeps asking "A or B?" and work grinds to a halt while you decide |
Stop answering on the spot — arrange for the choice to be decided by an automated test or a hook instead. |
| The AI is doing the review, but it's unclear what it isn't looking at |
Use an outside automated test that counts things to catch any automated test that scans files but has no lower-bound assertion on the count (e.g. assert_operator ... :>=). |
| Screenshots keep piling up, but it's unclear which one verified what |
Before checking the screen, require answers to two questions — "what is being verified" and "why a cheaper method won't do" — and keep a one-page guideline for trying the cheapest option first, in the order unit test, integration test, then E2E. |
| A step that requires writing something down is in place, but you can't count how many runs skipped it |
Before a screenshot or an E2E run, have a declaration file written that states what is being verified (for example tmp/visual_verification.md), make its existence a precondition of a PreToolUse hook, and let the screenshot or E2E refuse to start without it. |
| The same test runs again even though the code hasn't changed, and you wait for it anyway |
Add a --last option to the test wrapper script that replays the previous log, so a rerun isn't needed. |
| Nothing was broken, yet a wall of unfamiliar errors shows up |
Have the test wrapper script take an exclusive lock (using the atomicity of mkdir), and refuse to run if it can't acquire one. |
| A report saying "the tests pass" doesn't mention the parts that never ran |
Tag heavy E2E tests by area name and skip them by default, and print the list of areas that didn't run every time. |
| There's no way to tell afterward whether an instruction specifying how to proceed was actually followed |
When you want a procedure followed, don't strengthen the wording of the instruction — instead change it so that following the procedure leaves a trace in the deliverable (for example, having it print one line for every file it opens). |
| A wrapper you put in place gets abandoned partway through, back to the raw command |
When you want the wrapper used, don't strengthen the instruction — check instead whether there's still a reason to fall back to the raw command, meaning the wrapper is missing some capability. |
| Asking the same question repeatedly gets a different answer each time, and summarizing loses something |
Before merging multiple answers into one, print how often each type of finding appeared — how many out of how many raised it. |
| There's no way to tell whether a line that says "do X if needed" ever actually fired |
Don't write conditional instructions like "do X if needed" — instead enforce the step with a hook that blocks progress until it's done. |
| Saying "think about it again" changes the answer, but it's unclear whether the AI is actually convinced |
Instead of sending it back with "think about it again," point out specifically which premise is wrong. |
| Writing "don't guess" made the AI start coming back having built nothing at all |
Don't hand over only a prohibition — pair it with a fallback output, such as "if nothing applies, output 'not applicable'". |
| The longer a conversation that's going well continues, the more effort it takes to verify |
End the session at each task boundary, and start the next task in a new session. |
| Every deliverable is correct, yet waste that never shows up in them keeps building up |
Once the deliverables are complete, run a script to tally the work log (transcript) itself, once. |
| Notes left behind for the next person drift out of sync with reality and go stale |
Don't leave the knowledge in a document — embed it in an automated test's failure message or a hook's stop message, so it surfaces exactly when it's needed. |
| Digging into the cause continues, and the reading keeps going even after the answer is found |
Count, from the work log, runs of reads that never changed anything, and write a one-line stopping condition before you start digging. |
| The lowest-priced model is made the default without measuring whether it actually fits the use case |
Give the same task to both the cheaper and the more expensive model, then decide only after separately counting the turns to completion and the amount newly read, reused (cache read), and written. |
| When something isn't working, the fix reached for is a bigger model rather than a better mechanism |
Give the same task to both the more expensive and the cheaper model, and turn the spots where only the cheaper one fails into a permanent check. |
| Research that the main session could finish on its own gets handed to a sub-agent just in case |
Before delegating, check whether the parent agent already has that context. If it does, keep going in the parent agent; hand a subagent only the bulk of the reading it doesn't already have. |
| The default move is to split the work into four and run them all at once, just because |
Give each subagent only as much as it can return in a single response. What sets the cost isn't how many subagents there are, but how many round trips each split-off subagent makes with the parent agent. |
| "Take a look at this too" gets injected from outside partway through the work |
Wait for a natural break in the work, then bring in the extra request with a narrowed scope. When asking the AI itself about gaps, always add: "if it's sufficient, say so explicitly." That gives it an escape hatch, so it doesn't have to invent a gap. |
| Which model to use is being decided by comparing them head to head |
Before starting to compare models, count how many hooks or automated tests the comparison would cost in effort. If you can write down more mechanisms than that, put those in place before comparing. |
| "There was no difference" is used as the reason to wrap up the verification |
Before wrapping up with "there was no difference", count two things: if any results were excluded from the tally (such as failed subagents), put them back and recount; if more than half the items score zero under every condition, rephrase the task and measure again. |
All articles
Series by series, from the introduction to the final article.
はじめに —— 3 つの連載を、1 冊に
バイブコーディングにおける読まない技術
- The Art of Not Reading — Introduction I Barely Read What the AI Outputs Anymore
- The Art of Not Reading #1 The Art of Not Reading Test Output
- 読まない技術 第2回 メモリを読まない技術
- 読まない技術 第3回 単体テストを読まない技術
- 読まない技術 第4回 スキルを使わない技術
- 読まない技術 第5回 サブエージェントの出力だけは読め
- 読まない技術 第6回 ルールを読まない技術
- 読まない技術 第7回 共有メモリを整理しない技術
- 読まない技術 第8回 修正履歴を読まない技術
- 読まない技術 第9回 引き継ぎを読まない技術
- 読まない技術 第10回 AIに要約しろと言わない技術
- 読まない技術 第11回 口を挟まない技術
- 読まない技術 第12回 作業結果を読まない技術
- 読まない技術 最終回 AIの出力を、ほとんど読まなくなった
AIの意見を聞かない技術
言わない技術
- 言わない技術 序論 AI に指示することが、ほとんどなくなった
- 言わない技術 第1回 検証を指示しない技術
- 言わない技術 第2回 具体的な指示を出さない技術
- 言わない技術 第3回 不具合詳細を書かない技術
- 言わない技術 第4回 計画を書けと言わない技術
- 言わない技術 第5回 念を押さない技術
- 言わない技術 第6回 サブエージェントの出力だけは、細かく指示しろ
- 言わない技術 第7回 AI を問い詰めない技術
- 言わない技術 第8回 AI にダメ出ししない技術
- 言わない技術 第9回 AI に考えさせない技術
- 言わない技術 第10回 質問に答えない技術
- 言わない技術 第11回 AI にレビューをさせない技術
- 言わない技術 最終回 何もしない技術
付録
はじめに —— 前巻の続きを、もう 1 冊に
確かめない技術
動かさない技術
追わない技術
番外編
- 番外編 A-1 整理する技術 —— 記録が増えたときに、何が起きているか
- 番外編 A-2 指示を残す技術 —— 「調べるだけ」が通らなかった日
- 番外編 A-3 参照するタイミングを変える技術 —— 2,000 行の壁
- 番外編 A-4 導出を依頼者の言葉と分ける技術 —— 誰も言っていない条件が、memory に載った日
- 番外編 A-5 memory を要約しない技術 —— 整理から、要約を抜く
- 番外編 A-6 責務で線を引く技術 —— 仕組みが増えたときに、どれを消すか
- 番外編 A-7 読まれたかを確かめる技術 —— 確かめるのをやめて、読めていない形を止めた
- 番外編 A-8 面積で数える技術 —— 読ませた量で数えていたら、102 倍外していました
- 番外編 A-9 ルールを短くする技術 —— 読みに来るのは、止められた直後の人です
- 番外編 B-1 連載を本にする技術 —— 本単位のスイッチでは、足りなかった日
- 番外編 C-1 校正の方法に、先に本編を当てる技術 —— 方法を決める文が、本文と同じ地雷を踏んでいた日
- 番外編 C-2 仕組みと人を分ける技術 —— 検査を置いたその手で、検査の外側で 2 度転んだ日
- 番外編 C-3 要素ごとに観点を変える技術 —— 一様に当てた点検が、要素をまたいだところで数を落としていた
- 番外編 C-4 指示の揺れを、事故として残す技術 —— 事故を見て置いた仕組みは、まだ一度も鳴っていない
- 番外編 C-5 作業の流れを見る技術 —— 終わりにしたつもりの日に、まだ起きていたこと
- 番外編 C-6 作業を進める技術 —— 選ぶ場面が、1 つも残らなかった日
- 番外編 C-7 基準の出どころを見る技術 —— 2 分前に開いたページに、答えが書いてありました
- あとがき —— 本当の事実はどうでもいい話