One field was missing. Not a crash, not a 404, not an error message of any kind. Just a metadata field that wasn't there, which meant a presentation I'd built wasn't showing up in its own library. The build had passed. The page loaded fine. The deck existed. The system simply didn't know it.
That one missing field sent me into an audit I hadn't planned on running. I went through 58 talks in a single morning, checking everything systematically for the first time. What I found was uncomfortable: 31 wrong slide counts, 26 missing redirect entries that had been silently 404-ing, 7 broken file paths pointing at images that didn't exist. Sixty-four separate issues across a library I'd have told you was in good shape.
Not one of them had announced itself.
This is the new failure mode
The old "move fast and break things" thesis assumed visible breakage. High error rate, high visibility, rapid iteration. Crash early, learn fast. The assumption was that speed produces obvious problems, and obvious problems get fixed.
That's not what happens when you're building with AI at pace. The errors don't crash things. They accumulate. A wrong number in a field, a path pointing at nothing, a counter that's been off for weeks. The product looks fine. The build passes. The page loads. And underneath, the library drifts away from what you thought it was.
The faster you ship, the wider the gap between your intentions and your outputs. But unlike the mistakes that announce themselves, these ones are patient. They sit there until someone decides to actually look.
Why checklists don't solve this
The instinctive response to a quality problem is process discipline. Add a step to the workflow. Write it down. Put it in the documentation. Make sure everyone knows.
I had done exactly this. There was a note in my build instructions: remember to add the thumb field. Seven decks had the wrong thumb path anyway.
A checklist you sometimes forget to follow is not a quality system. It is a quality wish. And the conditions under which checklists fail are precisely the conditions that AI-speed production creates: flow state, high output, multiple projects running in parallel, a hundred small decisions being made at once. Human memory is unreliable by design. Asking it to be the last line of defence against invisible drift is optimism dressed as process.
Every checklist item is a bet on consistent attention under pressure. That bet loses. Not occasionally. Systematically. The audit found things I had no idea were wrong, not because I was careless, but because the system gave me no signal that anything was off.
The actual answer
An audit fixes the past. A validator prevents the future.
I spent about twenty minutes writing a CI validator. It now runs on every push to the repository. It checks that every deck has a thumbnail. That every thumbnail file actually exists on disk. That every slug has a matching redirect entry. That every slide count in the metadata matches the actual HTML. It doesn't care how good the talk was, how fast I was moving, or whether I remembered the checklist. It simply refuses to pass without the right answer.
This is a different relationship with quality. Not being more careful. Not trying harder to remember. Building a system where carelessness is structurally impossible.
Engineers have known this for decades: CI pipelines, schemas, required fields that block without explanation. What's new is who it applies to now. When a single person with an AI can ship at the output level of a team, the discipline that used to be handled by that team becomes essential infrastructure for the individual. There's no senior developer to catch the drift. No QA pass at the end of the sprint. It's you, moving fast, and either the machine is checking or nothing is.
The shift that matters
I've been thinking about what actually changed, and it's this: the human role didn't disappear. It shifted.
Before: I was the one doing the checks. Badly, inconsistently, under pressure. After: I'm the one designing the checks. Once, permanently, encoded into the system.
The difference in output quality is dramatic. But more importantly, the difference in cognitive load is dramatic. I'm not spending mental energy remembering the checklist. I'm spending it on the thing that actually requires judgment: what to build, what to say, what argument is worth making.
What this looks like in practice
The question that triggered all of this wasn't "what did I miss?" It was "what's broken but not showing? What's fragile? What could be more reliable?"
Those are different questions. The first is retrospective and specific. The second is structural and forward-looking. The second is the one that finds the 64 issues, generates the validator, and makes every future build cleaner without you having to think about it.
I ask this question now at the end of every significant build. Not "is it done?" but "what would the audit find?" The gap between those two questions is where invisible debt lives.
The people who figure this out won't just ship fast. They'll ship fast and the library will stay clean across months of production, without a human manually checking everything on a Friday. That's the actual advantage that AI-speed building makes available, and it requires building the rails first.
Move fast. Build the rails. Then move faster.
The companion deck for this post is at mikelitman.me/movingfast — 20 slides, same argument, with the actual audit numbers.
