With Claude Code, you can plan an entire project - architecture, tasks, dependencies - and get a precise implementation plan. But once the plan is written, how do youexecute it? That's the question I asked myself while building FamilySound.
The context: FamilySound
FamilySound is an iOS app that lets parents send sounds to their children's phones via push notification. You press a button, your child's phone plays a sound at maximum volume - even if it's on silent. It's a digital "come eat."
The app was already ~95% functional: parent/child authentication, sound recording, Firebase storage, local playback. But there were still 20 tasks spread across 5 phases to reach a product publishable on the App Store:
- Phase 1 - Critical fixes - Notification permissions, reliable FCM synchronization, fixing a race condition in the sign-up flow, deploying the Cloud Function
- Phase 2 - Robustness - Retry logic, Firestore query optimization (N+1), hardening security rules, audio session management
- Phase 3 - Co-parent role - New role between parent and child, sign-up flow via email + invite code, specific permissions, backend update
- Phase 4 - Tests - Protocols for services, unit tests for models, mocks, ViewModel tests
- Phase 5 - Polish - Crashlytics, analytics, network monitoring, TestFlight preparation
20 tasks, interdependent files, no existing test suite. The question was no longer what to do, but how to get the AI to execute it without driving it into a wall.
The execution problem
When working with Claude Code on a project of this size, the plan is the easy part. The AI analyzes the code, identifies the gaps, proposes a logical sequence. But execution is another matter.
Two main risks:
- The cascade effect - An error in task 1 propagates into task 2, which propagates it into task 3. After 5 tasks, the code is in an inconsistent state that's hard to untangle.
- Silent drift - The AI misinterprets a task, produces code that "works" but doesn't match what was wanted. Without a checkpoint, you only notice at the end.
I identified two possible approaches.
Approach A: Subagent-Driven
Principle
You stay in the same Claude Code conversation. For each task, you launch a specialized agent (subagent). Between each task, you check in: I review the code, validate or fix it, then move to the next.
- Review between each task - nothing passes without human validation
- Real-time correction - if it goes off track, adjust immediately
- Intermediate commit - each validated task = a Git restore point
- Zero runaway - the AI never heads in the wrong direction without agreement
The main drawback: it's sequential and interactive. The user must be present to validate each step. And each agent starts fresh without the context of previous ones - prompts need to be written carefully to compensate.
Approach B: Parallel Session
Principle
You open a new Claude Code session in the same directory. The agent reads the implementation plan and executes tasks in batches - phase by phase - with checkpoints at the end of each phase.
- Continuous execution - the agent proceeds without waiting for intermediate validation
- Fresh context - the written plan is the source of truth, not the conversation history
- Parallelizable - independent tasks (e.g. Phase 2) can run in parallel
- Free session - while the agent works, you can do something else
The drawback: less control. Errors accumulate before being noticed. If a task is misinterpreted, the following ones inherit the problem. And the agent can't ask questions along the way.
Direct comparison
| Criterion | Subagent-Driven | Parallel Session |
|---|---|---|
| Control | Total (validation per task) | Partial (review per phase) |
| Speed | Slower (waiting on human) | Faster (continuous execution) |
| Drift risk | Low | Moderate to high |
| Presence required | Continuous | Per phase only |
| Safety net | Commits + human review | Written plan + tests (if any) |
| Best suited for | Interdependent files | Independent tasks + tests |
The choice for FamilySound
1. The files are interdependent
Tasks 1 to 3 of Phase 1 all touch the same files: AppDelegate, AuthService, FamilySoundApp. If task 1 (notification permissions) modifies AppDelegate and task 2 (FCM synchronization) also modifies it, an error in the first instantly propagates into the second.
With intermediate review, the problem is caught before it contaminates the rest.
2. Phase 3 is complex
Adding a "co-parent" role means modifying the Swift models, the authentication services, the SwiftUI views, the Firestore rules and the Cloud Function - all at once. That's 5 tasks touching both frontend and backend. Letting the AI do this without a checkpoint risks discovering a tangle of problems at the end of the phase.
3. No safety net
The project had neither a test suite nor a clean Git history. No tests = no automatic regression detection. No Git = no easy rollback. Each intermediate commit (one per validated task) manually creates the safety net that didn't exist.
When to choose the other approach?
Parallel Session isn't inferior - it's suited to different contexts:
- Existing test suite - regressions are detected automatically, no need for human review at every task
- Clean Git history - easy rollback if something goes off track
- Independent tasks - when tasks don't touch the same files, parallelization is a real win
- Limited time - if you can't stay present to validate each step, better to let the AI proceed and review afterward
What I take away from this
- The plan isn't enough. A 20-task implementation plan, however well structured, guarantees nothing if the execution method isn't well thought out. "How do we execute" matters as much as "what do we execute."
- The AI needs guardrails. Not because it codes badly - it often codes better than I do. But because without a checkpoint, a bad interpretation turns into invisible technical debt.
- The intermediate commit is your best tool. Every validated, committed task is a restore point. It's the simplest and most reliable safety net.
- Adapt the method to the project, not the other way around. FamilySound needed strict control. A project with good test coverage would have benefited from the Parallel Session. There's no universal answer.