Series: Weekend at Claude's — misadventures in building a production app with an AI anyone could mistake for the person who's going to make the whole thing happen
Here's what a 10-minute cycle feels like when you're in enough of them.
Report the error. Claude Code identifies a fix — Firestore security rules, in this case. Apply the fix. Recompile the mobile app APK. Deploy the PWA. Reseed the database. Rebuild the test data. Run the test. Get a Firestore security check failure. Report the error. Repeat.
Each cycle is about ten minutes. The cycles are not short on cognitive load either — there's the recompile, the deploy, the reseed, the mental overhead of keeping track of what changed and what you're actually testing. And at the end of each one: another Firestore security rules failure, slightly different from the last, equally resistant to the fix that should have worked.
I was doing this happily, more or less. Claude Code was engaged. We were making progress, technically — each cycle produced a hypothesis, a fix attempt, a result. Things were happening.
They were just happening very slowly, in a very expensive context.
The Question That Changed Everything
After enough cycles — I won't tell you how many, it's embarrassing — I noticed the common thread. Every failure was a Firestore security rules issue. Every fix was applied in the full app context: recompile, redeploy, reseed, retest. Ten minutes a cycle, minimum.
And I asked myself: why are we doing this here?
The security rules failure wasn't a mobile app problem. It wasn't a PWA problem. It was a query problem — specifically, whether the query the app was making would pass Firestore's security rules. That was it. Everything else — the APK compilation, the PWA deployment, the database reseed — was overhead. It had nothing to do with the actual thing we were trying to fix.
So I asked Claude Code:
"Since this seems to be the most critical blocker with multiple resolves failing, would it be more expedient to write a test query that duplicates what the mobile app page uses, and iterate on that directly until it passes Firestore security rules — then apply the fix back to the codebase?"
Yes. Absolutely yes.
We isolated the query. Stripped out all the app context. Ran the query directly against Firestore security rules, iterated on it until it passed, then propagated the working version back to the mobile app and PWA. The fix that had been resisting ten-minute cycles resolved in a fraction of the time.
What Claude Code Was Doing Right — And What I Needed to Add
Claude Code was solving the problem correctly the entire time. The security rules fixes it was generating were reasonable. The issue wasn't Claude's reasoning. The issue was the context we were working in — a context where every test took ten minutes to execute, because we were fixing a query problem inside a full app deployment loop.
Claude Code will keep solving the bug in the context it was found and explained. If that context has a ten-minute feedback loop, it will work within that ten-minute feedback loop. It won't stop to suggest that you might be able to test the same thing in thirty seconds a different way. That's not its job. That's yours.
Human-to-Claude calibration setting #7: When the cycle time is long, ask whether you're fixing the bug in the right context.
Before the next cycle, ask: what is the actual thing I'm testing? Is there a faster way to test just that thing, without all the surrounding overhead? If the answer is yes — isolate it, fix it there, then propagate.
Report, fix, compile, deploy, reseed, test, repeat. Or: isolate the query, fix it directly, apply it everywhere.
One of these is ten minutes a cycle. The other is thirty seconds.
Aphilaty is a privacy-first community coordination app. aphilaty.com