Three AIs, One Edge Function: How I Structurally Prevent Drift in Parallel AI Work
I run several AIs on my code in parallel. It saves time, as long as their work areas don’t overlap. With edge functions, they overlapped — and that cost me more hours than I’d like.
The trigger was unremarkable. Three AIs were working the same area at the same time, and all three touched edge functions in the process. They committed in parallel, sometimes without flagging it clearly. What came out of that was drift.
Drift, briefly
Drift means: several states that should match drift apart unnoticed. Here there were three — the state in the repo, the state in the database, and what each AI believed to be the current state. Every commit without reconciliation widens the gap.
With ordinary application code you catch that quickly. With edge functions tied closely to migrations, you catch it only once something stops deploying or starts behaving strangely.
Edge functions are migration-critical — and that wasn’t front of mind
That’s the real lesson. I’d filed edge functions under code that runs somewhere — decoupled, harmless, easy to parallelize. In reality they hang off the database’s migration state for me, and when several actors work and deploy against them at once without knowing the current state, one overwrites the other’s assumptions.
The tricky part wasn’t the failure itself but the hunt for it. By that point we’d already rebuilt a fair amount. It could have been anything. That’s what eats time: not the fixing, but the narrowing down when the cause sits behind twenty other changes. I still found and isolated it quickly, because while going through it I recognized the parallelism as the pattern — three actors, one resource, no reconciliation.
The fix: a deterministic workflow with a real gate
So I built a workflow that makes this pattern structurally impossible. Four parts.
Pull the state first, then work. Before an AI touches an edge function, it pulls the current state from the database and works against that state — not against its assumption from ten minutes ago. That alone removes the ground drift grows on.
A gate before the deploy. No edge function deployment happens silently anymore. Before deploying there’s an explicit question: do you really want this deployed now? I get informed and get genuine decision points here, instead of facing a done deal after the commit.
Atomic claiming via a running number. This is the core. Anyone who wants to work on an edge function has to pull a number from the table. Only exactly one row can be claimed per number. If the number is taken, you pull the next one. That makes it physically impossible for two actors to occupy the same slot — and as a side effect, everyone sees at a glance whether something is running in parallel or the track is clear.
Every step is checkable. The flow is broken into deterministic steps. I can look at any single step and see what happened and why — instead of ending up with a result whose path I can no longer reconstruct.
What I take away
The expensive part wasn’t the bug. The expensive part was three capable actors working an uncoordinated critical resource — and my having treated that resource as less critical than it is. Parallelism across AI agents is a win, as long as who may touch what and when is clear. The moment a resource is migration-critical, it needs exactly this: a current state before the work, a gate before the effect, and a mechanism that rules out simultaneous access rather than hoping against it.
Conclusion
I didn’t build atomic claiming because it’s elegant, but because a lost afternoon showed me where the sharp edge sits in parallel AI work. The rule behind it is simple enough to apply anywhere: pull the state, claim the slot, ask before the deploy. Three steps that prevent a drift whose hunt costs more than any precaution.
Running several AIs side by side without that kind of coordination is exactly the failure mode the AI orchestration in the boostN app is built to rule out — and the evergreen guide on working in parallel with AI walks through the wider pattern.
Entdecke mehr
Database accidents with AI: rule conflicts, worktree collisions, and what actually protects you
Why migrations slip past the sandbox, how worktrees can wipe your DB, and which layer structurally fixes it.
BlogAI Workflows by Keyword: How We Make Recurring Routines Enforceable
A typed keyword triggers a fixed AI routine — and every single step must be committed before the next one appears. Why that's the actual trick.
BlogMulti-AI Orchestration Without API Costs: Why Your Existing Subscription Is Enough
Headless agents on your own machine, fed by the subscription you already pay for instead of an API bill — how boostN orchestrates many models.