My Cloud Workflow: Claude Code + Parallel Agents

2026-02-20·3 min read

I shipped 8 features for Better Muslim in about 30 minutes last week. Not 8 small tweaks. Real features across different parts of the app. Here's how.

The setup

I run Claude Code in the terminal. No IDE. Just the CLI, a split terminal, and the codebase. The key insight is that Claude Code sessions are independent. Each one gets its own context window, its own file access, its own ability to read, write, and run code.

So instead of working on one thing at a time, I open 5+ terminal tabs and give each one a different task.

Writing the prompts

This is the part that matters. Each terminal starts fresh. It doesn't know what the others are doing. It doesn't know your codebase conventions unless you tell it. So the prompts need to be self-contained.

For each workstream I write a prompt that includes:

Which files to read first to understand the existing patterns
The exact feature spec, not vague, specific
Theme and font rules (Better Muslim uses a specific design system)
The verification command to run when done (npx tsc --noEmit)

A bad prompt is "add a settings page." A good prompt is three paragraphs that explain where the navigation lives, what the settings should include, what the existing screen pattern looks like, and how to verify it compiles.

The upfront investment in prompt quality pays for itself immediately. A well-specified prompt almost always one-shots. A vague prompt burns rounds going back and forth.

What works in parallel

Not everything can run in parallel. If two agents are editing the same file, you get merge conflicts and wasted work. The trick is finding workstreams that touch different parts of the codebase.

Good parallel tasks:

Different screens or components that don't share state
A new utility function and a new screen that will eventually use it
Backend logic and frontend UI when the interface is already defined
Tests for existing code while new features are being built

Bad parallel tasks:

Two features that modify the same component
Refactoring a shared module while someone else is adding to it
Anything where the output of one task is the input of another

The inner team pattern

Some of those terminals can run their own internal teams. Claude Code can spawn teammate agents that work in parallel within a single session. So you might have 5 terminals, and 2 of them are running 2-agent teams internally. That's 7 agents working simultaneously on your codebase.

The constraint is the same: they need to touch different files. Worktrees help here. Each agent gets an isolated copy of the repo so there are no file conflicts. Changes get merged back when they're done.

What I actually shipped

That 30-minute session for Better Muslim included: a new prayer times display, a Qibla compass screen, a favorites system, an updated home screen layout, a settings page, haptic feedback across the app, a splash screen fix, and a calendar component. Eight different workstreams, all running simultaneously.

Not every one was perfect on the first try. A couple needed small fixes after. But the total time from "nothing" to "all features working" was about 30 minutes of wall clock time.

The mental model shift

The traditional approach is serial: think about a feature, implement it, test it, move to the next one. The parallel approach is more like being a project manager for a team of fast engineers. You spend your time upfront writing clear specs, then you let them all run, then you review the results.

The bottleneck moves from "how fast can I implement" to "how clearly can I specify." And it turns out that writing a really clear spec for a feature takes about 2 minutes. Running 8 of them in parallel takes as long as running 1.

This is how I build now. I don't think I could go back.