AI review can help with Laravel upgrades, but it should not make the decisions

Laravel upgrades are one of the easiest places to overestimate AI. It looks perfect for the job: large diffs, framework changes, repetitive refactors, and lots of surface area to scan. In practice, AI review is useful, but it is not where the important upgrade decisions get made. I still use AI during Laravel upgrades, especially as a second pass. It catches renamed methods, outdated config shapes, stale imports, and framework-level inconsistencies faster than most humans want to admit. But the more expensive bugs in a real upgrade are usually not syntax bugs. They are judgment bugs. They come from misunderstanding how this codebase uses queues, middleware, auth, caching, tenancy, validation, or exception handling. That distinction changed how I run upgrades now: AI helps me audit the change set, but I do not let it pretend to own the migration. The architectural call still needs a human. Where AI Review Actually Helps The best use of AI in a Laravel upgrade is narrow and mechanical. Give it a diff, the target Laravel version, and a concrete question. That tends to produce useful output quickly. In my experience, AI is good at spotting four classes of issues: Framework API drift: deprecated helpers, signature changes, config keys that moved, middleware registration changes, or updated bootstrapping conventions. Pattern mismatch: places where half the app uses the new pattern and the other half still uses the old one. Upgrade guide coverage gaps: areas you skipped because the app still boots, but the framework now expects a cleaner or safer implementation. Low-level review fatigue: dozens of tiny edits that are individually obvious but easy to miss when you are tired. That matters because upgrade work creates a lot of noise. If you are moving from one Laravel major version to another, the official upgrade guide is essential, but it does not tell you where your specific codebase is fragile. It tells you what changed in the framework. You still need to map that onto your app. The official docs are still the anchor here: Laravel upgrade guide Laravel releases AI becomes valuable when you already know the target and want a fast consistency scan. It is much less valuable when you want it to infer business intent from a codebase it met thirty seconds ago. The Bugs AI Usually Misses The dangerous part of AI review is not that it is dumb. It is that it is plausible. It often produces the kind of answer that sounds senior enough to pass a quick read, while still being wrong in the places that matter. During upgrades, the misses usually fall into three buckets. It does not understand your invariants Laravel gives you abstractions. Your application gives those abstractions meaning. A queue job in one project is a harmless background sync. In another, it is part of a payment pipeline with strict ordering guarantees. A middleware change can look cosmetic until it silently alters tenant resolution or auth context. AI can say, "this code should use the newer registration style," and still miss that the current order exists to preserve behavior around impersonation, locale resolution, or request-scoped caching. That is why upgrade bugs often show up in places that look boring in the diff. The framework changed something generic. Your app depended on the old behavior in a very non-generic way. It tends to normalize toward framework defaults This is one of the biggest traps. AI usually assumes your code should look more like the framework docs. Sometimes that is correct. Sometimes your app intentionally deviates because the default is wrong for your domain. I have seen this show up in exception rendering, validation flow, broadcast auth, guard selection, and database transaction boundaries. The AI recommendation looks clean because it moves the app closer to "standard Laravel." But standard Laravel is not automatically correct Laravel. It cannot rank risk the way a maintainer can Upgrade work is not just about correctness. It is about sequencing. Which change is safe now? Which one should be isolated? Which one needs a feature flag? Which one needs product signoff because it changes observable behavior? AI review is weak at that layer. It can tell you what is different. It usually cannot tell you which difference is worth waking up for at 2 AM. What Changed in My Upgrade Process The useful shift was simple: I stopped treating AI as a reviewer of the whole upgrade and started treating it as a reviewer of prepared evidence. That means I now structure the upgrade before I ask AI to look at anything. I keep an upgrade notes file Before changing code, I write down the target version, the official upgrade notes I expect to touch, risky subsystems, and known app-specific deviations. This dramatically improves both human review and AI review, because the work has context. A stripped-down version looks like this: ## Laravel 12 Upgrade Notes ### Expected framework touchpoints - bootstrap / app configuration - exception handling - middleware registration - queue + scheduler behavior - auth / guards - validation and request objects ### App-specific risk areas - tenant resolution depends on middleware order - admin guard differs from default web guard - payment jobs rely on serialized DTO shape - API clients retry through custom exception mapping ### Non-goals - no opportunistic refactors - no config cleanup unrelated to upgrade - no auth redesign during this PR This is not documentation theater. It forces scope control. It also makes bad AI suggestions easier to reject, because you already wrote down the constraints. I separate mechanical changes from behavior changes If an upgrade PR mixes signature updates, container changes, config rewrites, auth cleanup, and test rewrites, the review quality collapses. AI becomes noisier and humans become less reliable. So I split the work. Mechanical compatibility changes go first. Behavior-preserving test updates come next. Architectural changes happen only if the upgrade genuinely requires them. That separation matters because AI is strongest in the first category and weakest in the third. Example: A Change That Looks Safe but Is Not A common upgrade trap is middleware or bootstrap registration. Laravel evolves how the application is configured, and AI will often recommend moving everything to the modern pattern immediately. Sometimes that is fine. Sometimes it breaks assumptions hidden in execution order. Here is the kind of thing that deserves human attention: ->withMiddleware(function ($middleware) { $middleware->alias([ 'tenant' => \App\Http\Middleware\ResolveTenant::class, 'admin' => \App\Http\Middleware\RequireAdmin::class, ]); $middleware->appendToGroup('web', [ \App\Http\Middleware\ResolveTenant::class, \App\Http\Middleware\ApplyTenantLocale::class, ]); }); An AI review may say this is fine, or suggest a cleaner registration style. The real question is different: what depends on that order? If ResolveTenant used to run earlier through a previous kernel arrangement, moving it without checking can break: tenant-aware route model binding locale selection before validation messages are built per-tenant cache prefixes auth guard resolution for admin subdomains None of that is obvious from the framework diff alone. You need application context, and you need tests that prove the contract. The right follow-up is not "does this match the docs?" It is "what user-visible behavior did this ordering previously guarantee?" Tests Are the Real Counterweight If you want AI review to be useful during upgrades, give it a codebase with strong regression tests. Otherwise you are asking a language model to do architecture and QA at the same time, which is where the fantasy starts. I now treat tests as the primary control system and AI as a secondary scanner. Write tests around the risky edges first Before or during the upgrade, I want tests around: request lifecycle assumptions auth and permission boundaries queue serialization and retries exception-to-response mapping integration points with external services For example, if your app depends on a custom exception becoming a specific JSON error shape, lock that down explicitly: it('maps billing exceptions to a stable API response', function () { $this->mock(\App\Services\BillingGateway::class) ->shouldReceive('charge') ->andThrow(new \App\Exceptions\BillingDeclined('Card declined')); $response = $this->postJson('/api/checkout', [ 'plan' => 'pro', 'token' => 'tok_test', ]); $response ->assertStatus(402) ->assertJson([ 'message' => 'Payment could not be processed.', 'code' => 'billing_declined', ]); }); That test does more for upgrade safety than five pages of AI commentary. It preserves the contract that matters. Once those tests exist, AI becomes more useful because it can help identify other places where similar assumptions may have drifted. Use AI to ask targeted test questions This is where the workflow starts to work well. Instead of asking, "review my Laravel upgrade," ask narrower questions: Which touched areas lack regression tests? Which renamed methods or config shifts appear incomplete? Which custom exceptions, guards, or jobs are likely sensitive to framework lifecycle changes? That framing keeps AI in the lane where it adds leverage. Human Review Still Owns the Last Mile The final review on an upgrade should not be a generic "LGTM" pass. It should be a risk review by someone who understands both Laravel and the business behavior behind the app. What I care about in that last pass is not whether the code looks modern. I care about whether the upgrade preserved the contracts we actually rely on. A useful human review usually asks questions like: Did we change behavior, or only compatibility? Did any framework-default recommendation override an intentional local design? Do the tests cover the scary paths, not just the happy paths? Did we quietly mix upgrade work with cleanup work that should have been separate? That last point matters more than teams admit. Upgrade PRs get dangerous when they become an excuse to tidy architecture. Cleanups feel efficient in the moment, but they destroy your ability to isolate regressions. My rule now is blunt: if a change is not required for the upgrade, it needs a stronger reason than "we were already in the file." The Practical Rule I Use Now AI review is worth using in Laravel upgrades, but only after you define the problem properly. It is a strong second pass for mechanical drift, incomplete migrations, and consistency checks. It is a weak substitute for architectural judgment, regression strategy, and knowledge of why your app is weird in the first place. So the process I trust looks like this: Read the official Laravel upgrade notes. Write app-specific upgrade notes before touching code. Split mechanical edits from behavioral changes. Lock down risky behavior with tests. Use AI for targeted review, not for ownership. End with human review focused on invariants and risk. If you only remember one thing, make it this: AI can help you finish a Laravel upgrade faster, but it cannot tell you what your application is allowed to break. That call is still yours, and pretending otherwise is how "successful" upgrades ship regressions. Read the full post on QCode: https://qcode.in/ai-review-for-laravel-upgrades-is-useful-but-not-enough/