AI Code Review for Laravel Applications

Why Laravel codebases accumulate hidden debt

Laravel applications share a paradox with other convention-heavy frameworks: the same features that make development fast also make long-term maintenance difficult. Eloquent's Active Record implementation lets developers write expressive queries in a few lines, but that expressiveness obscures what the database is actually doing. A simple $user->posts access inside a Blade template loop triggers a separate query for every iteration – the classic N+1 problem – and nothing in the template syntax makes this visible.

Service providers compound the issue. A mature Laravel application might register dozens of bindings in its service container, each with its own dependencies and lifecycle. The boot order of these providers matters, but the framework resolves it implicitly. When two providers depend on each other indirectly, the application works in development but fails unpredictably in production under different request patterns. Understanding the full dependency graph requires reading every provider, every binding, and every deferred resolution.

Facades add another layer of indirection. Calling Cache::get() looks like a static method call, but it resolves through the service container at runtime. This means the real dependency is hidden from static analysis tools and from developers reading the code. A controller that uses six facades has six implicit dependencies that do not appear in its constructor, making it difficult to test, difficult to refactor, and difficult to understand in isolation.

Over time, these patterns interact. A controller action triggers an Eloquent query that fires a model event, which dispatches a queued job, which calls a service that uses three facades. The actual execution path spans a dozen files, none of which reference each other explicitly. Tracing a bug through this chain requires deep framework knowledge and careful manual reading of the entire call graph.

What VibeRails finds in Laravel projects

VibeRails performs a full-codebase scan of every PHP file, Blade template, configuration file, migration, route definition, and queue job in your Laravel application. The AI reasons about framework-specific patterns that static analysis tools treat as opaque:

• Eloquent N+1 queries – lazy-loaded relationships accessed in loops, Blade templates that trigger queries per iteration, and collection operations that defeat eager loading via with() or load()
• Mass assignment vulnerabilities – models with overly broad $guarded or $fillable arrays, controllers that pass $request->all() directly to create() or update(), and form request validators that do not match the model's fillable fields
• Route model binding misuse – implicit binding on models without proper authorisation checks, custom binding logic that bypasses scoping, and route definitions that expose internal IDs without access control
• Middleware order problems – authentication middleware applied after rate limiting, CORS middleware in the wrong group, and custom middleware that modifies the request in ways that conflict with downstream middleware
• Service provider complexity – circular dependencies between providers, boot-time side effects that depend on request context, and deferred providers that resolve at unexpected points in the request lifecycle
• Facade overuse hiding dependencies – controllers and services that rely on facades instead of constructor injection, making dependency graphs invisible and unit testing difficult without the full framework bootstrap
• Queue job error handling – jobs without retry policies, missing failed() methods, jobs that modify database state without transactions, and race conditions between queued jobs operating on the same records
• Blade template logic creep – business logic embedded in Blade directives, complex conditionals that should live in view composers or presenters, and raw PHP blocks that bypass the template engine's escaping

Each finding includes the file path, line range, severity level, category, and a plain-language description with a suggested remediation approach. The structured output transforms an opaque Laravel monolith into an organised inventory of improvements, prioritised by risk.

What PHPStan and Larastan miss

PHPStan with the Larastan extension is the best static analysis tool available for Laravel. It catches type errors, undefined method calls, and some Eloquent misuse. But it operates on individual files and cannot reason about cross-file architectural patterns.

Consider a Laravel application where authorisation logic has drifted. Some endpoints use Gate checks in the controller, others rely on form request authorize() methods, a few use policy classes, and several have no authorisation at all. Larastan can verify that a Gate call references a defined ability, but it cannot detect that half the application's endpoints are missing authorisation entirely. That requires reading every route, every controller method, and every middleware assignment together.

Eloquent query performance is similarly invisible to static analysis. A scope that chains whereHas() with a nested closure creates a correlated subquery that scales poorly with table size. Larastan verifies that the method chain is syntactically valid, but it cannot assess whether the resulting SQL will perform adequately. VibeRails flags these patterns because the AI understands what the Eloquent builder generates and how it behaves at scale.

Configuration drift between environments is another gap. Laravel's .env-based configuration means that queue drivers, cache backends, and database connections can differ between local, staging, and production. When application code assumes a specific driver – calling Redis-specific methods on a cache that might be configured as file or database in another environment – the mismatch only surfaces at runtime. VibeRails identifies these assumptions by reading both the configuration files and the code that depends on them.

Dual-model verification for Laravel

Laravel's convention-over-configuration approach creates genuine ambiguity for automated review. Is that model event listener an intentional design choice for decoupled architecture, or a shortcut that hides critical business logic? Is the facade usage in a service class acceptable for a small application, or a maintainability risk as the codebase grows?

VibeRails supports running reviews with two different AI backends – Claude Code and Codex CLI – in sequence. The first pass discovers issues, the second verifies them using a different model architecture. When both models independently flag the same N+1 query path or mass assignment risk, confidence is high. Disagreements highlight areas where human judgement during triage adds the most value.

From findings to fixes

After triaging findings, VibeRails can dispatch AI agents to implement fixes directly in your local repository. For Laravel projects, this typically means adding with() calls to eager-load relationships, tightening $fillable arrays on models, replacing facade usage with constructor injection, adding missing authorisation checks to controller methods, and extracting Blade template logic into view composers.

Each fix is generated as a local code change you can inspect, test, and commit or discard. The AI works within the conventions of the existing codebase, matching the application's naming patterns, test framework, and directory structure.

VibeRails runs as a desktop app with a BYOK model – it orchestrates Claude Code or Codex CLI installations you already have. No code is uploaded to VibeRails servers. AI analysis is sent directly to the provider you configured, billed to your existing subscription. The lifetime licence is $299 per developer for the lifetime option (or $19/mo monthly). The free tier includes 5 issues per session to evaluate the workflow.