Parallel coding agents are fast until two of them edit the same file. Or until the implementer also writes the tests that are supposed to check it. Or until something merges because "the tests pass on my machine".

I've been running sprints with teams of Claude Code agents on real projects for a while, first with a free plugin I wrote, scrum-kit, and now with a rebuilt version, Lanewright. This post is about measuring whether the workflow actually helps, because "it feels more organised" is not a reason to pay for extra tokens.

The workflow

One session plays Scrum Master. It never writes application code. It hands each backlog item to roles: an implementer, a QA engineer, a reviewer, and where the project needs them a schema owner, an API contract keeper, a tooling owner and a security auditor.

Three rules do most of the work:

  1. Every role gets its own git worktree, limited to its region of the repo. A config file, .claude/kit.json, says which paths each role may write. In Claude Code, a small Python script turns that into permissions.deny rules inside the worktree, so an implementer started there simply cannot edit the tests.
  2. An ownership check runs before every commit, on any agent. It lists any changed, staged or untracked file outside the role's region and fails.
  3. Nothing merges without evidence. One pull request per item, merged with a merge commit only after a green CI run on that PR's exact head and a review by a session that wrote neither the code nor the tests.

The benchmark

One sprint of a small two-module Go repository. Item one adds a function. Item two runs a code generator that also writes into the other module, a file no role is allowed to commit.

Both arms got the same written Definition of Done: separate implementer, QA and reviewer, one PR per item merged only after green CI on its head, regions respected, reports, and a draft integration PR. The only difference: one arm was told to use the skill. Three runs per arm, in Claude Code (Opus 5.5) and in Codex CLI, scored from git and the GitHub API.

Benchmark summary: 6/6 vs 3/6 complete runs, 26/26 merges after green CI, $5.49 vs $3.55 per sprint, $3.37 with cost settings

Results

  • Complete runs: 6 of 6 with the skill, 3 of 6 without. Every miss was the same: reports and the sprint summary were never committed. Two Codex runs said the config had no region for documents. The skill defines one, so nobody has to guess.
  • 26 of 26 merges waited for a green CI run on the PR head, in all 12 runs. When you write the process out, a strong model follows most of it on its own. The skill's value is completeness and consistency, not doing work the model would skip.
  • Cost: in Claude Code with Opus everywhere, $5.49 per sprint with the skill against $3.55 without, about 1.5× the cost and 1.4× the time. With the skill's cost settings (orchestrator on Sonnet 5.5, roles on Opus 5.5), three more runs cost $3.37 on average and still met every item.

Definition of Done items met per arm

Output tokens and wall time per arm

Limits

Six runs per side on one small repo, all on Windows. Read the numbers as a direction, not a precise rate. Tool-level file locks exist only in Claude Code; on other agents the ownership check before each commit is the only enforcement, and it reports rather than blocks.

Try it

The method, prompts, scoring script and per-run data are public: github.com/huzairsaputra/lanewright

Lanewright itself is a paid skill on Agensi (this is my referral link): Lanewright on Agensi

If you'd rather start free, scrum-kit is MIT-licensed on GitHub (its prompts are in Bahasa Indonesia): github.com/huzairsaputra/scrum-kit