AI Agents for Laravel: Boost Setup and a Safe Workflow

An AI coding agent can write a controller, a migration and a test in a minute. It can also invent a method that does not exist in your Laravel version, ignore how your project is structured, and tell you everything works without running anything.

Getting good results is less about the agent and more about what you give it: accurate context, a way to check its own work, and limits on what it may touch. This guide covers that setup for Laravel, using Laravel Boost, the official package for this job, and a workflow that keeps you in control.

What goes wrong without setup

A general-purpose agent knows Laravel from its training data, which mixes versions. Typical results are code written for an older release, queries that ignore your actual schema, and a new style next to your existing one.

It also cannot see runtime problems: the exception in your log, the table columns in your database, or what your last request returned. An agent that can read those things fixes its own mistakes. One that cannot guesses.

Step 1: Install Laravel Boost (development only)

Laravel Boost gives agents Laravel-specific guidelines, skills and an MCP server connected to your running app. Install it as a development dependency, then run its installer:

composer require laravel/boost --dev
php artisan boost:install

The installer asks which agents you use and which parts to set up. You can also run parts separately: --guidelines, --skills and --mcp.

In the current source (v2.10.4, released 29 October 2026), Boost knows these agents: Claude Code, Codex, Copilot, Cursor, Junie, Kiro, OpenCode, Zed, Amp, Antigravity, Grok Build and Pi.

For several of them the guidelines go into AGENTS.md in your project root. Claude Code uses CLAUDE.md if that file already exists and AGENTS.md otherwise, its skills go into .claude/skills, and its MCP configuration into .mcp.json.

Boost requires PHP 8.2 or newer and supports Laravel 11, 12 and 13. Commit the generated guidelines so the whole team shares them. Keep them current when you upgrade Laravel or add packages:

php artisan boost:update
php artisan boost:list-skills

What the agent can do through Boost

The MCP server exposes tools the agent can call while it works. From the tool definitions in the source:

• Search docs - Version-specific Laravel documentation for the packages installed in your project
• Database schema and connections - Your real tables and columns instead of guessed ones
• Database query - Read-only SQL (SELECT, SHOW, EXPLAIN, DESCRIBE); write statements are rejected, and the query runs inside a read-only transaction
• Tinker - Runs PHP in the application context, like artisan tinker
• Last error and log entries - The latest exception and application log lines
• Browser logs - Frontend console errors
• Absolute URL - Correct URLs for routes, so the agent can check pages
• Record rule - Saves a project rule into .ai/rules, only when you explicitly ask for one to be remembered

This list reflects the source at the time of writing. For example, an older application-info tool was removed in v2.10.4, so tool names in older tutorials may not match what you get.

Step 2: Use a workflow, not one big prompt

The pattern that gives consistent results is small steps with a check after each one.

• Ask for a plan first. "Plan how to add invoice PDF export: which files change, which routes, which tests. Do not write code yet." Fix the plan before any code exists.
• Write the test first. "Write a feature test for the export endpoint that fails right now." A failing test is a precise definition of "done".
• Implement in small pieces. One migration, one model, one controller action at a time, not the whole feature.
• Make the agent run the checks. Tell it to run the tests and the formatter, and to read the output:

php artisan test --filter=InvoiceExportTest
./vendor/bin/pint --dirty

• Review the diff yourself. Read every line before you commit. You own the code that ships.

A prompt in this style, for a change in an existing project:

Add soft deletes to the Project model.

• Check the real projects table schema first.
• Create the migration and update the model.
• Update the existing ProjectTest so it covers restoring a project.
• Run php artisan test and fix failures. Do not change unrelated files.
• Show me the migration SQL with php artisan migrate --pretend before running it.

migrate --pretend prints the SQL a migration would run without running it, which is a cheap safety check on anything the agent generates.

Step 3: Set guardrails

• Keep Boost out of production. It is a dev dependency, and in the source its server only starts when the app environment is local or when APP_DEBUG is true. Production should have neither. A server with APP_DEBUG=true would qualify, which is one more reason never to run production that way.
• Point agents at a local database with fake data. The query tool is read-only, but Tinker can run any PHP, including writes. Never give an agent production credentials.
• Review security-sensitive code by hand. Authorization (policies and gates), validation rules, mass-assignment settings and file uploads are where plausible-looking code is often wrong. A missing authorization check does not fail any test unless someone wrote one.
• Review migrations before you run them. Dropping a column or changing a type on a large table is not something to approve by skimming.
• Look for performance mistakes. Agents readily write queries inside loops. Check for N+1 patterns in anything that lists records.
• Keep secrets out of the conversation. Do not paste .env contents into prompts.
• Use version control as your undo button. Work on a branch and commit after each working step.

Common mistakes

• Accepting "done" without evidence. If the agent did not run the tests, ask it to. Only a passing run counts.
• Prompting for a whole feature at once. Large changes bury mistakes in a big diff that nobody reviews well.
• Stale guidelines. After upgrading Laravel or adding packages, rerun boost:update, or the agent keeps following old conventions.
• Letting the agent restyle your code. Tell it to follow existing patterns, and keep formatter changes to files it touched.
• Treating generated tests as proof. An agent that writes both the code and the test can encode the same misunderstanding in both. Read the assertions.

Agents inside your app are a different thing

Everything above is about agents that help you write the application. If you want an agent as a feature of your product (a support assistant, a tool-calling workflow), that is the Laravel AI SDK, covered in the Laravel AI SDK article. The two combine well, since a coding agent can help you build SDK-based features.

Frequently asked questions

Which coding agent works best with Laravel? Boost supports a dozen of them, and I have no evidence that one is clearly better. Choose by workflow (terminal, editor or IDE) and test two on a small real task from your own project.

Do I need Boost to use an AI agent with Laravel? No. Any agent can edit Laravel files. Boost adds the project context and the runtime tools that reduce guessing.

Is it safe to let an agent run commands? Run it in a development environment, with a throwaway database, on a branch, and review what it ran. Keep production access out of reach.

Will it write my whole application? It can produce a lot, but you still need to know what good looks like. People who understand Laravel get far better results because they can plan the work and review the output.

Originally published on DEV Talk.