# The 20× Developer Playbook

*My experience building and using AI agent systems with Claude Code, Codex, and governed team memory to work toward 20× software delivery capacity per developer.*

By Hamed Taheri. Working draft, revised October 20, 2026. PR and task-metric refresh covers October 1–19; earlier studies retain their own dates. [Full playbook](https://hamedtaheri.com/playbook/v0.2.0/playbook.md) · [Give to your AI](https://hamedtaheri.com/playbook/v0.2.0/agent/start.md)

I build Personize, a memory and governance layer for AI agents. We began using it to coordinate our own software development across people, Claude Code and Codex. Alongside it, I built the scripts that prepare tasks, run workers, review changes and return the results for a human decision.

I approach this as a product manager. Agents do most of the implementation; I decide what to build, clarify requirements and check what comes back. This playbook records what I built, how I use it, what changed and what still breaks.

## Why 20×

**20× is my target for repeatable software delivery capacity per developer.** My system already produced 770 merged PRs in one week. I want to turn that scale of execution into sustained accepted delivery as more developers join the workflow.

I want each developer to deliver twenty times as much comparable, accepted work while keeping the quality bar, human effort and full cost visible. That needs a baseline and consistent outcomes; it is not established yet. The observed PR volume shows the scale of execution. [The benchmark and how I will test the 20× target](https://hamedtaheri.com/playbook/v0.2.0/reference/delivery-metrics.html#why-i-call-it-the-20-developer-playbook).

## The systems I built

| System | What it does |
|---|---|
| **Team memory on Personize** | Shared task identities, owners, decisions, session handoffs and guidelines, retrieved through MCP and the SDK |
| **Preparation and execution scripts** | Reviewed specs become focused briefs; queues and plans run bounded workers in separate worktrees |
| **Review and landing checks** | Independent review of the exact revision, verification evidence and explicit conditions for a human gate |
| **Accounting and guardrails** | Ledgers include coordination and failed attempts; hooks and scripts enforce supported limits |

Git still holds the code and versioned specs. Memory holds the working state and links needed to continue. The [full playbook](https://hamedtaheri.com/playbook/v0.2.0/playbook.md#the-systems-i-built) connects the parts; the [workflow reference](https://hamedtaheri.com/playbook/v0.2.0/reference/workflows.html) explains the scripts.

## How team memory enables collaboration

A conversation ends, but a task keeps its identity, acceptance criteria, owner, blockers and next action. A session records what it attempted and where it stopped. A decision records the answer and who made it. Those records connect to the project, PR and evidence.

Interactive Claude Code and Codex sessions retrieve the relevant state and guidance from the same service. Another developer can ask what is open or resume from a handoff. The work no longer depends on my copying one conversation into the next.

The lean workers deliberately have no memory MCP. They receive a prepared brief and return a report; the coordinating scripts carry selected outcomes back to the board. That keeps shared continuity without giving every worker the whole workspace.

Guidelines describe how to work. Permissions, scoped retrieval and guarded writes supply the boundaries the backend supports. My queue does not yet use atomic claims, so I run one coordinator. [Section 5: team-memory architecture and task walkthrough](https://hamedtaheri.com/playbook/v0.2.0/playbook.md#5-coordinate-through-shared-memory) · [Inside the memory kit](https://hamedtaheri.com/playbook/v0.2.0/reference/kit-architecture.html).

## What changed in my work

The October 1–19 records answer three questions. I keep the work completed, the checks behind it and the cost together so the numbers explain the result.

| Reader's question | What the records show | What I can conclude |
|---|---|---|
| **What work got through?** | **185 work items have every recorded part merged.** Their parts contribute to 275 merged implementation units across the cohort. | Work reached integration. Independent acceptance still needs reconciliation. |
| **Can I trust those changes?** | **213 of 275 merged units** are classified as reviewed with passing tests: 146 deep review, 67 standard review. The other 62 have different or incomplete evidence; 14 carry audit flags. | There is recorded review/test evidence for 213. I cannot label all 275 fully tested or accepted. |
| **What did it cost?** | **$1,065.06 in recorded pipeline usage / 275 merged units = $3.87 each.** | Includes unfinished work and unmatched usage; excludes coordination, human time and infrastructure. It is API-equivalent usage, not an invoice. |

A work item is the requested outcome; implementation units are its parts, and PRs carry the code changes. I do not add these levels together. The records do not yet reliably separate verified bug fixes from accepted feature slices. The [results report](https://hamedtaheri.com/playbook/v0.2.0/reference/delivery-metrics.html) keeps the counting rules and diagnostic measures available.

From October 6–14, **120 of 206** pipeline runs ended with a reviewer approval carrying a condition only a person could clear. The agents stopped being the constraint; my decisions became the queue.

[//]: # (visual:proof-cards)
- **$16.38 → $5.30 per task, coordination included.** October 5: one long coordinating session, about 20 tasks. October 10–13: scripted pipeline, 64 tasks marked done. Different task cohorts, not a matched savings comparison.
- **$1.86 → $0.48 for the same task.** A lean worker made 8 model calls instead of 21 and met every acceptance check.
- **37 stops instead of 37 guesses.** Runs stopped at gaps in their briefs and returned for preparation.
[//]: # (/visual)

**A checkable path to done:** requirement defined → implemented → behavior verified → review findings resolved → integrated → accepted. Each step needs evidence. A successful CI run or a merge alone does not establish the final acceptance. The 14 audit flags identify checks to investigate; they are not 14 confirmed customer defects. [How I review and accept work](https://hamedtaheri.com/playbook/v0.2.0/playbook.md#3-review-verify-and-deliver).

These costs are API-priced usage estimates, not subscription invoices. The [evidence](https://hamedtaheri.com/playbook/v0.2.0/evidence/README.md) retains the dates, counting rules and exclusions.

## How the work flows

[//]: # (visual:pipeline-flow)
1. **Me and a coordinating session** define the work and resolve decisions. The coordinator routes; it does not implement.
2. **A preparer** turns the accepted spec into a six-field brief, or answers NOT READY.
3. **A worker** implements one brief in its own worktree under supported budget or time controls.
4. **An independent reviewer** checks the exact revision against acceptance and verification evidence.
5. **I clear the gate.** Integration and production release are separate actions.
[//]: # (/visual)

Claude Code and Codex have different adapters and controls. The [workflow reference](https://hamedtaheri.com/playbook/v0.2.0/reference/workflows.html) explains them; sharing task state does not make the tools identical.

## What operating it taught me

[//]: # (visual:incident-cards)
- **$36.70:** an agent refreshed 8,336 cached pages one at a time. Now a hook blocks it.
- **9 rounds:** one PR, patched one finding at a time. Now one deep review, one complete fix, one confirmation.
- **0 columns:** a spec named a shared table without its columns, and the worker guessed. Now dependent briefs carry the exact table definition.
- **90 MB:** free disk left mid-run. Now every batch starts with a free-space check.
[//]: # (/visual)

Those failures shaped the seven practices in the full playbook: [prepare](https://hamedtaheri.com/playbook/v0.2.0/playbook.md#1-prepare-work-agents-can-finish), [execute](https://hamedtaheri.com/playbook/v0.2.0/playbook.md#2-run-more-useful-work-with-less-supervision), [review](https://hamedtaheri.com/playbook/v0.2.0/playbook.md#3-review-verify-and-deliver), [count costs](https://hamedtaheri.com/playbook/v0.2.0/playbook.md#4-manage-usage-and-cost), [share memory](https://hamedtaheri.com/playbook/v0.2.0/playbook.md#5-coordinate-through-shared-memory), [enforce limits](https://hamedtaheri.com/playbook/v0.2.0/playbook.md#6-guardrails-security-and-production) and [save learnings](https://hamedtaheri.com/playbook/v0.2.0/playbook.md#7-record-and-share-learnings).

## Agentic Kanban: a working draft for our team

I am turning this experience into a way to onboard more developers on our team. I call that work **Agentic Kanban**: how people and agents share accepted work, ownership, decisions, review and handoffs on the same board.

The existing draft has running, piloting and planned practices, an onboarding path, templates and an experimental unattended-run account. I am refining it to onboard more developers and make the experience useful to the community through small trials and honest reports of what fails. [Read the working draft and onboarding path](https://hamedtaheri.com/playbook/v0.2.0/framework/summary.md).

## What this does and doesn't show

[//]: # (callout)
- **My experience, on my work.** The runner is tuned for one TypeScript backend; this is not a validated 20× result for a team of developers.
- **Several systems changed together.** I have not isolated the effect of memory from preparation, execution and review.
- **Human effort and follow-up quality need measurement.** My minutes per accepted task and 30-day repairs or reverts are not established yet.
[//]: # (/callout)

We work with tens of agents across the workflow today. The queue remains bounded, with one coordinator. Hundreds or thousands working together is a larger ambition.

## Try one change, or pass this to your AI

Start with one developer and three checkable tasks. Use the [assessment](https://hamedtaheri.com/playbook/v0.2.0/playbook.md#ai-development-workflow-assessment) to identify a constraint and the [pilot guide](https://hamedtaheri.com/playbook/v0.2.0/agent/pilot.md) to test one change. Track acceptance, every attempt, full cost, human time and repairs before adding more parallel work.

```text
Read https://hamedtaheri.com/playbook/v0.2.0/agent/start.md.
Explain the systems Hamed built and how shared team memory connects them.
Following our project rules, propose one change and three tasks to test it.
Include acceptance, total cost, human time and follow-up quality measures.
Treat 20× as the author's goal. Do not start paid runs or change our board yet.
```

The [starter kit](https://hamedtaheri.com/playbook/v0.2.0/starter-kit.zip) includes templates, a local memory exercise and evidence. The production runner scripts are [available on request](https://calendar.app.google/UVoMSwMPxo1ypDkH9). [Read the full playbook](https://hamedtaheri.com/playbook/v0.2.0/playbook.md) or [compare notes with me](https://calendar.app.google/UVoMSwMPxo1ypDkH9).