The first thing the QA agent found was a P0 bug I'd have shipped to users.
The natal chart was computing before authentication. The 401 came back silently. The reveal screen showed a mock chart instead of the real one, no error, no indication anything was wrong. TypeScript didn't catch it. Unit tests didn't catch it. A QA subagent actually rendering the app caught it in about 90 seconds.
That's the case for agentic development in one bug.
This is the story of building Origo, an AI astrology and tarot companion app, under Raedus Labs. The AI companion is named Vega. The stack is Expo SDK 56, Supabase edge functions, and RevenueCat. The build used Claude Code subagents and dynamic workflows throughout. Here's what worked, what failed, and the specific patterns worth stealing.
Research Before Any Code
Before writing a line of implementation code, I ran a 6-agent fan-out research workflow. Six subagents ran in parallel, each focused on a distinct research question: competitor landscape, monetization patterns, retention mechanics, technical stack validation, content depth requirements, and user persona signals.
The synthesis agent read all six outputs and produced a build-ready PRD.
The whole thing ran in the background. No context bloat in the main session. By the time I sat down to write code, the product decisions were already made and grounded in evidence, not guesswork.
That's the first pattern: research is a fan-out problem. One agent doing sequential research is slow and shallow. Six agents running in parallel, each going deep on one question, and then a synthesis pass is faster and produces better signal.
Six Screens Built in Parallel
Once the foundation was laid, I dispatched six subagents to build the feature screens. Each one got its own git worktree and its own branch.
# Set up isolated worktree for each screen
for screen in onboarding chart-reveal daily-reading tarot-draw chat settings; do
git worktree add ".claude/worktrees/$screen" -b "build/$screen" origin/main
done
# Each subagent runs in its worktree cwd.
# Gate before merging back to main:
tsc --noEmit && npm test && npx expo export --platform web
# Clean up after a successful merge
git worktree remove ".claude/worktrees/onboarding"
The gate before merging anything back to main: tsc --noEmit had to pass, tests had to pass, the screen had to render without crashing. Each merge was sequential. Worktrees are isolated, but integration issues surface at merge time, so I didn't parallelize the merges themselves.
This is the second pattern: parallelism for creation, sequentialism for integration. Six agents building simultaneously is fine. Merging them back without checking integration is how you get cascading conflicts.
The content data got the same treatment. A fan-out workflow generated the 78-card tarot dataset with 5 parallel writer agents, each covering a subset, then a merge pass for consistency.
Model Routing as Cost Arbitrage
Not every task deserves Opus tokens. I routed by task type:
- Opus: architecture decisions, security-critical Supabase edge function logic
- Sonnet: mechanical screen builds, routing logic, data formatting
- Codex (on OpenAI tokens, a completely separate budget): grunt work, boilerplate, package installs, simple fixes
The Opus vs Sonnet distinction matters most on security-sensitive backend code. The edge functions that handle Vega's responses use a code-enforced safety filter. Getting that architecture right was worth the Opus call. Scaffolding a settings screen was not.
Running Codex on OpenAI tokens for mechanical work is genuine cost arbitrage. It's a junior developer on a different budget doing the boring parts.
Verification Was the Unlock
TypeScript and unit tests give you a certain class of guarantees. They tell you the types are consistent and the pure functions behave correctly. They don't tell you the user flow works end to end.
The QA agent rendered the actual app and walked through the actual onboarding flow. That's how it caught the natal chart bug.
The fix was straightforward once we knew it: anonymous Supabase auth at the cold open, then linkEmail on signup so the real chart persists through the auth transition. Commit 31fdf4e. But we wouldn't have known to write it without the agent that actually pressed the buttons.
Real bugs caught by verification that tests missed:
- The P0 onboarding flow (natal chart computed before auth, silent 401, mock chart shown)
- Client/server contract drift between the edge function response shape and the client's expected type (fixed with a single tsc-enforced shared contracts file)
The rule: a subagent saying "tsc clean, tests pass" is a claim. Re-run the gate yourself before believing it.
Three Operational Failures Worth Knowing
These are the things I'd tell someone before they run their first multi-agent build.
Orphaned worktrees polluted the jest run. After the screen-build workflow completed, the .claude/worktrees/ directory had leftover branches. Jest scanned them. It found duplicate test trees. The result was about 8 "suite failed to run" errors and a 579-second runtime. Fix: add .claude/ to jest testPathIgnorePatterns and modulePathIgnorePatterns. Clean run after: 255 tests, roughly 70 seconds.
// jest.config.js
{
"testPathIgnorePatterns": ["/node_modules/", "/.claude/"],
"modulePathIgnorePatterns": ["/node_modules/", "/.claude/"]
}
Never run the test gate while the local stack is up. Supabase containers, functions serve, and expo start --web running concurrently with jest creates memory pressure that SIGTERM-kills jest workers. You get ~10 false suite failures. An incremental tsc run can also produce spurious type errors under the same conditions. Kill the dev servers before running the gate. No exceptions.
Surviving a mid-build session death. The screen-build workflow got interrupted partway through. Recovery worked because state lived on disk: continuity notes, git history, committed worktrees. One worktree had committed its work. That was salvageable. Five had partially-written files and no commits. Those were cleaned and re-dispatched. The lesson: commit early and often from worktrees, even if the work is incomplete. Partial commits are recoverable. Uncommitted work in an orphaned worktree is not.
What's Shipping
Origo is a Raedus Labs app. Vega runs on server-side Supabase edge functions with a chart-aware context system and a code-enforced safety filter. RevenueCat handles subscriptions. The agentic build approach took it from zero to a complete, testable app across a handful of focused sessions.
If you're evaluating whether Claude Code subagents + dynamic workflows are worth the operational overhead: they are, but the gains are in the verification layer, not the generation layer. Generating code fast is table stakes. Catching the P0 before your first user hits it is where agentic development actually earns its keep.
The QA agent that found the natal chart bug cost less than a coffee. The alternative was shipping a mock chart to real users and wondering why retention was broken.
Origo isn't in public beta yet. I'm posting build logs as it ships at raeduslabs.com and on Dev.to. If you're building with agentic workflows and hit something interesting, reply here. Always curious what class of failures I haven't found yet.
Top comments (0)