One Claude Code Tip a Day: Read First, Patch Second

This post is part of the “One Claude Code Tip a Day” series — a daily guide to using Claude Code more effectively.

Claude Code is fastest when you slow it down at the beginning. The bad version of an AI coding session starts with “fix this bug” and immediately receives a patch. The good version starts with a read-only pass: Claude inspects the relevant files, explains how the current behavior works, names the likely failure point, and only then proposes an edit. This habit feels defensive, but it is one of the best ways to avoid beautiful wrong changes.

The failure: a plausible patch with no map

Picture a frontend bug in a React app: the checkout page shows the discount total twice after a coupon is removed. You paste the symptom into Claude Code and ask it to fix the issue. Claude edits the component that renders the total, removes a memoized value, and the UI looks better in one path. Then tests fail because the real duplication came from state synchronization between the coupon hook and the order summary store. The first patch was not random; it was just based on an incomplete map.

Read-only analysis prevents this kind of local optimization. You are telling Claude: before touching code, earn the right to edit by proving that you understand the flow.

The workflow: explicitly forbid edits

Start the session with a constraint that changes Claude’s posture. Use a prompt like this:

Do not edit any files yet. Read the checkout page, coupon hook, order summary store, and related tests. Summarize the data flow for applying and removing a coupon. Then identify the most likely source of the duplicated discount total, the files you would change, and the verification command you would run.

The important phrase is “Do not edit any files yet.” Claude Code can inspect, search, and reason without making a patch. In a mature codebase, that separation matters. Analysis and editing are different jobs. If you combine them too early, you often get a confident diff before you get a correct diagnosis.

What good analysis should contain

A useful read-only response should be concrete. It should name real files, not imaginary architecture. It should describe the control flow in the project’s vocabulary: which component owns rendering, which hook mutates coupon state, which store derives totals, and which test already covers removal. It should also call out uncertainty. For example: “I see two discount calculations, but I need to inspect the selector test before deciding which one is canonical.” That sentence is a good sign. Claude is using the repo as evidence, not guessing from patterns.

If Claude gives you a generic answer, push back. Try: “You described a common React pattern, but I need this repository’s actual flow. Quote the function names and file paths that support your conclusion.” This is the second-pass correction that turns a shallow assistant into a practical coding partner.

Then ask for the smallest patch

After the read-only map is good, switch from diagnosis to implementation:

Now make the minimal change that removes the duplicated discount total. Do not refactor unrelated code. After editing, show the git diff and run the narrowest relevant test. If the test fails, stop and explain the failure before trying another fix.

This prompt gives Claude three rails: minimal patch, diff inspection, and test feedback. In real sessions, this is where the loop becomes productive. Claude edits one or two files, runs pnpm test checkout-summary or npm test -- coupon, then you inspect whether the diff matches the diagnosis. If the diff changes formatting across the whole component or rewrites the store, ask it to revert and try the smaller path.

Verification is part of the tip

Read-only analysis is not complete until it names how the fix will be verified. For a frontend bug, verification might be a component test plus a Playwright step: apply coupon, remove coupon, assert that the discount row disappears and the total updates once. For a backend bug, it might be a failing unit test and a log line from a local request. For deployment debugging, it might be Railway logs plus a health-check command. The point is to make Claude connect code reading to observable proof.

Failure modes

This habit can go wrong in two ways. First, Claude may spend too long reading the entire repository. Fix that by naming the suspected area and asking for a bounded scan. Second, Claude may produce a polished plan that still skips the failing path. Fix that by asking: “What evidence would falsify this diagnosis?” A good answer might identify a specific test, route, or log line that would prove the patch is wrong.

Also avoid using read-only mode as procrastination. Once Claude has named the flow, risk, files, and verification command, let it make the smallest edit. The goal is not analysis forever; the goal is to make the first patch less imaginary.

Rule of thumb

When the bug involves unfamiliar code, state, tests, or production behavior, ask Claude Code to read first and patch second. Require file paths, function names, a diagnosis, and a verification command before edits. If the analysis is vague, correct it before accepting a diff. The best Claude Code sessions do not start with a patch; they start with a map that makes the patch obvious.