Yesterday I got assigned to a new project. Not a greenfield one, an existing Laravel 12 codebase, and I was genuinely excited. New stack to poke around in, new patterns to learn.
Here’s what I was walking into:
On paper, this is a nice stack. I opened the docs first, like I always do, and they were actually maintained. Someone had even documented migration columns. I remember thinking, okay, good, this is going to be a smooth setup.
It was not smooth. It took me a day and a half just to get the project running locally.
Some of that was Docker being Docker — a networking issue between the app container and Postgres that I’ve fought before on other projects and will fight again. Annoying, but familiar territory. I can live with that.
What actually got me was the migrations.
I ran a fresh migration and immediately hit a foreign key error: the table it was pointing to didn’t exist yet. So I went digging into the migration file. The foreign key change had been committed two weeks ago. The table it referenced? Created three months ago. Except someone had renamed the migration files at some point, which shuffled their execution order, and now the table-creation migration was running after the migration that needed it.
So I did what you do: opened every migration file, checked the timestamps against what they actually created, and manually renamed a chunk of them back into the right order. That ate most of my afternoon.
The thing that stuck with me wasn’t the bug itself. Migration ordering breaks, I get it, it happens. What stuck with me was the rest of the codebase. Services, form requests, API resources, tests actually written for the functionality they claimed to cover — it was clean. Someone clearly cared about this project. And then I checked the commit history and found the migration changes had been written by AI.
Which, fine. I use AI for code too. That’s not the problem. The problem is nobody ran it. Nobody opened a fresh database and typed migrate:fresh before merging. If they had, this would've thrown the exact same foreign key error I hit, immediately, in about four seconds. Instead it sat there for two weeks, waiting for whoever onboarded next to find it the hard way.
And it didn’t stop at migrations. The seeder file had its own set of issues too, presumably for the same reason — written fast, never actually run against a clean database.
I don’t think this is really a story about Laravel, or about AI writing bad code. The migration file itself wasn’t wrong in isolation. It’s a story about order — literally, in this case, since migration order is the whole mechanism Laravel uses to know what to build before what. You can write a perfectly correct migration and still break everything if it runs at the wrong point in the sequence. And that’s exactly the kind of thing you only catch by running it, not by reading it.
If there’s a takeaway, it’s a boring one: AI-generated code isn’t the risk. Merging AI-generated code without executing it is. A migrate:fresh on a clean database costs you thirty seconds. Skipping it cost me half a day, and it'll cost the next person who clones this repo the same. I still like this codebase. The parts a human clearly sat down and thought through are genuinely good. I just wish someone had spent thirty seconds checking the part they didn’t.
Anyway, this is my first week on the project, so I’m sure there’s more waiting for me. If you’ve walked into a codebase and lost a day to something that should’ve taken thirty seconds to catch, I’d genuinely like to hear it. Drop it in the comments — misery loves company, and I could use a reminder that this happens to everyone.
I Spent My First Day on a New Laravel Project Fixing Migrations an AI Wrote was originally published in Stackademic on Medium, where people are continuing the conversation by highlighting and responding to this story.