AI in a Laravel Project: From Migrations to Safe Refactoring

Laravel is one of the frameworks AI knows best: tidy documentation, a large community and plenty of sample code. As a result, generated code is usually clean and familiar.

The problem lies elsewhere: the model has seen every Laravel version at once and sometimes mixes the structure of a few years ago with today's. This article is about getting code that fits your own project, from migrations to refactoring.

What context should you give the AI?#

The exact Laravel and PHP versions, the runtime environment, and the real files related to the task; not the whole project.

Two commands give most of the information you need:

php artisan about
composer show laravel/framework

The first command shows the Laravel and PHP versions, the environment, the cache and queue drivers and more. Read the output and remove any sensitive value before sending it. Mention the runtime environment too: code that works on a VPS may hit disabled PHP functions on shared hosting. We covered the limits of that kind of hosting in the shared hosting checklist for Laravel.

A common example of version mixing: in the newer Laravel structure there is no app/Http/Kernel.php, and middleware is registered in bootstrap/app.php. A model that does not know your version may still say "add this to the Kernel". The simple fix: attach a real file from the project, such as that same bootstrap/app.php, so the model can see the structure.

How do you review migrations written by AI?#

Generate the migration quickly, but before running it check the down method, the indexes and the effect on existing rows.

Suppose you want to add a shipment tracking code to the orders table and speed up each user's order report:

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    public function up(): void
    {
        Schema::table('orders', function (Blueprint $table) {
            $table->string('tracking_code', 64)->nullable()->after('status');
            $table->index(['user_id', 'created_at']);
        });
    }

    public function down(): void
    {
        Schema::table('orders', function (Blueprint $table) {
            $table->dropIndex(['user_id', 'created_at']);
            $table->dropColumn('tracking_code');
        });
    }
};

Before running it, go through this checklist:

Then look at the final SQL without running it:

php artisan migrate --pretend

On the production server, run it only after a full database backup. If you get an error, see how to report it to the AI in debugging with AI.

How does AI help with Eloquent queries?#

Its biggest help is finding redundant queries, especially the N+1 problem, and suggesting eager loading.

The N+1 problem means that to display a list, one query runs for the list itself and a separate query runs for each row:

// 51 queries: one for the orders and one for each order's customer
$orders = Order::latest()->take(50)->get();

foreach ($orders as $order) {
    echo $order->customer->name;
}

// 2 queries in total
$orders = Order::with('customer')->latest()->take(50)->get();

AI finds this pattern well in a controller or a Blade template, as long as it can see both. To make Laravel itself warn you in development, put this line in the boot method of AppServiceProvider:

use Illuminate\Database\Eloquent\Model;

Model::preventLazyLoading(! $this->app->isProduction());

To count the real queries on each page, tools such as Laravel Debugbar or Telescope are more accurate than the model's guess.

How do you refactor safely?#

Refactoring means changing the structure of code without changing its behavior. To stay safe: tests first, then a plan, then small steps, one commit per step.

Suppose the store method in OrderController has grown to two hundred lines and handles order creation, stock deduction, payment and email all together.

1. Write tests first that cover the current behavior. Without tests you cannot tell whether the refactor broke something. The method is described in writing automated tests with AI.
2. Ask for a plan, not code.
3. Run each step separately, read its diff the way AI code review describes, and then run the tests.
4. Commit every green step so you have a way back if the next step breaks.

A Laravel project on PHP 8.3. I attached the store method of OrderController.
I want to move the order creation logic into a separate Action class.

Do not write code yet. Give me a refactoring plan in small steps, so that
the application works after each step. The external behavior, routes and
database structure must not change.

Where should you be extra careful?#

The model makes the most mistakes where it knows nothing about your version, packages or environment.

• A package that does not exist or is abandoned: before composer require, find the package on Packagist and check the date of its last update.
• A made-up method: if you do not recognize a method, search for it in the official Laravel documentation.
• Queues and scheduling on shared hosting: the model usually assumes you can run a permanent process.
• Changes to configuration files: review changes to config or .env separately; their effect is felt across the whole application.

Where is AI in Laravel heading?#

The direction is clear: tools get more access to the real structure of the project, such as routes, models and the database schema, and rely less on their general memory. Multi-file work, from migrations to tests, is also increasingly handed to agents.

To get ready, keep your project readable: write coding rules and folder structure in a short guide file at the project root, keep tests fast and reliable, and update Laravel regularly so the gap between your code and what models know best does not grow. The clearer the project is to a new teammate, the clearer it is to AI too.

Summary#

• Give the Laravel and PHP versions, the runtime environment and one real file from the project with your request.
• In migrations, check down, nullable columns, indexes and table size, and run --pretend first.
• Fix the N+1 problem with with and turn on preventLazyLoading in development.
• Refactor only behind tests, with a plan beforehand and small committed steps.
• Look up an unfamiliar package or method in the official source before using it.