Why One-Shotting Apps with Claude Code Fails (And How to Actually Build Software)
Problem
I sat down with Claude Code, described my app idea in detail, and typed “implement everything.” Four hours later, I had a mess of broken code, conflicting assumptions, and a half-working prototype that would need to be scrapped entirely.
I assumed I was doing something wrong with my prompts. Maybe I wasn’t being specific enough? Maybe I needed to provide more context?
Then I found a Reddit thread where experienced developers shared the same frustration. The consensus was clear: “You can’t one-shot an app or software not even with CC or Opus on max level effort.”
This isn’t a skill issue. It’s a fundamental misunderstanding of how AI-assisted development works.
Why One-Shot Fails
The core problem is assumption cascade. When you say “implement everything,” you’re asking the AI to make hundreds of decisions without your input. Each decision builds on previous decisions. One wrong assumption at step 3 compounds into a completely broken system by step 50.
Step 1: Choose database → Assumption: PostgreSQLStep 2: Choose ORM → Assumption: SQLAlchemy (works with PostgreSQL)Step 3: Define schema → Assumption: User table has email columnStep 4: Build auth → Assumption: Email-based loginStep 5: Build API → Assumption: REST endpoints for user CRUD...Step 50: Everything is broken because Step 3 assumption was wrong (Users actually need phone-based auth)By the time you realize Step 3 was wrong, Steps 4 through 49 are built on top of it.
Context Dilution
Each feature you add dilutes the context. Claude has a limited context window. When you try to implement an entire app in one go, the early decisions get compressed, summarized, or lost entirely.
Request: "Build a task management app with users, projects, tasks, subtasks, comments, attachments, notifications, search..."
Token 1-10K: [Detailed understanding of requirements]Token 10K-50K: [Reasonable implementation of core features]Token 50K-100K: [Compressed context, missing edge cases]Token 100K+: [Operating on summaries of summaries]The model stops reasoning about the original requirements and starts reasoning about its own compressed understanding of them.
Integration Complexity
Features don’t exist in isolation. When you build feature A, then feature B, then feature C separately, you discover integration problems late:
One-Shot Approach: Day 1: Build all features Day 2: Discover A and B conflict Day 2: Discover B and C conflict Day 2: Discover A conflicts with the fix for B-C conflict Day 3: Scrap and start over
Iterative Approach: Day 1: Build feature A, test it Day 2: Build feature B, test B, test A+B integration Day 3: Build feature C, test C, test A+C, test B+C Day 4: Feature complete with known integrationsHidden Dependencies
Real software has dependencies you don’t know about until you hit them. One-shotting assumes you can predict all dependencies upfront, which is impossible even for experienced architects.
Testing Gaps
When you implement everything at once, you test nothing until everything is “done.” This means:
- Bugs compound on top of bugs
- Debugging requires untangling layers of interdependent code
- You can’t tell which layer has the problem
The Solution: Iterative AI-Assisted Development
The Reddit thread was clear: “You have to iterate tens, hundreds, thousands of times before the app becomes remotely useful or good.”
Here’s a practical framework for iterative development with Claude Code:
Phase 1: Foundation (Day 1-2)
[ ] Project structure created[ ] Database schema defined (minimal, extensible)[ ] Single model working (e.g., User)[ ] Basic CRUD for that model[ ] Tests passing[ ] Can run locally with one commandStop here. Ship this. Test it. Use it. Find problems.
Phase 2: Core Features (Day 3-7)
Add one feature at a time:
1. Write the feature requirement in plain English2. Ask Claude to design the schema changes3. Review and approve changes4. Implement the change5. Write tests6. Run tests7. Manually test the feature8. Fix any issues9. Commit10. Move to next featureEach feature is a complete loop. You never move to the next feature until the current one works.
Phase 3: Polish (Day 8-14)
[ ] Error handling[ ] Loading states[ ] Empty states[ ] Validation messages[ ] Edge case handling[ ] Performance optimization[ ] AccessibilityThese are done iteratively, one at a time, with testing between each.
Phase 4: Production Ready (Day 15+)
[ ] Environment configuration[ ] Database migrations[ ] Deployment scripts[ ] Monitoring and logging[ ] Security review[ ] Performance testing[ ] DocumentationWrong Approach vs Right Approach
ONE-SHOT APPROACH ITERATIVE APPROACH────────────────────────────────────────────────────────────────────"Build a task app with..." "Create a project structure for a task management app" │ │ ▼ ▼[4 hours of code generation] [10 min] Basic structure │ │ ▼ ▼[500+ files, 50K+ lines] [Test it works] │ │ ▼ ▼[Try to run it] [Add User model] │ │ ▼ ▼[20 errors] [Test User CRUD works] │ │ ▼ ▼[Fix error 1, breaks error 2] [Add Project model] │ │ ▼ ▼[Fix error 2, breaks error 1] [Test Project CRUD works] │ │ ▼ ▼[Realize architecture is wrong] [Test User + Project integration] │ │ ▼ ▼[Start over] [Continue adding features...] │ │ ▼ ▼Total: 2 days, nothing working Total: 2 days, working MVPCommon Mistakes
| Mistake | Why It Fails | Fix |
|---|---|---|
| ”Implement the full app” | Too many assumptions cascade | Implement one feature, test, repeat |
| ”Add authentication and authorization” | Hidden dependencies emerge | Add auth first, test, then add authorization |
| ”Build the API for all models” | Context dilution | Build one endpoint, test, build next |
| ”Set up the complete database schema” | Premature optimization | Start minimal, extend as needed |
| ”Write all the tests at the end” | Bugs compound on bugs | Write tests immediately after each feature |
| ”I’ll refactor later” | Technical debt compounds | Refactor after each feature works |
Why This Matters
The Reddit discussion revealed an important truth: even experienced AI users don’t one-shot apps. The developers who succeed with Claude Code treat it as a pair programming partner, not a code generator.
Developer: "Create a User model with email and password"Claude: [Creates model]Developer: [Tests it]Developer: "Add a method to check password validity"Claude: [Adds method]Developer: [Tests it]Developer: "Now add Project model that belongs to User"Claude: [Adds Project with association]Developer: [Tests association works]...This pattern—small request, implementation, verification, next request—is how actual software gets built. One-shotting isn’t just difficult; it’s the wrong mental model for AI-assisted development.
The AI isn’t an architect who can hold an entire system in its head. It’s a fast, capable junior developer who needs constant direction and verification. Treat it that way, and you’ll build working software. Treat it like a genie, and you’ll get a pile of broken code.
Final Words + More Resources
My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me
Here are also the most important links from this article along with some further resources that will help you in this scope:
Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!
Comments