Tweeted in January about a small problem. Five people on Claude Code. Ten PRs a day. Two to five Drizzle migrations a day. Generate-then-migrate workflow falls apart in PR land.
Here's the specific failure mode and why it generalises.
Drizzle migrations are numbered sequentially. Migration 0042 modifies the products table. Two people open PRs at the same time, each runs the generator, each gets a migration 0042 with a different change. Both PRs pass review. The second one merges and now main has a migration history that branches and reconverges in a way the migration runner doesn't understand. You discover this when you pull main, run the migrations, and the database is in a state nobody designed. You fix it by hand. You write a sentence in team chat about being careful. Three weeks later it happens again, because being careful doesn't scale.
Sequential numbering is the simplest possible coordination strategy. It works when one person controls the sequence. It breaks the moment two people generate concurrently, because the sequence assumed only one author at a time.
Most things that fail when you go from one developer to five fail for exactly this reason. The single-author assumption was load-bearing and you didn't notice. A TODO list in one person's head. A deploy script somebody runs manually on Friday. A build that depends on local env files. A code style enforced by one reviewer. A roadmap maintained in a Google Doc somebody owns. Each works for one person, holds together for two, and produces incidents at five. Not because the team is sloppy, because the design assumed something the new size violates.
For migrations specifically, switch to content-hashed migration names, or use a tool that detects collisions before merge. Some ORMs do this. Drizzle didn't last I checked.
More generally, when you grow past one developer, audit every step in your release process for "what happens if two of us do this at the same time." Anywhere the answer is "we coordinate by talking," you have a future incident. Make the step concurrency-safe or remove it. The work isn't avoiding bugs, it's removing the assumptions that let those bugs exist.
AI coding tools make this problem worse faster. One person with Claude Code produces what five people produced two years ago. Now five people with Claude Code produce what twenty-five did. Every coordination assumption that survived twenty-five engineers fails at five-plus-AI scale, because the agent doesn't read your team chat and doesn't know the convention.
If you're scaling a team with AI in the loop, the engineering bottleneck isn't the code. It's the coordination layer everyone assumed didn't matter because one developer didn't have to think about it.
— Simon