I Got Tired of Babysitting AI Coding Agents, So I Built an AI Scrum Team

A 2-minute demo of the Mac app this article is about.

📥 MaulTeam.app — landing page & download

AI made me faster. So why was I exhausted?

Ask a coding agent to implement something, and a few minutes later a huge diff comes back. Tests included. Even a design note.

That's where the real work started, though.

Checking whether the diff actually satisfies the requirements — that was me. Spotting that the tests merely restate the implementation — also me. Doubting the cheerful "Done!" and actually running the thing — me again.

Add a second and a third agent, and a new job appears: tracking who is doing what, untangling conflicting changes, re-explaining context to an agent that lost it. My time spent writing code dropped to zero, and yet whole days were disappearing into AI supervision.

AI really is fast at writing code. But I've come to think that this only moved the bottleneck — from writing to controlling the system that writes.

AI coding agents can generate more code than a human can review.
The bottleneck is no longer writing code. It is controlling the system that writes it.

Once generation outruns review, there seem to be only two options: stop reviewing and trust the output, or throttle generation down to human review speed. The first gives up on quality; the second gives up most of the point of using AI.

I got tired of that dilemma and went looking for a third option. This article is the story of building it — not a smarter agent, but an organizational structure that governs agents.

Where the two usual approaches broke down for me

As far as I can tell, current practice clusters around two poles.

Pole 1: Vibe coding — improvise in a chat window

Fire instructions at an agent as they occur to you, look at what comes back, fire the next one. Fastest way to a prototype — but past a few days of project life, I watched it fall apart again and again.

• Decisions leave no trace. A week later, nobody — not me, not the next session's AI — can explain why the architecture looks the way it does
• Requirements and implementation drift apart. The spec lives in a chat scrollback, mutating as you go, until nobody knows what "correct" means
• Tests become an afterthought. It's hard to summon the energy to write tests for something that already looks like it works
• The AI misses blast radius. Code outside the context window might as well not exist

I've come to believe vibe coding's core problem isn't speed — it's amnesia. Human and AI both keep moving forward with no memory of judgment.

Pole 2: Heavy spec-driven development — decide everything up front

The opposite pole: freeze a complete spec before the AI touches anything. You get order, and a different set of problems.

• Writing the spec is heavy work. The human ends up carrying the hardest part again
• It fights unknown-heavy development. Deciding everything up front is exactly what you can't do when you learn by building
• If the spec is wrong, the AI implements the wrong thing at full speed. Agents don't question the map you hand them

Putting it together: vibe coding breaks because there is no inspection, and heavy spec-driven breaks because there is no adaptation.

Software engineering has been here before — cowboy coding versus waterfall. And human teams found an answer in between decades ago: build in short iterations, inspect working software, adapt in the next iteration. Scrum.

What I needed wasn't a smarter agent — it was an organization

The conclusion I eventually reached:

The problem was not that the coding agent was insufficiently intelligent.
The problem was that it had no delivery system around it.

Human teams have the same issue, if you think about it. Put six brilliant engineers in a room, say "good luck," and walk away — progress goes invisible, quality varies wildly, integration becomes a mess. That's why real teams have roles, reviews, test gates, retrospectives. Teams produce trustworthy output not by making individuals smarter, but by giving the organization a structure in which mistakes get detected and corrected.

So I tried giving AI agents the same structure:

• Product Owner — decides what to build. A human — or, in the autonomous mode described later, an agent
• Scrum Master — coordination and flow; writes no code itself
• Developer agents (several) — each implements one backlog item at a time
• Reviewer agents (several) — verify design, implementation, and tests from separate viewpoints
• Sprint Review — inspect working software
• Retrospective — feed failure patterns into the next Sprint's improvements

To avoid a misunderstanding: this is not "make the AI play office." Having agents perform a daily stand-up would accomplish nothing. The value isn't reproducing Scrum's ceremonies — it's redesigning each of them as a control loop that contains AI failure modes:

• Review isn't an approval ritual — it's adversarial verification by an agent with a separate context
• Tests aren't a comfort blanket — they're a pass/fail gate written from the spec alone, by an agent that cannot read the implementation
• Sprint Review isn't a status meeting — it's a checkpoint that refuses self-reports and only counts working software
• The retrospective isn't a debrief — it's a configuration change so the same failure doesn't happen twice

The idea is to repurpose what human Scrum spent decades refining — "getting reliable output from a collection of unreliable individuals" — as a governance mechanism for AI. In practice, AI follows this structure rather more obediently than humans ever did.

What Maul Team is

I built this structure as Maul Team. In one sentence:

Maul Team is a local, multi-agent software delivery system that runs a real Scrum loop on top of Claude Code.

The framework itself — agent definitions, workflows, state management — is MIT-licensed open source, usable from the CLI. On top of it, I built a native Mac app (MaulTeam.app) to make the framework easy to drive. The app is source-available: the source is public, personal and internal business use is currently free, and redistribution is not permitted.

What the Mac app gives you:

• Supervise everything in one window: the Scrum Master conversation, the team's Work Log, the backlog board, and the project's code
• Run up to six developer agents in parallel
• Develop each backlog item in its own isolated git worktree, merging only what passes the gates
• Persist all state locally — interrupt and resume any time
• Both a human-in-the-loop mode and an autonomous mode that keeps running Sprints while you sleep

That's enough feature-listing. It's quicker to show what actually happens.

What actually happens — building one small app

Here's the real flow when you hand it a goal like "build a simple task-management CLI":

1. You enter the Product Goal. At first, that's the human's whole job
2. A Requirements Analyst asks questions back. "Where should data persist?" "Do you need multi-device sync?" It won't run on vague requirements — they get pinned down into a requirements doc first
3. The backlog is split into items. Each is one unit of user-visible behavior — a PBI (Product Backlog Item)
4. The human approves the Sprint's goal
5. Several Developers implement in parallel, each working in its own worktree, so nobody tramples anyone's changes

