Diff as a quality gate

1. Diff is a gate, not a highlight

— Okay, I get the three boxes, — says Tommy. — But where do I actually sort them with my hands? Where do I even look at this diff?

Alex opens the terminal.

— A couple of days ago you already learned how to look at changes before committing them. Scroll through, nod “looks okay.” Now the next level: not just scroll through, but examine each change on its merits. Same command:

/diff       # show all changes — go through each chunk separately

— Only now the eye does not skim, — Alex continues. — You yourself said it: in someone else's code, skimming is dangerous. You go through the diff slowly, and for each chunk ask one question — is it about the task or “while we're at it”? — and sort it into those three boxes:

✓ target fix                                → that's what was requested
✗ reformatted half the file “while at it”    → not the task
✗ touched a neighboring area outside scope   → not the task
? added an unsolicited animation (unexpected) → not ordered; in someone else's work — not it

— And here's the important part, how this works by hand, — Alex pauses. — /diff shows you everything, but it does not let you carve out one piece and leave the rest — that's not what it was built for. This is an inspection window, not a surgical table. So the decision is not “accept this line, reject that one.” The decision is bigger: if there's a tail in the diff, the whole run is crooked. You do not take it as a whole; you ask the agent to redo it narrowly, exactly on the boundary.

— So I don't filter pieces one by one, — Tommy thinks aloud. — I look at the diff and see that the run has sprawled, — and send the whole thing back. Then I set the task tighter, so there won't be any tail.

— Exactly. Diff is a quality gate: you're the gatekeeper at it. Spot something extra — the run does not pass, you turn it back and make it cleaner. You do not fix a crooked duplicate piece by piece; you don't let it through at all. And now it is no longer “diff showed” — the diff is asking you whether to let the run in or not. And you answer, not the agent.

Tommy says his piece out loud:

— Before, diff showed me “this changed here.” And now, from it, I decide: this run goes into the project or back for rework.

— Exactly. And the more precisely you reformulate the task afterward, the cleaner the next diff will be — and there will be nothing to turn away.

2. When it's easier to rewind the whole run

— And if Sam messed up so broadly that cleaning each piece by hand is a pain? — asks Tommy. — It really happens that he overhauled half the file.

— It happens. Then don't suffer, — Alex shows. — Don't fish out a hundred tiny pieces one by one. Rewind the whole run at once:

/rewind     # rewind the sprawling run entirely and start again more carefully

— Your very first course button, remember? — Alex adds. — It's alive and useful, but now it's the session's close-range safety net — remove one bad run. Not the only net, but the top one of several: underneath it is the git branch you studied recently.

Tommy nods. Once he thought this button would save him from anything. Now he sees its honest place.

3. Trust mode based on risk

— Listen, can I make it so it doesn't even go into someone else's code in the first place? — Tommy wants not to catch the tail every time, but to block it at the entry. — I'm tired of cleaning up after it.

— You can. Half the success is choosing the right mode in advance, — Alex switches. — Remember the “trust dial” from last week? Before, you turned it by habit. Now — by the cost of the mistake. And the first thing you do on someone else's code is NOT trust blindly.

— Claude Code has 3 operating modes:

• manual - The AI asks permission for any action with files on disk
• acceptEdits - editing is allowed.
• plan mode - nothing on disk can be changed at all. We only do planning.

You can switch them using the key combination “Shift+Tab”.

— Let me explain each of them, — Alex continues. — manual means “show every file change and ask before touching anything.” In commands it's also default: --permission-mode default. There is a faster mode, acceptEdits: the agent edits files in the project on its own and doesn't bother you. It's good in your own code, no problem. On someone else's code, it's an enemy: the agent will do a ton of stuff and you won't even see it. So in someone else's apartment — manual, we see every step.

— And the rule here is one, — Alex adds, — set the dial by risk, not by habit. Let safe things — reading files, running tests — go freely. Dangerous things — edits in someone else's area — keep strictly under control. And let the borderline stuff ask.

4. Point permissions rules in settings.json

— And won't reading what the AI asks and answering every time get exhausting? — Tommy looks for a way to simplify the work.— The more questions it asks, the less carefully I read them.

— It won't get exhausting; you can write the same thing once, — Alex opens settings. — So that you don't have to decide again at every step what to ask about and what to forbid, you can write all the rules in .claude/settings.json:

{
  "permissions": {
    "ask":  ["Edit(src/partner/**)"],
    "deny": ["Edit(legacy/**)"]
  }
}

— Let me explain what's written here, — Alex continues. — Edit means “the agent edits the file,” and in parentheses is where. src/partner/** is the whole src/partner folder with everything inside it, your work area for today; any edits there — ask. And legacy/ is an old, long-frozen piece of the portal that must not be touched at all; put it in deny — and edits there are forbidden completely, the agent will not even suggest them. It hits paths surgically, not “allow everything” or “forbid everything.”

Tommy looks at the two lines and, figuring it out on his own, builds the third basket:

— So we can mark folders in advance? Dangerous things — in deny. Borderline things — in ask. And safe things I don't write anywhere — they go through freely, like allow by default. Three baskets: forbid, ask, allow.

— Exactly. Just keep in mind, — Alex adds, — this is still the dial plus a few rules for specific paths. A full permission system, where the project's whole policy is written out in advance like law, is a separate grown-up topic for later. And the syntax changes over time — stick to the logic, not the brackets: forbid / ask / allow.

5. Why “asking about everything” kills protection

Tommy has what seems to him like a brilliant idea:

— Oh! Then I'll set ask on everything. Let it ask about every move. Maximum protection!

— Stop, — Alex cuts him off. — That's the trap. It's called confirmation fatigue. If the agent pings you for every little thing — opened a file? ask. read a line? ask — after twenty minutes you'll start clicking “yes” without looking, on autopilot. And then confirmation will die as protection: it works only while you read it. And you'll stop reading because you've had enough.

Tommy tries it on himself — and recognizes his own night habit of clicking “yes” to everything. Now he can see where it comes from: not from stupidity, but from fatigue.

— So asking about everything is the same as asking about nothing, — he says slowly. — I'll just stop reading carefully.

— Exactly. So do the opposite: leave “ask” only where you really need to think. Let safe stuff through freely, forbid dangerous stuff completely — so there won't even be a question. Put only the borderline cases under question, where the cost of a mistake is high and a human must decide. Then you read every “ask” seriously, because there are few of them.