How our team collaborates on agentic coding

At Superserve, we are building the deployment platform for AI agents, and we use agents to build it. This is a look at our engineering workflow: how we use AI coding agents to plan, execute, and maintain our codebase.

Agents plan for agents

Before any code gets written, we run a 7-phase planning framework, entirely through Claude Code subagents. Each phase feeds into the next:

1. Scoping: Goals, non-goals, success metrics
2. Architecture: System design, Architecture Decision Records (ADRs), tech stack rationale
3. SDK Design: Developer-facing APIs, package structure, error handling
4. MVP Planning: Milestones, workstreams, dependency graphs
5. Task Breakdown: Every task with specific acceptance criteria
6. Agent Assignment: Tasks split across parallel agents, each with strict file ownership
7. Coordination: Integration order, PR review checklists, progress tracking

Engineers review and refine at each step. Agents write everything, including the prompts and instructions for the agents that do the building.

Parallel execution by design

When we tackle a large workstream, we split it across parallel agents. Claude Code's Agent Teams supports this natively — a team lead coordinates teammates through shared task lists, inter-agent messaging, and delegate mode. For a recent project, we ran multiple agents across three repos. Each got its own git worktree, its own branch, and a file ownership matrix so no two agents touch the same file.

One agent didn't write code at all — its job was reviewing everyone else's work and updating a shared progress file. Agents spawned subagents throughout.

The file ownership matrix does more than prevent merge conflicts. Each agent gets an explicit allowlist of files it can modify, defined before any code is written. This bounds the blast radius of bad output, makes each PR reviewable in isolation, and makes accountability clear: when a test fails, the matrix tells you which agent to re-run. Changes that cross ownership boundaries get escalated to a human.

Running agents in parallel only works if you're not hand-holding each one. We run Claude Code in sandbox mode with auto-approved bash commands. Agents run tests, build containers, and interact with tooling without waiting for human approval on every shell command. The sandbox constrains filesystem access and network reach; auto-bash lets agents move fast within those constraints. Each agent operates autonomously in a well-defined box: free to execute, unable to reach outside its scope.

It wasn't all smooth. After the coding tasks completed, we spent a day debugging real infrastructure issues: wrong image paths, network policies blocking callbacks, environment variables not forwarded. But the verification layers the agents had built (acceptance criteria, E2E tests, progress tracking) made it fast to identify what was broken and where.

Code review as a closed loop

Once agents open PRs, a Gemini review agent runs against each one. It checks for correctness, style, adherence to architecture decisions, and consistency across repos. Review comments get posted directly on the PR.

From there, we spin up parallel agents to address the comments, one per PR. Each agent picks up its review feedback, makes the fixes, and pushes. Nothing merges until the full E2E suite passes against staging. If a test fails, the agent that owns the relevant code gets the failure context and iterates until it's green.

The result is a tight loop: write, review, fix, verify. Engineers step in for judgment calls and final approvals, but the mechanical work of responding to review feedback happens autonomously and in parallel.

Everything lives in git

The plans, architecture docs, agent instructions, and progress tracking all get checked into a shared engineering space repo. Every engineer on the team clones it and gets the same context. Every coding agent reads from it.

When someone new joins, their agent already has context on the architecture, the decisions that were made, and why. And because agents maintain the docs as part of their workflow (updating progress, tracking issues, writing ADRs) the docs stay current. Not because someone remembered to update the wiki, but because it's part of how agents work.

What we've learned

Engineers orchestrate, agents execute. The job is defining what needs to be built, writing acceptance criteria, choosing approaches, setting guidelines, planning tests, and reviewing output. The skill is thinking clearly and communicating precisely.

Tooling speed kills or enables parallelism. Many agents in parallel means every slow build, slow test, or slow deploy multiplies. The agents are only as fast as the infrastructure they run against.

Trust requires visibility. We give agents real autonomy, but every task has verifiable acceptance criteria. A dedicated review agent catches issues. E2E tests run against staging. Trust without observability is just hope.

Iterate on architecture before writing code. Reviewing high-level design, security implications, technical choices, and system details up front is critical. We loop on architecture and design with agents until the plan holds up under scrutiny. A bad design decision that slips through is hard to find and debug once multiple agents have built on top of it.

The constraints are the product. The real leverage comes from refining architecture docs, agent instructions, file ownership rules, acceptance criteria, and test plans. The quality of constraints directly determines the quality of output.

The framework

Our planning framework is reusable across projects. Each phase has a prompt template and a structured output format: all markdown, readable by humans, parseable by agents, versionable in git.

We run all of these agents on Superserve. This is how we do engineering now. Not less engineering, more leverage.

Want to deploy your own AI agents? Get started with Superserve.