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 · Give to your AI
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.
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 connects the parts; the workflow reference 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 · Inside the memory kit.
What changed in my work
Swipe to see the full chart. Orange October is a partial month.
Monthly counts and counting rules
PRs authored by hataheri, counted by merge date across accessible GitHub repositories. Commits match hataheri or Hamed Taheri across 39 valid local repositories, deduplicated by hash; includes merges and unmerged work, with no fetch. Separate zero-based linear scales; line and bar heights are not directly comparable.
| Month | Merged PRs | Commits |
|---|---|---|
| 2025-10 | 0 | 15 |
| 2025-11 | 8 | 64 |
| 2025-12 | 9 | 52 |
| 2026-01 | 35 | 157 |
| 2026-02 | 5 | 74 |
| 2026-03 | 47 | 458 |
| 2026-04 | 85 | 963 |
| 2026-05 | 128 | 1,200 |
| 2026-06 | 136 | 1,318 |
| 2026-07 | 131 | 1,591 |
| 2026-08 | 136 | 1,876 |
| 2026-09 | 154 | 2,569 |
| 2026-10 (partial) | 972 | 3,480 |
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 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.
$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.
$1.86 → $0.48
The same task, lean worker
8 model calls instead of 21, less than half the peak context, and every acceptance check met.
37
Stops instead of guesses
Workers that hit a gap in the brief handed the task back. Each stop cost cents; a guessed migration costs far more.
API-priced usage, not invoices. The two cost windows count tasks differently; this is not a matched comparison. How I counted ↗
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.
These costs are API-priced usage estimates, not subscription invoices. The evidence retains the dates, counting rules and exclusions.
How the work flows
Me + coordinator
49.6% of spend
Plans with me, writes specs, launches runs. Never reads code or diffs.
Preparer
$0.18 median
Turns the spec into a six-field brief, or answers NOT READY.
Worker
$0.43 median
Capped, lean, own worktree. Implements one brief and opens a draft PR.
Reviewer
$0.11 median
No edit tools. Reviews the exact revision: MERGE, MERGE AFTER or DO NOT MERGE.
Gate + me
human time
I clear conditions and merge to an integration branch. Release is a separate, supervised step.
Claude Code and Codex have different adapters and controls. The workflow reference explains them; sharing task state does not make the tools identical.
What operating it taught me
$36.70
An agent refreshed 8,336 cached pages one at a time. One wildcard would have cost about half a cent.
Now: A hook blocks it before it runs.
9 rounds
One PR, patched one finding at a time. Each review found the next problem; two patches added new serious bugs.
Now: One deep review, one complete fix, one confirmation.
0 columns
A spec said a sibling task creates the table, without listing its columns. The worker guessed; mocked tests passed.
Now: Paste the exact table definition into every spec that uses it.
90 MB
Free disk left mid-run: 251 leftover worktrees and a 301 GB container disk. A review failed to start.
Now: Check free space before every batch; prune after.
Those failures shaped the seven practices in the full playbook: prepare, execute, review, count costs, share memory, enforce limits and save 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.
What this does and doesn't show
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 to identify a constraint and the pilot guide to test one change. Track acceptance, every attempt, full cost, human time and repairs before adding more parallel work.
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 includes templates, a local memory exercise and evidence. The production runner scripts are available on request. Read the full playbook or compare notes with me.