Claude Code Laravel: practical setup, prompts, and testing

Claude Code is an agentic coding assistant that works inside your Laravel repository: start Claude Code with claude in the project root, describe a change in plain English, and it reads the code, edits files, runs Artisan commands, and executes your test suite. For Laravel teams, this means faster feature delivery if you set up Laravel-specific context and review its work the same way you would review a colleague’s pull request.

Why Claude Code fits Laravel work

Laravel’s value comes from strong conventions: Eloquent models, migrations, service providers, named routes, form requests, Blade views, and queued jobs. Claude Code is useful because it can spread a change across all of those layers in one task. Instead of hand-editing three files and forgetting the test, you can ask it to add a last_login_at column, update the User model, write a migration, and update the feature test. It also runs the commands you already use: php artisan migrate, php artisan test, php artisan route:list, and composer scripts. Because it reads the whole project tree, it can follow the conventions that already exist in your codebase, such as how you name service classes or how you use form requests.

Setting up the project for Claude Code

The highest-leverage file is CLAUDE.md in the project root. Claude Code reads it as persistent instructions. Keep it short and project-specific: do not paste the entire Laravel documentation. Include the commands you actually run, the folders that matter, and rules that stop common Laravel mistakes. Here is a realistic example:

# Laravel project commands
composer test      # PHPUnit or Pest suite
composer lint      # Laravel Pint
composer stan      # PHPStan level 5

# Folders that matter
app/Models
app/Http/Controllers
app/Services
database/migrations
database/factories
routes/web.php
routes/api.php
resources/views

# Rules
- Always run `composer test` after changing code.
- Use Eloquent query builder, not raw SQL, unless a raw expression is justified.
- Put reusable domain logic in app/Services, not controllers.
- Use form requests for validation.
- Every migration must be reversible and use foreign keys when referencing other tables.
- Run `php artisan migrate:fresh --seed` before switching branches.
- Blade templates should not contain business logic.
- Follow Laravel naming conventions: model App\Models\Post maps to table posts, pivot tables alphabetical_snake_case.

Put this file in version control and update it when you change your testing or formatting commands. A good CLAUDE.md is like an onboarding note for a new Laravel developer: it tells the agent which conventions matter and which commands prove a change is correct.

A working loop for Laravel changes

Work in small slices; do not ask for a 12-file feature in one prompt. Start by asking Claude to inspect the relevant code and propose a plan. If you prefer a proposal before any file changes, use plan mode first. This loop follows the checklist in Claude Code best practices: a practical checklist. After you approve the plan, let it implement one vertical slice: migration, model, controller or service change, and a test. Run the focused test before moving on. Review the diff with git diff or your IDE, then ask for the next slice. If a test fails, paste the failure into the conversation and let the agent repair only what caused the failure. This loop keeps the agent inside existing Laravel conventions and makes it much easier to reject a bad change.

Example prompts:

• Add a slug column to the posts table, populate it from the title in the Post model, and add a uniqueness constraint. Run migrations and the Post feature tests when done.
• Create an Artisan command app:send-reminders that queues an email for users with overdue todos. Use the existing Todo model, create a queued job, and add a feature test that fakes the queue.
• Refactor the checkout action in OrderController into app/Actions/PlaceOrder.php with a form request for validation. Keep the controller thin and update existing order tests.
• Find and fix N+1 query problems on the admin dashboard without changing the rendered output. Show the eager loading changes and run the dashboard tests.
• Generate a tags resource with a many-to-many relationship to posts: migration, pivot table, model, controller, requests, and Blade views that follow the existing resource controller pattern. Run tests and migrate.

Where Claude Code shines and where to watch it closely

Claude Code handles repetitive Laravel tasks well: resource scaffolding, migrations, Eloquent scopes and relationships, Blade partials, queued jobs, and feature tests. It is also good at cross-file refactors such as renaming a model binding or moving validation into form requests.

However, it can make mistakes that are specific to Laravel. Watch closely when it touches migrations: it may edit an existing migration instead of adding a new one, forget a foreign key constraint, or write a destructive down() method. In Eloquent, it may accidentally introduce N+1 queries, eager load too much, or use whereHas when a simpler join would be clearer. It may also bypass your project’s DI convention by using new instead of constructor injection, or put business logic into Blade with @php blocks. In queued jobs, it may not make a job idempotent or may forget to dispatch through a queueable class. Always review the diff for these patterns before accepting work.

Testing and verification with the agent

Make the test suite the source of truth. Ask Claude to run a focused test first, then the full suite before you review. After that, ask it to run your formatter and static analysis. A practical verification table for a Laravel change looks like this:

For queue or scheduler changes, ask for a description of how the job is dispatched and have the agent run the relevant worker or scheduler test in a fake context. When you see a red test, paste only the failure text back; do not let Claude rewrite unrelated tests. Finally, have it summarize the diff with git diff --stat, and review migration files manually before applying them.

Running several agents on a Laravel project with AgentVera

When one agent is not enough for parallel Laravel workstreams, AgentVera lets you run multiple Claude Code agents in parallel in real terminal panels. Give each agent its own git worktree so one can change migrations while another works on Blade views without overwriting files. Automatic code review by a second model after a turn catches Laravel-specific issues like missing eager loading or an irreversible migration. Checkpoints let you undo a change and replay, and token budgets cap spending without losing the conversation.

Wrap-up

Claude Code can be a strong Laravel pair programmer if you invest in a concise CLAUDE.md, work in small test-driven slices, and review its diffs with the same care you would give a teammate. The main wins are faster cross-file changes and fewer forgotten tests; the main risks are Laravel-specific conventions around migrations, Eloquent, and DI. Put those guardrails in place, and the agent becomes a useful part of your PHP workflow.