← All writing

Build log

How fast should an AI workspace startup check be? Mine was 13x too slow

Aug 14, 2026

My workspace verifier's 'fast' path quietly grew past a minute at session start, so nobody ran it. Bounding it to entry-critical invariants got it to 4.61 seconds, and back into every session.

A startup check that takes more than a minute is a startup check nobody runs. Mine did. I bounded it to entry-critical invariants, and now it takes 4.61 seconds.

The claim I'll defend: a slow safety check is worse than no check, because it trains you to skip it while letting you believe you're still covered. My running example is the workspace verifier — the shell script my AI workspace runs at session start and on every push, before any agent session touches a file. Its whole job is one question: is this workspace safe to enter?

Why did a "fast" check take over a minute?

Accretion. The verifier had a tier literally named fast, and every diagnostic that ever felt useful got added to it. The heaviest were recursive scans — checks that walk every folder and file under the workspace root, like harvesting inline TODO markers out of every document in the tree. Each addition was defensible on its own. Each produced real signal. The sum crossed sixty seconds.

And session start is the one moment you cannot charge a minute. Patience is lowest, and the urge to start the actual work is strongest. So the predictable thing happened: I began skipping my own check. That was a design failure, and it was mine. A check that exists but doesn't run is worse than absent: it still appears in the architecture story, still earns credit for coverage, and catches nothing.

More than a minute against 4.61 seconds is the 13x in the title. That ratio is a floor, since "more than a minute" is the minimum, not the day's exact reading.

What actually belongs in a startup check?

Entry-critical invariants only — the facts that must be true before any work is safe to start. The bounded --startup route checks exactly that shortlist. Is the task board present and well-formed? Are the status, root, and meta markers where they should be? Are there live locks or stop flags? (A stop flag is a plain file a human leaves behind that means "halt here, on purpose.")

Nothing recursive. And the deferred work is declared, not hidden: the bounded tiers print the inline-TODO inventory as deferred, naming the deeper tier that owns it, instead of pretending to have looked. That line matters more than it seems. A bounded check that names what it skipped is honest about its coverage. A broad check that silently runs long is lying about it.

Two more properties earn their place. The route is read-only by default (writing its own history log is opt-in behind a separate flag), so the entry check can't modify the workspace it's judging. And it came back in 4.61 seconds on the 2026-07-24 baseline, which sits under the threshold where skipping ever feels rational.

Where did the deep scans go?

Into their own lane, not into the trash. The heavy stages (structure, cross-domain consistency, content integrity) run in the full and brief tiers, as targeted or release checks rather than at every session entry. That lane runs under a controller enforcing a deadline per stage plus one global deadline, so it can't quietly repeat the original sin. Unbounded growth now hits a timeout, and a timeout is a loud failure instead of a slow check.

The verifier also keeps exit codes strict: clean, finding, and invoked-wrong are three different numbers, so automation can tell "the workspace is broken" from "the check is broken." And it ships a self-test mode that runs its own parser and stage-selection logic against fixtures. A check you can't check is a vibe with an exit code.

How do you stop the fast path from growing again?

Treat the speed of a check as a feature of the check: specified, budgeted, and tested like any other behavior. The failure here was never a wrong answer. It was a right answer that arrived too late to be asked for — latency rot, which is a regression (something that used to work getting worse) even though no assertion ever failed.

Most agent setups I've seen fail in the same direction: one ever-growing check script, run weekly at best, giving coverage on paper and nothing at the moment of entry. The fix isn't choosing between fast and thorough. It's refusing to let one flag mean both: a bounded entry lane that always runs, and a deep lane with deadlines that runs on purpose. This verifier is one slice of a larger system for making an AI assistant show its work; the full tour is in how do I know AI is right.

So the question back at you: which check in your setup has drifted from "every session" to "when someone remembers"? Time it today. If it's over a minute, which five seconds of it would you keep?

I'm Ali — I run real life-and-work admin on AI agents, then check their work in the open. More at /about.

Published under my standards. Found an error? Tell me — corrections go in the corrections log, dated, never silent.

@online{ali2026startupcheck,
  author = {Ali},
  title  = {How fast should an AI workspace startup check be? Mine was 13x too slow},
  date   = {2026-08-14},
  url    = {https://alidoes.ai/ai-workspace-startup-check/}
}

Caught something I got wrong? Send it directly. Confirmed corrections go in the corrections log.