L2Lesson 2Free

Read Before Tab

After this, you'll have a five-second scan habit that catches near-miss completions before they make it into your codebase.

Before you start

Complete Write Stubs the Model Can Finish first; this lesson builds on stub-writing so you can evaluate whether the completion matches the typed signature you wrote.

The idea

The model does not hesitate when it is wrong. It produces a wrong completion with exactly the same confidence as a correct one. This is the core hazard of tab-complete: you are working fast, the grey text looks right at a glance, and you hit Tab without reading it. The bug is now in your file.

The dangerous category is not obviously wrong completions. Those you catch immediately. The dangerous category is near-miss completions: code that looks correct at a glance but has one wrong detail. A variable name that is one character off. An off-by-one index. A condition that is inverted. A hardcoded value where you meant a parameter. These pass a casual scan and fail in production.

The fix is a five-second scan habit. Before you accept any multi-line completion, read: the variable names (are they actually the variables you have in scope?), the condition logic (is that `>` or `>=`? is that `&&` or `||`?), and any literal values (is that hardcoded or parameterized?). Five seconds. Every time. The habit builds fast and the payoff is immediate: you catch the near-misses before they compound.

Try it (20 min)

Watch out for

Only scanning the first line of a multi-line completion. The mistake is often on line two or three.
Trusting completions more in languages you know less well. The model is equally likely to be wrong, but you are less likely to catch it.
Accepting fast because a deadline is close. Near-miss bugs take far longer to debug than five seconds of reading.
Treating the model's confidence as signal. It has no confidence signal. It just produces text.
Forgetting that linters and type checkers catch some but not all near-misses. Logic errors pass type checking.

Paste this into Claude:

I want to build the read-before-tab habit. For the next 15-20 minutes of real coding, I will keep a tally of every completion I accept. For each one, I will note: (1) Did I read it before accepting? (2) Was there anything I had to fix after accepting? When I am done, I want to paste my tally here and get help interpreting it. Specifically: what patterns do I see in the completions I accepted without reading? What types of edits did I make most often? What should I scan for first in my specific codebase or language?

What good looks like:

You ran at least one 15-20 minute coding session with a deliberate read-before-tab tally
You caught at least one near-miss completion during the session that you would have previously accepted
You can name the specific error type you are most likely to miss (off-by-one, wrong variable, inverted condition, hardcoded literal)
You can describe the five-second scan in your own words: what three things you check before accepting a multi-line completion
Your tally shows a measurable difference between read-rate at the start and end of the session

What a good response looks like:

Here is what your tally tells us:

You accepted 23 completions. You read before accepting 14 of them (61%). Of the 9 you accepted without reading, you had to edit 6 afterward. The edits clustered into two categories: wrong variable name (4 times, usually a one-letter difference like `user` vs `users`) and hardcoded string where you needed a variable (2 times).

Pattern: the near-misses almost always happened when the completion was more than 3 lines long. Short completions you scanned naturally. Long ones you skimmed.

For your TypeScript/React codebase, the three things worth scanning first: (1) prop names in JSX, the model often invents props that look right but do not exist on the component; (2) array method chains, it frequently adds `.filter()` or `.map()` calls that look logical but use the wrong predicate; (3) any string literals, especially ones that look like they should be an env variable or constant.

Your read-rate started at about 50% and ended at 80% by the end of the session. The habit is building. Two more sessions like this and it will be automatic.

When this breaks

Breaks when you trust the model's tone, because there is no underlying confidence signal and a wrong completion looks identical to a correct one.
Breaks on logic errors that pass type checking, because compilers and linters cannot catch inverted conditions or off-by-one math, and that is exactly the near-miss category that hurts most.

Claude can do it for you

After a coding session, paste a completion you accepted that turned out to be wrong and say: 'What should I have caught in a quick scan of this? What pattern should I watch for next time?' Claude will identify the near-miss category and help you calibrate your scan.

You can now

Identify and correct at least one near-miss completion in a 15-20 minute coding session, and explain in one sentence the three specific things you scanned for before pressing Tab.

Key takeaways

The model autocompletes bugs as confidently as correct code. Five seconds before Tab is cheaper than an hour of debugging after.

Five seconds of scanning before Tab beats an hour of debugging after
Near-misses live in variable names, condition logic, and literal values; check those three first
The model has no confidence signal; tone is not evidence of correctness
Type checkers and linters miss logic errors, which is exactly the near-miss category that hurts most

Go deeper

I want to build the read-before-tab habit. For the next 15-20 minutes of real coding, I will keep a tally of every completion I accept. For each one, I will note: (1) Did I read it before accepting? (2) Was there anything I had to fix after accepting? When I am done, I want to paste my tally here and get help interpreting it. Specifically: what patterns do I see in the completions I accepted without reading? What types of edits did I make most often? What should I scan for first in my specific codebase or language?

Here is what your tally tells us: You accepted 23 completions. You read before accepting 14 of them (61%). Of the 9 you accepted without reading, you had to edit 6 afterward. The edits clustered into two categories: wrong variable name (4 times, usually a one-letter difference like `user` vs `users`) and hardcoded string where you needed a variable (2 times). Pattern: the near-misses almost always happened when the completion was more than 3 lines long. Short completions you scanned naturally. Long ones you skimmed. For your TypeScript/React codebase, the three things worth scanning first: (1) prop names in JSX, the model often invents props that look right but do not exist on the component; (2) array method chains, it frequently adds `.filter()` or `.map()` calls that look logical but use the wrong predicate; (3) any string literals, especially ones that look like they should be an env variable or constant. Your read-rate started at about 50% and ended at 80% by the end of the session. The habit is building. Two more sessions like this and it will be automatic.

After a coding session, paste a completion you accepted that turned out to be wrong and say: 'What should I have caught in a quick scan of this? What pattern should I watch for next time?' Claude will identify the near-miss category and help you calibrate your scan.