My personal site runs on Laravel 13 with Livewire 4 and Filament 5. It uses Nuno Maduro's starter kit — the one that enforces PHPStan at max strictness, Rector with predefined rule sets, and 100% test coverage. Not aspirational targets. Enforced. The CI pipeline fails if any of them drop.
I fell in love with the code this setup produces. Elegant, clean, organized. And with full coverage, fixing bugs feels safe.
Then I read about a new skill added to Laravel Boost called laravel-best-practices. It gives your AI agent 19 categories of architectural rules — database performance, security, scheduler configuration, queue retry logic, caching strategies, migration discipline. If you want the full breakdown of what the skill covers, Notes on Laravel already wrote that article. I'm not going to repeat it.
What I want to talk about is what happens when you run it against a codebase that's already passing every static analysis and coverage check you can throw at it.
What PHPStan and Rector actually catch
PHPStan at max level catches type mismatches, null coalescing on non-nullable types, unreachable code paths, incorrect return types. Before the code ever runs. Rector rewrites idioms automatically: constructor property promotion, array unpacking, arrow functions, match expressions. Together they enforce mechanical correctness with zero tolerance.
What they don't see is architectural intent.
A query inside a loop is valid PHP. A missing database index is syntactically correct. An unthrottled route compiles fine. A scheduled command without overlap protection passes every type check. These tools enforce type safety and modern syntax. They don't ask whether you should be making 47 queries to render a page.
What the audit actually found
I ran the audit expecting maybe two or three minor flags. It found more than that.
Missing Model::preventLazyLoading(). The service provider called Model::automaticallyEagerLoadRelationships() but never set preventLazyLoading(! app()->isProduction()). Every N+1 bug was invisible during development, only showing up as slow pages in production. The fix is one line.
Missing database indexes. Two migration files had columns used in WHERE and ORDER BY clauses on nearly every page load with no indexes. A status column, a published_at column, and a slug column missing a unique constraint while its sibling table had one. These only show up under load or in EXPLAIN output.
Unbounded queries in a background action. The sitemap generator iterated over records using ->each() without chunk() or cursor(). For a small dataset it works. For a growing one, it loads everything into memory. The fix: swap ->each() for cursor().
Scheduled commands without guards. command should have withoutOverlapping() to prevent two instances from colliding if one runs long. On multi-server deployments, onOneServer() stops it from running N times simultaneously. And environments(['production']) keeps it from firing in staging or local. These are easy to forget because the command works fine without them. Until it doesn't.
No throttle middleware on the contact form route. Low real-world risk for a portfolio site. Still valid. A contact form without rate limiting is an open invitation for spam bots.
Hardcoded email in application logic. I hardcoded an admin email early in the project and forgot about it. The config file existed, the environment variable existed. I just never wired it to the one place that actually checks panel access. The skill pointed straight to it.
What it got wrong
The audit noted the absence of Route::resource() and Route::apiResource(). Expected — the entire frontend is Livewire Volt pages. There are no traditional controllers. The skill applied a general rule without knowing the architecture.
It also flagged the lack of Cache::remember() or Cache::flexible() on any queries. For a personal portfolio site with low traffic, adding a caching layer introduces invalidation complexity that isn't worth the tradeoff yet. Valid observation, wrong priority.
This is the important thing to understand about the skill. It applies general rules. It doesn't know your deployment setup, your traffic patterns, or which decisions you made deliberately. Every finding needs a judgment call. Fix it, note it as intentional, or ignore it.
Between "passes CI" and "handles production"
The best-practices skill covers the space between "the code compiles and passes tests" and "the code handles real-world conditions." Missing indexes, lazy loading leaks, unprotected schedulers, unthrottled routes — these are production concerns, not type-safety concerns.
I fixed five of the six findings in under an hour. The caching suggestion stays on a list for when traffic justifies it.
References
Notes on Laravel — full breakdown of the skill's 20 rule categories
laravel/boost — SKILL.md on GitHub (MIT licensed)
nunomaduro/laravel-starter-kit — the starter kit with PHPStan max + Rector + 100% coverage