PBIs flow across the Scrum board while each agent's work streams into the Work Log in real time.

1. Design, implementation, and tests each get reviewed — by agents in separate contexts, optionally cross-reviewed by a different model (Codex)
2. Only PBIs that pass the gates get merged. Every merge runs a regression check
3. Sprint Review inspects the working product. Findings go onto the next Sprint's backlog

What I'd ask you to look at isn't the speed of success — it's where mistakes get stopped. Running this daily, scenes like these are routine:

• The UI was finished, but a persistence requirement was missing → caught not by code review but by the requirements-conformance review, and sent back. No human had to squint at diffs to find it
• All unit tests passed, but the merge-time regression gate caught a break in existing behavior → merge refused, item bounced back to its developer
• Requirements were ambiguous, and instead of guessing, the agent escalated: "the spec is unclear" → the human Product Owner answers in one line and work resumes. Confidently-written code built on a silent guess is the scariest failure mode I know, so the system is designed to force escalation over guessing

Don't trust an agent's "Done!" — count only what survives the gates. That one rule changed the nature of my supervision from "doubt everything" to "audit the design of a few gates." The surface I have to watch shrank from countless diffs to a handful of loops.

"Isn't this just running agents in parallel?"

Fair question — there's a growing family of excellent tools (Orca is a well-known one) that fan a prompt out to N agents in isolated worktrees, let them race, and let you compare the results and merge the winner.

I think of those as comparison orchestrators: parallel attempts, human picks. They're great for exploring solution variants fast — but the human is still the quality system, and the judgment load scales up with parallelism: you now review N outputs instead of one.

Maul Team is aiming at a different job: a delivery system. One team, explicit roles, and mistakes stopped by structure — black-box tests, adversarial reviews, merge gates, escalation rules — before a human looks. Parallelism here means six agents advancing six backlog items through the same quality machinery, not six drafts of the same prompt.

If you want to explore variants, a comparison orchestrator is the right tool. If you want to hand over a multi-day build and keep your review load flat, you want governance. I built the second thing because the first one didn't fix the bottleneck I was drowning in.

Loop Engineering — design the loops, not the prompts

From here on, this is for readers curious about the machinery.

If I had to compress Maul Team's design philosophy into one term, it would be Loop Engineering. I define it like this:

Prompt engineering improves the instruction.
Context engineering improves what the agent knows.
Loop engineering improves what happens after the agent is wrong.

Agents will be wrong. So the thing worth betting on, I think, isn't "cleverness that avoids mistakes" but "structure in which mistakes are detected, corrected, and learned from." Maul Team implements that as three nested loops:

1. The development pipeline loop (per PBI) — design → implement → test → review, repeated until the pass conditions are met. The test-writing agent cannot read the implementation source (black-box), so it can't write flattering tests. Termination isn't "the agent says it's fine" — it's decided mechanically by a composite of success, stagnation, divergence, and hard-cap conditions
2. The Sprint loop — after all of the Sprint's PBIs merge, the whole repository is audited. Post-integration drift that per-item review can't see — duplicated implementations, divergence from the spec, security issues — is detected and fed into the next Sprint's backlog. Improvements decided in the retrospective flow through the same path
3. The autonomous execution loop — launch Maul Team in autonomous mode, and an outer watchdog iterates entire Sprints toward the product's goal. An agent takes the Product Owner seat too, and every decision lands in an audit log. Safety valves (caps on iterations, wall-clock time, and consecutive failures), automatic recovery from API rate limits, and a morning report make "it kept running while I slept" an actual, bounded claim

I understand the unease about pushing in this direction. The wariness about cognitive surrender — human involvement hollowing out as you delegate more — is legitimate, I think. Maul Team's answer is: remove the human from the labor, never from the governance. Human judgment concentrates on refining the product vision and evaluating what gets built by actually touching it — and every decision is logged and auditable after the fact.

Explorer, the Scrum Master conversation, the Work Log, and the Sprint/PBI board — all in a single window.

Who it's for — and who it's not for

To be honest, the sturdy harness costs something: speed and token consumption are both sacrificed. I'd rather you know that going in and use it where it fits.

A good fit if you:

• Already use Claude Code
• Want to hand AI a build that takes half a day to several days
• Want parallel agents in worktrees, without doing the management yourself
• Don't unconditionally trust AI output
• Want a durable record of design, tests, reviews, and decisions
• Want everything running locally — no handing your code to an external service

Not a good fit if you:

• Want a one-file prototype right now (plain Claude Code is faster)
• Consider code review and tests unnecessary
• Don't have a Claude Code environment or subscription
• Expect a finished no-code product

Limits, and what isn't done yet

• Requires the Claude Code CLI (2.1.172+). Claude usage costs are separate
• macOS 14+ for the app — a universal binary for Apple Silicon and Intel, signed and notarized by Apple. The CLI framework also runs on Linux
• It does not guarantee the AI is right. The gates raise the detection rate of mistakes; they don't make it zero
• Adopting Scrum's forms doesn't automatically produce a good product. Deciding what's worth building is still the Product Owner's job — usually yours
• The Codex CLI for cross-model review is optional; everything runs without it

If you try it

Download MaulTeam.app, point it at a small existing project, and run just one Sprint.

• 🎬 2-minute demo
• 💻 GitHub — the framework is MIT
• ✅ Requirements: macOS 14+ / Claude Code CLI 2.1.172+ / a Claude subscription

I've grown quite fond of this as my daily AI development setup, so I plan to keep raising this team for a while. Feedback and issues are very welcome.

(This article is an English rewrite of my Japanese original on Zenn.)