Give an AI agent a big, vague task in a Laravel project, walk off to make coffee, and you'll come back to a confident summary, a lot of changed files, and the strong feeling that you now have more work than before you started.

That's rarely the tool's fault. It's the way it's used. Claude Code has been part of my day since Anthropic released it as a research preview in February, and over these weeks I've settled into a workflow that actually saves time instead of creating review debt. Here it is, step by step, with the rules I wish I'd started with.

What Claude Code is, briefly

It's a coding agent that runs in your terminal, inside your project. Unlike a chat window, it can read your files, search the codebase, edit multiple files, and run commands such as your tests, asking for permission before it does anything risky. Under the hood it currently uses Claude 3.7 Sonnet.

That power is exactly why the workflow matters. An agent that can change twenty files can also change the wrong twenty files.

Step 0: a CLAUDE.md that knows the house rules

Claude Code reads a CLAUDE.md file from the project root at the start of every session. It's the onboarding note you'd give a new colleague: how the project is built, what the conventions are, what never to touch. Running /init generates a first draft from the codebase, which I then trim and sharpen.

A cut-down version of what mine look like for a Laravel project:

# Project rules
- Laravel 12, PHP 8.4, MySQL. Follow existing patterns in app/.
- Validation in Form Requests, authorization in Policies.
- Never edit an existing migration; always create a new one.
- Money is stored as integers in minor units, never floats.
- After changes, run: php artisan test --filter=<related test>
- Before finishing, run: ./vendor/bin/pint --dirty
- Never touch .env, deployment scripts or CI config.

Every line in there exists because, without it, the agent made a reasonable-looking choice that didn't fit the project. When I catch myself correcting the same thing twice, it goes into CLAUDE.md. The file grows with the project, and the corrections stop repeating.

Step 1: small, well-defined tasks

This is the single biggest lesson. "Build the invoicing module" is a bad task. "Add a due_date column to invoices, set it from the contract's payment terms when an invoice is created, and cover it with a feature test" is a good one.

Small tasks give the agent less room to wander and give me a diff I can actually review in one sitting. If I can't describe what "done" looks like in two or three sentences, the task is too big, and I split it first.

Step 2: ask for a plan before any code

For anything beyond a one-line fix, I ask it to explore and plan first, explicitly without writing code:

Read the invoice creation flow and the related tests. Then tell me which files you'd change and how, and what could break. Don't edit anything yet.

This step is cheap and catches most problems early. Sometimes the plan reveals it has misunderstood the task. Sometimes it finds an existing helper I'd forgotten about. And occasionally it points out an edge case I hadn't considered. Correcting a plan takes a sentence. Correcting fifteen edited files takes an afternoon.

Step 3: let it work, in a clean branch

Once the plan looks right, I let it implement. Two habits here:

• Start from a clean Git state, on a branch. Whatever happens, git diff shows exactly what changed, and git checkout . is the undo button.
• Read the permission prompts. It asks before running commands. Clicking "yes" on autopilot defeats the point. I approve test runs and code-style tools freely; anything that touches the database or the network gets a proper look.

If I see it heading in the wrong direction, I interrupt with Escape and redirect. Steering early is far better than reviewing a finished wrong answer.

Step 4: tests are the referee

The most useful thing an agent can do is run the tests and react to failures itself. That loop (change, run, read the error, fix) is where it really earns its keep. So I ask for tests as part of the task, not as an afterthought, and I check that they test behaviour: a test that just asserts the code does what the code does protects nothing.

When a project has weak test coverage, the agent is weaker too. It has no referee. That's been a useful nudge to write more tests in general.

Step 5: review every diff like a colleague wrote it

Every change gets the same review I'd give a pull request from a teammate. I look for:

• changes outside the scope I asked for,
• new code that duplicates something the project already has,
• missing authorization checks and validation,
• queries that will be fine with ten rows and painful with a lot more,
• tests that pass for the wrong reason.

The code is mine once I commit it. "The AI wrote it" isn't an explanation I'd accept from anyone, including myself.

Small habits that help

• /clear between unrelated tasks, so old context doesn't leak into new work.
• Point it at examples: "follow the pattern in StorePaymentRequest" beats a paragraph of description.
• Commit in small steps, so a bad later step doesn't take good earlier work with it.
• Use it for the boring parts first: test scaffolding, form requests, factories, migrations, reading unfamiliar code. These are where the speed-up is easiest to trust.

Where I still do it myself

Security-sensitive logic, anything involving money calculations, and decisions about the data model. The agent can help me think, list options and write the boilerplate around them, but the decision stays with me. It's also not great at knowing what the business actually needs, which is often the hardest part of the job anyway.

The tool is still a research preview and it changes fast, so this workflow will change too. But the principles (small tasks, plans, tests, reviews) are just good engineering habits. The agent simply makes skipping them more expensive.

If you're using an AI coding agent, whether Claude Code, Cursor, Copilot or something else, what's the one rule you'd add to this list?