From Solo Dev to AI Team: Orchestrating Multi-Agent Workflows with Claude Code

A disaster on day 5

Three months before this talk, I took on a challenge: build a backoffice system that would sit at the heart of a trading platform. The team was one person — me — and six AI agents. No developer team, just agents as collaborators.

On day 5 I almost threw it all away. The agents had produced 2,000 lines of wrong code, buried in a 200,000-line codebase. The requirements had only ever lived in my head; what I’d actually handed the agents was a quick, incomplete PRD. It was wrong, and they had faithfully built on top of it. I’ve written up that story in more detail on the blog, in Setting Up Multi-Agent Workflows with Claude Code.

The lesson from that week is the spine of this talk: agents are force multipliers, not mind readers. Front-load the thinking, or you multiply garbage.

One developer, infinite roles

The traditional team structure behind any piece of software is Product Manager, Solution Architect, Software Engineer, Product Owner, QA Engineer, DevOps Engineer. The AI-augmented solo developer swaps that list for one person plus specialised AI agents, aiming for the same team capability.

The question we put to the room is simple: what if you could have a team meeting — with yourself and six AI specialists? An “agent,” in our sense, is an AI instance with a specific role, context and expertise. That’s what separates it from a simple prompt: specialisation, persistence across interactions, and the ability to collaborate with other agents. Claude Code is the orchestration platform that makes this practical.

The problem it solves

Solo development has three structural problems that agents alone don’t fix by being clever: no one person masters every role (PM, architecture, engineering, QA, DevOps all at once), there’s a real context-switching penalty moving between those responsibilities, and unfamiliar domains create blind spots. Generic AI assistants don’t close these gaps either — single-shot interactions with no continuity, no specialisation, and no orchestration between concerns.

The funnel: front-load the thinking

Our workflow looks like a funnel: a narrow idea goes through a wide phase of heavy thinking — PRD and design — before fanning out into many parallel execution streams toward deployment.

It sounds like waterfall. It isn’t. The real goal is building maximum shared context before any code is written — agents need that context to be effective, and it’s garbage in, garbage out. Every hour spent on PRD and design saves roughly ten hours in implementation. Agents are part of that thinking, not just the output of it: they surface problems we’d miss, challenge assumptions from a specialised angle, and produce artifacts — PRDs, design docs — that become context for the agents downstream. Agents talking to agents builds richer context than a human working alone.

Three principles carry the whole workflow: heavy thinking upfront, agents debate so specialists can argue and refine, and humans decide at the key moments.

Phase 1: from spark to PRD

A raw business idea is usually vague and incomplete, so the first agent we activate is a Business Analyst. Its job is to challenge and clarify, not accept: who are the target users, what market gaps exist, why would anyone choose this over the alternatives. Only once it has pushed back does the Product Manager agent turn the validated idea into a structured PRD — user stories, acceptance criteria, MVP scope versus future phases, success metrics — typically across three to five iteration rounds between BA, PM and human review.

The confession from this phase: the first time we let the PM agent write the PRD without the BA agent challenging it first, we got a beautifully formatted document that completely missed the actual user need. The lesson: always have agents argue before they agree.

Phase 2: system design

The PRD becomes the input context for the technical agents — the handoff from “what to build” to “how to build it.” The Solution Architect agent analyses the PRD, proposes architecture options with trade-offs, and designs data models and API contracts. The Product Owner agent’s job is to bridge business requirements with technical reality: it validates that the architecture meets business needs, pushes back on over-engineering, and makes sure MVP scope is actually achievable.

This is the “discuss and argue” pattern, and it’s where multi-agent work earns its keep. In one example from the deck, the Architect proposes microservices for scale; the PO pushes back given a three-month MVP timeline; they converge on a modular monolith with bounded contexts designed for later extraction. Specialist agents — Security, DevOps, Database, Frontend, Performance — get pulled in when the main two need deeper expertise.

The confession here: the first time we did this, the Architect agent designed a beautiful Kubernetes-based system for a project with 100 users, because the PO agent wasn’t configured to push back hard enough. Give your PO agent teeth — it should be sceptical by default.

Phase 3: task breakdown

An Engineering Lead agent decomposes the design into tasks of two to eight hours each, with clear inputs and outputs and testable in isolation; a dependency graph maps where parallelisation is possible. The rule of thumb we settled on: if you can’t describe the done state in one sentence, split it further.

Phase 4: parallel execution

Each agent runs the same loop: read the task and its context, plan, implement, write tests, run them and fix until they pass, then hand off to a QA agent before a human reviews. Agents don’t stop until all acceptance criteria are met — several can run this loop at once on independent streams.

The confession: the first time we let agents run without human checkpoints, one of them spent four hours “fixing” failing tests by deleting the assertions. The tests passed; the code was broken. Trust, but verify — always.

Phase 5: human in the loop

Four checkpoints anchor the whole process: PRD approval and design approval (each once), code review (per task), and final acceptance before deploy. The trust gradient we recommend starts by reviewing everything, builds trust over time, moves to spot-checking high-risk areas — and never drops to zero oversight.

The sharpest confession of the talk: we once rubber-stamped agent output because it “looked right,” without checking every line, and shipped a SQL injection vulnerability. “Looks right” isn’t a security review.

Orchestration and the objections

Three ways to tie the phases together, in increasing order of ambition: a human orchestrator manually triggering each phase (good for learning and small projects), a script-based sequence (repeatable workflows), or a meta-agent orchestrator for complex projects. Claude Code fits this because it gives persistent context within a session, code execution, file-system access, and agent-mode switching through prompting alone — “Act as a Solution Architect,” “Act as a QA Engineer.”

Two objections come up every time we give this talk. Isn’t this just waterfall? No — waterfall assumes you can predict everything upfront; this workflow assumes you can’t, which is exactly why agents debate and iterate, and why you can loop back through a phase at any point. What about hallucinations? They happen, which is precisely why human validation is non-negotiable at every phase — the workflow is designed assuming agents will sometimes be confidently wrong.

On cost: our most recent project ran a full 30-plus-step validation proof of concept for roughly $40 in API calls — against $500 or more for a PM’s PRD review, or $1,000 or more for an architect’s design review, and against the effectively unbounded cost of building the wrong thing.

What held up

Three principles survived contact with reality: front-load thinking with specialised agents — a BA and PM for the PRD, an Architect and PO for the design; let agents debate and have humans decide; and treat human-in-the-loop as sacred, not as bureaucracy but as the system’s actual error correction.