
Specs, Adversarial Review and a Human in the Loop: How My AI Agents Ship Code Safely
How I organized nine Claude Code sessions into a real engineering team, with a scrum master, a tech lead, developers, reviewers and a deploy role. They message each other and work from closed specs. Every PR goes through an adversarial reviewer and then Codex. Anything that touches production waits for my explicit OK. Includes the guardrails, the testing rules and the mistakes that shaped them.
I built a team of 9 AI agents. They message each other, review each other's work, and come to me when a decision is mine to make.
Claude Code just shipped a feature I've been leaning on hard: sessions can now message each other. Here's what that looks like with a whole team.
Over the past few days, the orchestrator behind an edtech was built by a team of Claude Code sessions, each with its own role:
π§ SM: clears blockers, manages permissions and environments, and gives the final release on every merge.
π― Tech lead: coordinates the work, owns the specs and sets priorities.
βοΈ API, front end, Python (Γ2) and deploy: write the code, each in its own area and its own worktree.
π Reviewers (Γ2): review every PR before it merges.
π€ Why chatting sessions, not subagents?
A subagent is a task. A teammate is a role.
- π§ Memory: a session lives for days with its own context. A subagent runs one job and is gone.
- π Permissions: each role has its own. The reviewer can't push, and nobody touches production.
- πΏ Isolation: each session has its own worktree and branch, so nobody overwrites anyone else's work.
- π Real independence: the reviewer never saw the author's reasoning, so it can't be talked into agreeing.
- β‘ No bottleneck: the work runs in parallel instead of piling up in one parent's context.
- π± Human access: I can open any session from my phone.
- β»οΈ Resilience: sessions survive reboots and account swaps with their role intact.
Subagents still have a job inside each session: wide searches, parallel checks, and the self-review before every PR, run in a fresh context.
π Subagents for tasks, sessions for roles.
What made it work wasn't the model. It was the process:
π Specs and tasks before code. 16 specs with a closed contract. If the spec doesn't answer a question, the agent asks before inventing an answer.
π Two layers of review. First an internal reviewer, with a clean context and an adversarial mindset. Then Codex on GitHub, to catch what slipped through. Only P1 and P2 findings block a merge, and each PR gets at most 3 Codex rounds. If the same problem keeps coming back, the design isn't settled: it goes back to the spec instead of getting another patch.
π§ͺ Tests that prove something. Every fix ships with a test that failed before it. To prove the test covers the bug, we revert the fix on purpose and check that the test breaks. When the CI ran out of budget, we ran the suite by hand and attached the output to the PR.
π‘οΈ Guardrails.
- Every session has its own permissions.
- No agent pushes to main.
- PRs stay small, and files stay under 400 lines.
- Secrets stay out of git.
π€ Human in the loop. Spending, product calls and student data go to a decision queue in Slack. Anything that writes to production (deploys, migrations, SQL) needs my explicit OK, which reaches me by email with a π¨ and a direct link to the decision.
β»οΈ Persistence across accounts. A monitor tracks usage across five Claude accounts and swaps the credential when one hits its limit. After the swap, it reconnects Remote Control on every session without clobbering anything typed at the prompt, and emails me the new links. The team keeps working, and I follow along from my phone.
The result: about 400 merged PRs in 4 days, every one of them reviewed.
And me? I'm the one holding the balloons. π
#ClaudeCode #AI #SoftwareEngineering #MultiAgent #DevOps
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article