This site is built and maintained with an AI coding agent working alongside me: Claude Code, with Laravel Boost installed in the project. It is not a demo app. It has an admin panel, three MCP servers, an AI article pipeline, a workflow library, and a production deploy on every push to main. Our VividSol products, LaunchLancer and Invitation Arts, are built the same way.

The Laravel world has moved quickly here. Boost ships guidelines and tools for agents, Laravel announced a first-party language server at Laracon US 2026, and Pest 5 added a way for coding agents to check their own changes. The tools are good. What decides whether an agent helps or makes a mess is what the repository tells it.

These are the practices that made the difference on this codebase.

Write the conventions down where the agent reads them

The project has a CLAUDE.md file, largely generated by Boost, that every session reads first. It holds the things I used to repeat in code review:

  • PHP 8 constructor property promotion, explicit return types, and curly braces on every control structure.
  • PHPDoc blocks with array shapes instead of inline comments.
  • Create files with php artisan make: commands rather than by hand.
  • Run Pint on changed files before finishing.
  • Every change gets a test, and only the affected tests run while working.

None of these are opinions an agent can infer from a few files. Written down, they are followed. Unwritten, every session picks its own style.

Give it documentation for the versions you actually run

Most wrong code from an agent is correct code for a different version. This project runs Laravel 13, Tailwind CSS v4, and PHPUnit 12, and the model's training data is full of Laravel 9 and Tailwind 3.

Boost's search-docs tool returns documentation matched to the installed package versions. The project's instructions say to search before changing code. That single habit removed most of the "this method does not exist" mistakes.

Let it look before it writes

Boost also gives the agent read-only views into the running app: the real database schema, read-only queries, recent browser logs, and the correct local URL. An agent that checks the actual columns before writing a migration, or reads the browser error before guessing at a fix, behaves much more like a careful colleague.

The word that matters is read-only. Looking is cheap and safe. Writing goes through code, tests, and review.

Load domain knowledge only when it is needed

Boost installs skills for specific areas: the Laravel AI SDK, MCP development, Tailwind, and Laravel best practices. Each holds focused guidance that the agent loads when it works in that area, instead of everything being pushed into every session. When the agent builds an MCP tool, it works from MCP guidance, not from general memory of a protocol that changes quickly.

Turn preferences into tests

This is the practice I would recommend first. Some of my rules are about copy, not code: the site leads with full-stack web development and puts automation second, writes "Full-Stack" with a hyphen, and keeps framework names other than Laravel out of headings and search descriptions. Rules like that are easy to break by accident in a long session.

So they are tests. A PositioningCopyTest loads the real pages and checks the title, the meta description, the order of sections, and every heading:

preg_match_all('/<h[1-6]\b[^>]*>.*?<\/h[1-6]>/s', $html, $headings);

foreach ($topLevelCopy as $label => $copy) {
    $this->assertStringNotContainsString('Vue', $copy, "The {$label} should not mention Vue.");
    $this->assertStringNotContainsString('React', $copy, "The {$label} should not mention React.");
}

An agent cannot silently regress a rule that fails the suite. Neither can I.

Keep a memory of decisions the code does not show

Some decisions leave no trace in the code: why a design choice was made, which work is deliberately kept off the public site, how production is deployed. Claude Code keeps short memory notes for this, one fact per note with the reason behind it. The next session starts already knowing that a choice was deliberate, instead of "fixing" it.

People own commits and deploys

On this project the agent does not commit unless I ask, and a push to main deploys to production. That boundary is deliberate. The agent proposes changes and runs the tests. I read the diff and decide when it ships. Reviewing a diff takes minutes. Untangling an unreviewed commit that is already live takes much longer.

Where it still needs watching

  • Local is not production. An agent will happily reason from the local database. Before claiming something about the live site, it should check the live site.
  • Overbuilding. Asked for a small change, an agent may also refactor the neighborhood. Scope the request and read the whole diff.
  • Generic copy. Agents write fluent, forgettable text. Content still needs a person with something to say.
  • Secrets. The instructions say never to print or commit them, and the deploy tooling is written so it does not need to.

My take

An AI coding agent is only as good as the context the repository gives it. Written conventions, version-matched documentation, read-only access to reality, preferences captured as tests, and a person who owns the commit turn it from a fast typist into a useful pair. None of that is specific to Laravel, but Laravel's first-party tooling makes most of it a single composer require away. Several of the products on my Projects page are built this way.