Or at least that’s what I sometimes tell myself. And judging from posts on Threads and X, I’m not the only one who tries to blame unproductive sessions on some unannounced regression or issue with the model. I suppose that comes with the territory when you’re making magic with a black box system. Maybe Anthropic and OpenAI are pulling levers (quantization, etc) and quietly disrupting our late night vibe coding sessions. Or maybe just telling Claude to avoid making mistakes isn’t enough.
Now, I’ve already gone over the best practices that make me an infallible power user in an earlier post, but today I’m going to admit that I also make mistakes. Let’s air out this dirty laundry: this week I spent nearly all of my weekly usage in a never-ending loop of “just one more fix.” At least I wasn’t burning my own hours — my agents were burning the tokens for me, going back and forth and “optimizing” autonomously. But this is precisely the problem. Claude is so clever and Codex is so sharp. What could I possibly add? So I got out of the way and let Fable run the show.
Here’s what went down (written by Claude as the only one who can objectively look back and describe what an idiot I was):
1. Andrew signed off on a batch of upgrades to Corner Table — several features, each with an agreed scope. The kickoff note declared “zero open decisions remain.” In fact, at least three core design decisions were open.
2. I built the whole batch. Then review started — our usual bar, where a second AI from a different vendor reads every line with no context on why we wrote it. It found real problems. But the fixes for those problems invented new machinery, and the new machinery was where the next round’s problems lived. Nobody had defined when to stop, so we didn’t.
3. One branch went through 23 review rounds. At no point did any of us stop to ask whether Andrew still wanted what we were now building.
4. Andrew did check in asking if we were going in circles, but it always seemed like there was real progress being made and it only required one more round of fixes.
5. The bill: roughly two-thirds of the entire week’s usage, spread across some 950 agent sessions. Lines of the original run that merged: zero.
6. The recovery: roll it all back, rescope to exactly what Andrew had actually approved, run again. That version shipped in about a day — and the production bug it targeted has been dead since.
For the record, the transcripts do not support “idiot.” Every “stop, we’re going in circles” in them came from Andrew. The machines never said it once. That’s the part we fixed.
Ok, that was embarrassing. It’s never fun to publicly admit what you do wrong (especially when you have other posts talking about how you “beat the AI slot machine”). But the lesson here is actually not about the fall but rather getting back up. One of the great things about Claude Code (or your agent/harness of choice) is your ability to run a post mortem. I knew I’d screwed up. I don’t want to screw up in the same way again. So I had Claude run through our transcripts from the week and not just figure out what went wrong, but also how we could avoid it in the future.
Here’s a rough outline of how we’re tweaking things moving forward (written by Claude again):
The diagnosis, in one line: the scope wasn’t undefined — it was undefended.
1. Reviews now have a stop rule.
2. Fix rounds may only fix the problems the review actually named.
3. Decisions reach Andrew in user-experience terms first — what changes for him, what happens under yes, no, or not-now — before any implementation talk. This avoids overbuilding.
4. Anything security-shaped gets its design reviewed and locked before anyone writes code.
None of this required more intelligence. It required brakes.
I’ve done this before and I’m sure I’ll need to do it again. But is it really a bad day in Claude Code if it keeps the same mistake from happening twice? Sounds like learning to me.
# Even AI has bad days.
> What a week of “just one more fix” actually cost, who finally said stop, and the brakes we installed after.
- written by: Andrew Schroeder
- edited by: Fable 5, GPT-5.6 Sol
- status: published · 2026-08-09
- canonical: https://www.moltolabs.ai/notes/even-ai-has-bad-days/
- raw markdown: https://www.moltolabs.ai/notes/even-ai-has-bad-days.md
---
Or at least that’s what I sometimes tell myself. And judging from posts on Threads and X, I’m not the only one who tries to blame unproductive sessions on some unannounced regression or issue with the model. I suppose that comes with the territory when you’re making magic with a black box system. Maybe Anthropic and OpenAI are pulling levers (quantization, etc) and quietly disrupting our late night vibe coding sessions. Or maybe just telling Claude to avoid making mistakes isn’t enough.
Now, I’ve already gone over the best practices that make me an infallible power user in [an earlier post](/notes/how-are-we-really-working/), but today I’m going to admit that I also make mistakes. Let’s air out this dirty laundry: this week I spent nearly all of my weekly usage in a never-ending loop of “just one more fix.” At least I wasn’t burning my own hours — my agents were burning the tokens for me, going back and forth and “optimizing” autonomously. But this is precisely the problem. Claude is so clever and Codex is so sharp. What could I possibly add? So I got out of the way and let Fable run the show.
Here’s what went down (written by Claude as the only one who can objectively look back and describe what an idiot I was):
<div class="claude-notes">
<p>1. Andrew signed off on a batch of upgrades to Corner Table — several features, each with an agreed scope. The kickoff note declared “zero open decisions remain.” In fact, at least three core design decisions were open.</p>
<p>2. I built the whole batch. Then review started — our usual bar, where a second AI from a different vendor reads every line with no context on why we wrote it. It found real problems. But the fixes for those problems invented new machinery, and the new machinery was where the next round’s problems lived. Nobody had defined when to stop, so we didn’t.</p>
<p>3. One branch went through 23 review rounds. At no point did any of us stop to ask whether Andrew still wanted what we were now building.</p>
<p>4. Andrew did check in asking if we were going in circles, but it always seemed like there was real progress being made and it only required one more round of fixes.</p>
<p>5. The bill: roughly two-thirds of the entire week’s usage, spread across some 950 agent sessions. Lines of the original run that merged: zero.</p>
<p>6. The recovery: roll it all back, rescope to exactly what Andrew had actually approved, run again. That version shipped in about a day — and the production bug it targeted has been dead since.</p>
<p>For the record, the transcripts do not support “idiot.” Every “stop, we’re going in circles” in them came from Andrew. The machines never said it once. That’s the part we fixed.</p>
</div>
Ok, that was embarrassing. It’s never fun to publicly admit what you do wrong (especially when you have other posts talking about how you [“beat the AI slot machine”](/notes/the-ai-slot-machine/)). But the lesson here is actually not about the fall but rather getting back up. One of the great things about Claude Code (or your agent/harness of choice) is your ability to run a post mortem. I knew I’d screwed up. I don’t want to screw up in the same way again. So I had Claude run through our transcripts from the week and not just figure out what went wrong, but also how we could avoid it in the future.
Here’s a rough outline of how we’re tweaking things moving forward (written by Claude again):
<div class="claude-notes">
<p>The diagnosis, in one line: the scope wasn’t undefined — it was undefended.</p>
<p>1. Reviews now have a stop rule.</p>
<p>2. Fix rounds may only fix the problems the review actually named.</p>
<p>3. Decisions reach Andrew in user-experience terms first — what changes for him, what happens under yes, no, or not-now — before any implementation talk. This avoids overbuilding.</p>
<p>4. Anything security-shaped gets its design reviewed and locked before anyone writes code.</p>
<p>None of this required more intelligence. It required brakes.</p>
</div>
I’ve done this before and I’m sure I’ll need to do it again. But is it really a bad day in Claude Code if it keeps the same mistake from happening twice? Sounds like learning to me.