1,392 Claude prompts later: the real cost of vibe coding a Mac app
Vibe coding a new Mac app with Claude Code took ten days of stolen sessions between real work. One intermittent bug ate an entire weekend. By the time it was fixed, the developer had issued 1,392 individual prompts, 312 of them just to diagnose and squash that single freeze.
That is the number nobody puts in the vibe coding thread. Here is the full account.
️ The Build: Ten Days of Flow
The project was a fully customizable list manager for Mac, built entirely through Claude Code. The first ten days were, by the developer’s own description, glorious. Feature after feature took shape. The early phase of a new app is where vibe coding shines: ideas go in, working code comes out, and the gap between imagination and implementation shrinks to minutes.
That phase does not last.
The Bug That Ended the Rush
On day eleven, scrolling through the first large list triggered the Spinning Beachball of Death. On modern Apple Silicon hardware, a spinning beachball that does not stop means the app is genuinely stuck, not just slow. The app became completely unresponsive.
Two things made this bug particularly brutal. First, it was intermittent. The app hung on one specific list, but only after switching from another specific list. Second, it disappeared on restart, which meant Claude could not observe it directly.
Having a semi-sentient AI coding superhero doesn’t mitigate this sort of problem. The AI can’t fix what it can’t find.
Roughly two-thirds of Saturday went to narrowing down the reproduction conditions. The rest of Saturday and all of Sunday went to identifying the actual cause and shipping a fix.
The Two Constraints That Shaped the Weekend
Claude Code and most agentic AI tools run into two hard limits during extended debugging sessions.
Context fills up
Each session has a context window. As the session runs, that window fills. The developer describes it as a workbench that gets buried under the remains of five previous projects. The workaround is saving memory files so the AI can pick up where it left off after a restart. But those memory files grow with each session, so eventually a fresh session starts with half its context already consumed by the history of the problem.
Usage allocation cuts you off
Plans meter usage by what you consume in a five-hour window and what you consume in a week. Exceed either limit and you wait or upgrade. The developer runs a $100/month Claude Code Max plan, which held reasonably well, though they were cut off once during the debugging weekend. A $20/month ChatGPT Plus plan ran out much faster in comparison.
Why You Still Need to Be the Jockey
The AI writes fast. It does not always write right.
When the developer asked Claude to implement a search algorithm for an app that manages large text blocks, Claude chose to re-read and re-index every document every time the app loaded. It also scrolled through a hundred pages on screen before displaying the line the user searched for. Both approaches were technically functional and practically unusable.
It did not take much to redirect Claude toward index tables and an on-screen frame jump. But it required the developer to recognize the architectural problem first. That recognition comes from engineering experience, not from vibe coding instinct.
Claude also defaults to guessing at bugs rather than reading the actual code. The developer had to consistently instruct it to re-read the source and to set up logging so the AI could analyze what was actually happening at runtime, rather than what it assumed was happening.
The Real Time Split
New features are fast. Bug fixes are not. The developer reports spending most of their time testing and debugging, not prompting new features into existence. Claude Code may be a 10x or even 100x force multiplier for writing code. It does not multiply testing and debugging speed at all. That work proceeds at normal human pace, sometimes slower because you have to reverse-engineer what the AI built before you can debug it.
After all of this, the developer estimates the app is roughly one-third complete. The 1,392 prompt count is the raw evidence of what one-third-done actually looks like on a real project.
What This Means for Operators Building with AI
Vibe coding is a genuine productivity multiplier for people who already understand software architecture, testing, and system design. The AI handles the mechanical labor. The human handles every decision about what the code should actually do and how it should be structured to stay maintainable.
For operators with no development background, the risk is specific: Claude will give you working code for what you asked, not necessarily for what you need. Search algorithms that load the entire dataset on every keystroke are technically correct answers to vague questions. Someone without engineering context will not catch that until the app is slow or broken in production.
- Expect debugging to cost days per stubborn bug, not minutes.
- Budget for context window management: save memory files early and often.
- Instruct the AI to log its actions. Do not let it guess at its own bugs.
- Guide architecture decisions explicitly. The AI defaults to the simplest interpretation of your request, not the most scalable one.
- Test everything yourself. The AI cannot reliably test its own SwiftUI output or anything that requires hands-on interaction.
The ten-day flow state is real. So is the weekend you lose to a single intermittent freeze. Both are part of the same process.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
