My Laravel AI Development Stack in 2026

I've been writing Laravel professionally for years. The way I build software today looks nothing like how I built it twelve months ago. Not because the framework changed — Laravel 12 is an evolution, not a revolution — but because AI went from something I occasionally pasted code into to the actual foundation of how I work.

This isn't a tools roundup. This is what I actually use every day, why I picked each piece, and how they connect into a workflow that genuinely makes me faster. Not "10% faster with autocomplete" faster. Fundamentally different.

The Editor: VS Code (Heavily Modified)

I'm on VS Code with every AI auto-typing feature turned off. No Copilot tab completions, no inline suggestions, no ghost text. The editor is just an editor — file tree, git UI, syntax highlighting, and a terminal. That's it.

This is deliberate. I don't want the editor doing AI things. I want Claude Code doing AI things, from the terminal, where I can see exactly what's happening and steer it. The editor is the cockpit. Claude is the autopilot. I'm along for the ride, reviewing what it does and nudging when needed. Mixing in a second AI layer from the editor just creates noise.

The AI Engine: Claude Code

Claude Code is a CLI tool. You install it globally, run it in your terminal, and it reads your codebase, edits files, runs commands, and builds features. No IDE plugin, no chat sidebar, no "generate code" button. Just a command line that understands your entire project.

I chose the CLI over IDE-integrated AI deliberately. IDE plugins are constrained by what the editor exposes to them. Claude Code has full filesystem access, can run any shell command, and manages its own context window. When I tell it to build a feature, it reads the relevant files, checks the database schema, looks at existing patterns, writes the code, runs the tests, and fixes what fails. In one conversation.

The real force multiplier is CLAUDE.md. This is a markdown file in your project root (and optionally in ~/.claude/ for global context) that Claude Code reads at the start of every session. Mine contains the project's tech stack, coding standards, the test command (which has specific environment variable handling), generator commands, git workflow rules, and architectural decisions. It means Claude doesn't start cold every time. It already knows this is a Laravel 12 project using Inertia v2 with React, that I use Actions for business logic, DTOs for data transfer, and that tests are written with Pest.

I also use hooks and custom skills for repetitive workflows — commit formatting, PR creation, deployment checks. These are just shell scripts that Claude Code triggers at specific events, and they turn a good tool into a personalised one.

One workflow I rely on heavily is git worktrees with parallel Claude Code sessions. I'll have one session working on a feature branch while another reviews a PR or investigates a bug on a different branch. Each session has its own working directory, its own context, and they don't interfere with each other. It's like having multiple developers who all know your codebase intimately.

The Context Layer: MCP Servers

MCP — Model Context Protocol — is what turns Claude Code from a smart text generator into something that can actually interact with your infrastructure. MCP servers expose tools that Claude can call: query a database, run an artisan command, search documentation, check server status.

I run two MCP servers daily.

Laravel Boost is an official MCP server built by the Laravel maintainers. It gives Claude direct access to my application's database (read queries, schema inspection), artisan commands, route listing, configuration values, and — critically — documentation search that's version-aware. When Claude needs to check how deferred props work in Inertia v2, it searches the docs through Boost and gets back the right answer for my exact package versions. No hallucinated APIs. No outdated v1 patterns. This is the single biggest quality improvement in the code Claude writes for me.

Coolify MCP is one I built and maintain as open source. I self-host on Coolify (more on that below), and this MCP server exposes 35+ tools for managing servers, applications, databases, deployments, environment variables, and diagnostics — all from the terminal. Claude can check deployment status, read application logs, restart services, and diagnose issues without me ever opening a browser. I built it because I was tired of context-switching to a web UI for ops tasks.

The combination is what matters. Claude Code isn't just writing code — it has access to the running application's database, the framework's documentation, and the production infrastructure. That's a fundamentally different capability than an autocomplete engine.

The Framework: Laravel 12 + Inertia v2 + React 19

The stack itself is Laravel 12 with Inertia v2 on the frontend using React 19 and Tailwind v4. I've been on this combination for a while and I don't see a reason to change.

Laravel 12 is rock solid. The streamlined directory structure from Laravel 11 is mature now, middleware configuration in bootstrap/app.php feels natural, and the framework stays out of my way. I use Actions for business logic, DTOs for passing data to Inertia pages, and Form Requests for validation. Standard patterns, well-documented, easy for Claude to follow.

Inertia v2 brought deferred props, polling, infinite scrolling, prefetching, and a proper <Form> component. These aren't flashy features — they're the things that used to require custom JavaScript and now just work. Deferred props alone changed how I think about page loads. Ship the shell immediately, load the expensive data after.

Wayfinder deserves a specific mention. It generates TypeScript functions from your Laravel routes and controllers, so your frontend gets type-safe routing that stays in sync with your backend automatically. No more hardcoded URL strings. No more route name typos caught in production. import { show } from '@/actions/App/Http/Controllers/PostController' and you get full type safety on the parameters.

For testing, Pest v4 is exceptional. The browser testing alone — real Chromium, real interactions, real assertions against your running application — replaced a bunch of manual QA I was doing. I write feature tests for backend logic and browser tests for anything that touches the UI. Claude writes most of the tests, and because it has the Pest docs via Laravel Boost, they're actually good tests.

The Hosting: Coolify (Self-Hosted)

I moved from Laravel Forge to Coolify last year. Forge is a good product. I left because I wanted more control and I wanted to stop paying per server.

Coolify is self-hosted, open source, and handles everything Forge does — server provisioning, deployments, SSL, database management, queue workers — plus Docker-native workflows and a broader range of application types. The setup cost is higher than Forge. The ongoing cost is just your server bill.

My deployment pipeline is simple: push to main, Coolify's webhook fires, the application builds and deploys. No CI/CD service, no build server, no deployment scripts to maintain. It just works, and it works because the application is straightforward enough that it should just work.

The real win is managing Coolify through MCP. I don't log into a dashboard to check if a deployment succeeded. I ask Claude. I don't open a browser to read application logs. Claude reads them and tells me what's relevant. The operational overhead of self-hosting dropped dramatically once I could manage everything from the same terminal where I write code.

The Workflow: How It All Connects

Here's what a typical feature looks like, start to finish:

I open VS Code, start Claude Code in the terminal, and describe what I want to build. Claude reads the relevant codebase files, checks the database schema through Laravel Boost, and looks at existing patterns. It writes the migration, model, action, controller, Inertia page, and tests. I review the code in the editor, make adjustments, and tell Claude to run the tests. It does, and fixes anything that fails.

When the feature is solid, Claude creates a branch, commits the work, and opens a PR. I review the PR, merge it, and push to main. Coolify picks up the webhook and deploys automatically.

If something goes wrong in production, I ask Claude to check the deployment status and read the logs through Coolify MCP. It diagnoses the issue, suggests a fix, and I'm back to writing code in the same terminal session.

The entire loop — write, test, deploy, monitor — happens without leaving the terminal. That's not a small efficiency gain. That's a different way of working.

What's Next

The direction is obvious: more context, more autonomy, less switching. MCP is still early. The protocol will mature, more services will expose MCP servers, and the context available to AI tools will keep expanding. I expect my workflow in another twelve months to involve less manual review and more delegation.

But the foundation is set. A capable AI engine with deep project context, connected to your application's data and infrastructure, integrated into a framework that's well-documented and well-structured. That's not a gimmick. That's a genuine shift in how software gets built.

The tools will keep changing. The principle won't: give AI as much context as possible, connect it to your actual systems, and get out of the way.