It was late. Three terminals open, a Supabase dashboard in another tab, Claude Code chewing through migration files, and a second Claude surfacing new rabbit holes every few minutes. I was deep in Sprint 3 of a 24-sprint plan, trying to close out a governance retrofit that — if I'm being honest — most founders would have just shrugged at.

That shrug is where a lot of systems quietly die.

Here are the two things that session clarified for me.

1. AI will fall short. The question is whether your system catches it.

A geometric lattice stretched across a dark field, particles drifting above, one caught at the mesh and glowing amber while others have fallen through below

Somewhere in that late-night session, the AI I was working with hallucinated a migration file that didn't exist. A little later, it deferred a scope item to "my mental list" after I'd explicitly asked it to log everything to the tracker. A little after that, it let a co-author attribution slide by on a commit without flagging it.

None of those are catastrophic. Each one, on its own, is the kind of thing you miss at 11 PM and pay for in month six.

Here's what I want builders working with AI to actually internalize: AI is going to fall short. It's going to invent things, skip things, let small inconsistencies slide. That is not a bug you're going to prompt your way out of. It's a property of the tooling at this moment in time.

The instinct didn't come from AI. It came from ten years as a BA.

I didn't invent my response to drift while building SQUEIL. I built it over ten years as a CBAP-certified business analyst, watching what happens when foundational requirements drift gets discovered in production instead of in the requirements phase. Every BA alive has lived the 1:10:100 rule — the cost of a defect roughly multiplies by ten with every phase it escapes into.

A rising exponential curve titled "The cost of finding it later," showing 1x cost at Requirements, 5x at Design, 10x at Code, 20x at Test, and 100x at Production

I've paid the rightmost column of that curve more times than I want to count. A misunderstood requirement that survived into production. A design assumption nobody surfaced until integration test. A validation rule skipped in a sprint that took three weeks to undo six months later. The pain of the right side of that curve is exactly what makes the left side feel cheap.

So when AI-assisted development came along, I didn't have to invent the instinct to catch drift early. I just had to refuse to unlearn it.

The framework instinct

The governance framework I've been building around SQUEIL — the CODEX, the GOV records, the canon drift checks, the Arbiter compliance gates — exists for exactly this reason. Not because I distrust AI. Because I know AI will drift, and I want the drift caught in the same loop, not three sprints later when a phantom migration file is the reason production won't deploy.

The test isn't "does your AI get it right most of the time?" Of course it does. The test is: when your AI gets it wrong at 11 PM, does your system notice?

That's the thing. Everything else is marketing.

2. Treat your own ventures like you'd treat a client's.

Nested architectural frames on a dark field, stepping inward from cool gray to warm amber, with tick marks and diagonal construction lines

There's a tic enterprise consultants develop. You bill for rigor when the rigor is for someone else. Spec-first, traceability matrix, acceptance criteria, sign-off oracle, documented decisions. The works.

Then you go home and build your own company with TODO comments and a Notion doc nobody updates.

I did that for years. Most founders do. Your own ventures become the place you cut corners because nobody's paying you to be rigorous, so rigor feels like overhead.

The shift that actually changed how I operate on SQUEIL and OTHS was simple, and it took me a long time to see: the rigor is the asset.

The moment it clicked

When drift showed up in that session — a missing migration, a stale index, a phantom Supabase ref, hidden staged files — my instinct was to expand the scope of what I was fixing, not contract it. That instinct is not natural. Every other signal in the moment says to cut, close the ticket, go to bed.

The only reason I had the instinct at all is because I'd decided, earlier and in writing, that the cost of closing the gap now was much lower than the cost of discovering it at scale.

That's the curve again. Left side or right side. Pay a little now or a lot later.

A consultant optimizes for the engagement. A founder optimizes for the system that outlasts the engagement. That's a founder decision, not a consultant decision — and it's the one I spent a decade of BA work learning to make reflexively.

The second lesson, then: if you're building anything you want to survive your own attention, start treating your own ventures with the kind of care you'd reserve for a client paying you $400 an hour. Not because the work deserves more ceremony. Because the work deserves the version of you that wouldn't let things slide.

The close

The session ended the way a good session ends — not with everything perfect, but with the system in a more rigorous state than when we started. The drift was caught. The governance records were updated. The specific AI failures were logged and addressed, not glossed over. The commit attribution was corrected.

None of that happened because the AI was flawless. It happened because the framework caught the places the AI fell short, and because I'd built a habit — over a decade and many rightmost-column battle scars — of holding my own ventures to the standard I'd enforce on any paying client.

If you're building with AI right now, those are the two muscles worth training. Build a system that catches drift. Hold your own work to the standard you'd hold someone else's.

The rest, as they say, is execution.