Skip to content

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.

One-Shot Assumption Cascade
Step 1: Choose database → Assumption: PostgreSQL
Step 2: Choose ORM → Assumption: SQLAlchemy (works with PostgreSQL)
Step 3: Define schema → Assumption: User table has email column
Step 4: Build auth → Assumption: Email-based login
Step 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.

Context Window Degradation
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:

Integration Discovery Timeline
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 integrations

Hidden 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)

Foundation Checklist
[ ] 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 command

Stop here. Ship this. Test it. Use it. Find problems.

Phase 2: Core Features (Day 3-7)

Add one feature at a time:

Feature Addition Workflow
1. Write the feature requirement in plain English
2. Ask Claude to design the schema changes
3. Review and approve changes
4. Implement the change
5. Write tests
6. Run tests
7. Manually test the feature
8. Fix any issues
9. Commit
10. Move to next feature

Each feature is a complete loop. You never move to the next feature until the current one works.

Phase 3: Polish (Day 8-14)

Polish Tasks
[ ] Error handling
[ ] Loading states
[ ] Empty states
[ ] Validation messages
[ ] Edge case handling
[ ] Performance optimization
[ ] Accessibility

These are done iteratively, one at a time, with testing between each.

Phase 4: Production Ready (Day 15+)

Production Checklist
[ ] Environment configuration
[ ] Database migrations
[ ] Deployment scripts
[ ] Monitoring and logging
[ ] Security review
[ ] Performance testing
[ ] Documentation

Wrong Approach vs Right Approach

Comparison: One-Shot vs Iterative
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 MVP

Common Mistakes

MistakeWhy It FailsFix
”Implement the full app”Too many assumptions cascadeImplement one feature, test, repeat
”Add authentication and authorization”Hidden dependencies emergeAdd auth first, test, then add authorization
”Build the API for all models”Context dilutionBuild one endpoint, test, build next
”Set up the complete database schema”Premature optimizationStart minimal, extend as needed
”Write all the tests at the end”Bugs compound on bugsWrite tests immediately after each feature
”I’ll refactor later”Technical debt compoundsRefactor 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.

Successful AI Development Pattern
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