The strategy most developers miss with Claude Code is not a hidden flag or a prompt template. It is this: never let the model write code before it has stated, in writing, what it is about to do and how you will both know it worked. Everything I have learned across a year of daily Claude Code use, on this Laravel site and on client work, compresses into that one sentence. The rest of this post is how to enforce it without turning every task into a committee meeting.
I can show you exactly what enforcement looks like, because it is sitting in the CLAUDE.md at the root of this website's repository.
The Real Bottleneck Is Input Quality, Not Model Quality
When a Claude Code session goes sideways, the instinct is to blame the model. In my experience the model is rarely the variable. The variable is what the model knew before it started typing.
An agent that starts cold on your repo makes statistically reasonable guesses: the popular library instead of the one you use, the conventional folder instead of your domain folder, casts() when your codebase standardized on $casts. None of these are hallucinations. They are defaults filling the vacuum you left. A plan forces the vacuum to be filled by you instead, while corrections still cost one sentence rather than one rolled-back branch.
The Three Questions I Force Before Any Code
My project CLAUDE.md makes Claude answer three questions, in writing, before implementing anything. This is my adaptation of the plan-first workflow Andrej Karpathy has argued for, wired into a real repo:
1. Domain: where does this live? In my repo that means naming the domain first: Blog, Shop, Website, or core, and the sub-area if it is Website. Sounds trivial. It is the single best drift-killer I know, because a model that has committed to "this is a Blog domain change" stops scattering files across three folders.
2. Sibling pattern: which existing file am I copying? Before writing a new Form Request, controller, or Filament resource, the model must point at the sibling it is modeling the new file on. My rule as written: no new abstractions without a reason. Codebases rot one clever one-off at a time, and agents produce clever one-offs at scale unless you make convention the default.
3. Verify steps: which concrete commands prove it worked? Not "make sure it works." Named commands: php artisan test --filter=RelatedTest, vendor/bin/pint, composer test:phpstan, load the page in the browser. Writing the verify step before the code is a bet the model has to place, and it changes what gets written. My file even encodes a repo gotcha here, that composer test runs PHPStan rather than PHPUnit in this project, because a verify step that runs the wrong tool "passes" while proving nothing.
If you adopt one thing from this post, adopt the three questions. They fit in any CLAUDE.md in ten lines.
Build in Feature-Sized Chunks, Not Session-Sized Ones
The second habit: scope every session to something with an observable outcome. "A visitor can filter courses by level" is a chunk. "Build the filtering system" is a fog bank.
Chunks bound the blast radius of a wrong assumption, keep the diff reviewable in one sitting, and, less obviously, keep the context window healthy. Long meandering sessions degrade; the model starts forgetting decisions from two hours ago, and you burn tokens re-establishing things you already settled. Scoping sessions to chunks is context management disguised as project management. When sessions do run long anyway, I lean on the token hygiene habits I covered in 18 Claude Code token hacks.
Make the Model Ask You Questions
Claude Code will interview you about your plan if you tell it to, and almost nobody tells it to. A standing instruction as simple as "before implementing, ask me anything ambiguous, one question at a time" converts the model from a guesser into an analyst. The questions it asks are consistently the requirements I forgot I had.
I eventually promoted this habit into a dedicated skill and then a full five-stage process; if you want the industrial-strength version, that is the 5-skill engineering pipeline. But the one-line instruction gets you most of the value on day one.
Testing Is Part of the Plan, Not a Follow-Up Prompt
Tests written after code, by the same model that wrote the code, mostly confirm the code does what the code does. Tests named in the plan, before implementation, define what the code is supposed to do. That ordering is the entire difference.
Practically: the plan states which tests will exist and what behavior they pin down. Implementation is not done until the named verify commands pass. On this repo a pre-commit hook runs Pint on staged PHP and flags PHPStan issues, so "done" has a mechanical definition that does not depend on anyone's mood, mine or the model's.
Know When to Skip the Ceremony
Plan-first discipline dies when it is applied to everything, because developers correctly refuse to write a plan for a typo. So my CLAUDE.md carries an explicit skip-list, and I think every team's should. Mine says no ceremony for: formatting-only fixes, translation key additions with no logic, seed and factory tweaks, typo fixes in views, and metadata edits.
The skip-list is what makes the discipline survivable. The rule is not "always plan." The rule is "the default is a plan, and the exceptions are written down."
A Workflow You Can Start Today
- Create a
CLAUDE.mdwith the three questions, your build/test/lint commands, and a skip-list. - Pick one feature-sized chunk from your backlog.
- Tell Claude Code: state domain, sibling pattern, and verify steps; then ask me your open questions before writing anything.
- Approve or correct the plan. This is where your expertise earns its keep.
- Let it implement, then run the named verify commands yourself.
- Whatever surprised you, write into CLAUDE.md before you close the session.
Step six is the compounding step. My file's "Quirks" section is a museum of one-time mistakes: cache invalidation gotchas, a Vite manifest error, the PHPStan-not-PHPUnit trap. Each entry cost me time exactly once. Claude Code will even help you find these; its /insights report suggests CLAUDE.md rules from your own session history, and once your workflow rules stabilize, the natural next step is packaging them as skills, which is the nine-skill setup I run now.
The Strategy in One Line
Plan, implement, verify, and make the model show its plan first. It is not glamorous, and that is rather the point: after 8+ years and 1,500+ projects, the practices that survive are the boring ones that compound. Take one feature off your backlog this week and run the loop on it exactly as written, then keep whatever CLAUDE.md you end up with. That same sequence, with real repos and the exact prompts, runs end to end through my AI School courses.
