Where Development Actually Slows Down
By the time a feature ships, the time spent writing code is smaller than it feels. The time sink is everything around it — breaking requirements into tasks, waiting on review, adding tests, handing work off between people.
"AI makes coding faster" is true. But a team's real bottleneck isn't coding itself — it's the friction of the surrounding steps and handoffs. One coder getting 3× faster does nothing for the pipeline if review sits for two days.
This post is a recipe for running the whole dev pipeline on a single Marblo board. Not to replace your personal coding tool, but to orchestrate the team pipeline around it.
Why a "Board," Not Just a CLI
Single-agent tools like Cursor or Claude Code are built for one person in one session. Powerful, but personal-productivity tools. A team pipeline is different — multiple stages, multiple people, and the visibility of who got how far.
Development, too, is a bundle of different kinds of work:
- Task breakdown — turning requirements into actionable tasks (long-context understanding)
- Implementation — writing code (speed)
- Review — independent code review (a different set of eyes)
- Testing — generating and running tests (verification)
Assigning each stage to a model chosen for its strength is the heart of heterogeneous agents, and why a board structure fits team adoption better than a personal CLI is covered in subagents vs. real multi-agent.
Recipe Architecture
[Issue / requirement intake]
│
▼
planner (task breakdown)
│
▼
coder (implementation)
│
▼
reviewer (code review · different vendor) ── change requested ─┐ (loops back to coder)
│ │
▼ │
tester (generate & run tests) ◀────────────────────────────────┘
│
▼
[Team approval gate] → PR / merge
The key is the reviewer → coder loop-back. When the reviewer requests changes, work returns to the coder to address them. The board runs the round-trips a human reviewer used to do, leaving only the final approval to a person.
Station by Station
1. planner — Task Breakdown
Splits a requirement into an actionable task list. It's about reading long context and structuring it, so Claude fits.
You are a task breakdown agent. Take an issue/requirement and split it
into implementable units.
- Each task: goal / files to touch / done criteria
- State ordering where dependencies exist
- Mark ambiguous requirements as "needs clarification"; don't guess
2. coder — Implementation
Turns tasks into code. Use a GPT-class model, strong at fast implementation. It needs repo and file access, so attach MCP tools (filesystem, Git) — for why MCP is the standard for this, see the MCP guide.
3. reviewer — Code Review
Reviews the written code. Crucially it uses a different vendor (Gemini) — a model reviewing its own code shares its own blind spots.
You are a code review agent. Review the changed code against the task's
done criteria.
Check: done criteria met / obvious bugs & edge cases / consistency with
existing conventions. If there are issues, request changes with file and
line. Otherwise, pass.
4. tester — Generate & Run Tests
Creates tests for the change and runs them. Via MCP it can invoke a real test runner or trigger your existing CI.
Team Collaboration — the Board Is the Shared Surface
This is where a board diverges from a CLI tool. The whole team sees the same board. Which task is at which station, whether it's stuck in review, how much it cost — all visible at a glance. People step in at chosen stages (review, merge) via approval gates, and handoffs happen on the board, not in a Slack thread.
If you already use a CLI tool, this is a complement, not a replacement — personal coding in your tool, team-pipeline coordination and visibility on the board. For a grounded sense of team-level adoption, see running Claude Code + MCP in a real studio.
Real Numbers and Honest Limits
What this recipe improves is usually lead time (issue → merge), review wait time, and handoff friction. As repetitive first-pass review and test-writing get automated, human reviewers focus on the real judgment — logic, architecture, security.
Honestly, architecture decisions and final responsibility for the code stay with a person — and they should. The reviewer agent is a first-pass filter, not a final sign-off. What this recipe removes is friction, not judgment.
FAQ
Q. Who's responsible for agent-written code? The approval gate plus human final review is the responsibility boundary. How much authority to give in-house agents and how to audit them is covered in the 5 principles of AI agent governance.
Q. Does it conflict with our CI/CD?
No. Have tester trigger your existing CI or call the runner via MCP. The board doesn't replace CI — it coordinates the stage in front of it.
Q. I use Cursor — do I have to switch? No, it complements. Personal coding stays in Cursor; the orchestration and visibility of a multi-person pipeline moves to the board.
Q. What does it cost?
Multi-agent boards are available from Marblo Pro (from ₩19,000/month), plus per-run API charges. Placing reviewer and tester on cheaper models cuts cost.
Build It Yourself
To build this board around your own repo and review rules, book a free 30-minute session. Or just start free on Marblo.
Related Posts
- Claude Code Subagents vs. Real Multi-Agent — What's the Difference?
- Running Claude Code + MCP in a Real AI Studio
- Why Heterogeneous AI Agents Beat a Single Model
- Building Your First Multi-Agent System with Marblo
Last updated: 2026-07-11. Marblo's UI improves often, but the board recipe pattern is stable.