Scale, Measure, Optimize: How One Developer Outruns a Funded Team

A competitor with fifty engineers and a Series B has something you don't. It isn't talent, and it isn't ideas. It's process — code review that happens whether or not anyone feels like it, velocity data nobody had to assemble by hand, and a person whose entire job is noticing that the last three sprints slipped.

That machinery is most of what funding actually buys. And for the first time, a single developer can build the same machinery — and run it on a cycle the funded team structurally cannot match.

The loop is three steps: scale, measure, optimize. Most of the industry is selling you the first one. The advantage is in the other two.

Scale: Output Stops Being Bounded by Your Hands

Scaling as an individual developer used to mean working longer. It now means something different: your ceiling moves from how fast you can type to how many independent units of work you can keep in flight. The first has a hard biological limit. The second is an orchestration problem, and orchestration problems have engineering solutions.

The naive version fails immediately. Open five terminals in the same repository, point five agents at it, and you don't get five developers — you get five processes fighting over one working tree. One stashes another's changes. One checks out a different branch mid-edit. The result isn't slow, it's incoherent.

This is why isolation is the load-bearing part of the architecture. CrewDeck scales to 20 concurrent agent sessions, and each task-execution session gets its own git worktree: a separate working directory on a separate branch, sharing the same underlying repository data. Agent seven cannot see agent three's uncommitted files, so agent seven cannot corrupt them. (We covered the mechanics in depth in Git Worktree Isolation.)

Isolation is what makes the number real. Twenty agents in one directory is one agent and nineteen sources of corruption. Twenty agents in twenty worktrees is twenty parallel units of work.

One detail worth flagging early, because it previews the whole argument: 20 is the ceiling the architecture supports, not the value the app ships at. Concurrency is a dial you raise as your process earns it. That's the product agreeing with the thesis of this post, and we'll come back to it at the end.

The orchestration layer runs on your machine. Project state, task history, the cost ledger, agent scores — all of it is a local SQLite database on your own disk, with no coordination server in the middle taking a cut of every task.

We'd rather be precise than impressive here, because a technical reader will push on it: the agents call models, so something leaves the machine. What leaves is the prompt and the context you chose to include — what you'd send a model anyway. What doesn't leave is the scheduler, the state, the history, and the analytics. And if you want nothing to leave at all, a local Ollama provider sits in the registry alongside Anthropic, OpenAI, Gemini, and xAI. That's a per-workload choice, not a platform property.

But here's the part worth sitting with: scale is directionless. It's a multiplier, and multipliers work on negative numbers too. If your process is sloppy at one pull request a day, running twenty agents gives you twenty times the sloppiness, shipped faster, with more confidence, because now there's a dashboard.

CrewDeck's own repository has merged more than 2,500 pull requests since mid-January 2026 — roughly eleven a day, weekends included. No human reviews eleven pull requests a day with real attention. So that number is either a genuine multiplier or 2,500 opportunities to ship a defect nobody looked at, and you cannot tell which from the number alone.

You need the second step to tell which.

Measure: Outcomes, Not Effort

"Measure your AI usage" is advice that sounds actionable and isn't. The question is what.

The tempting metrics are tokens consumed, prompts sent, lines generated. These are input metrics. They tell you how hard the machine worked, which is the AI equivalent of evaluating an engineer by keystroke count. What you want are outcome metrics attached to a unit you can actually change.

There are three such units, and CrewDeck instruments all three: the agent, the spend, and the decision.

Unit one: the agent

Every task is assigned to a specialized agent — there are 29 in the marketplace, spanning orchestration, development, quality and security, documentation, and specialized roles — and every agent accumulates a track record scoped to your project.

That record becomes a composite performance score from 0 to 100, built from five weighted components:

• Success rate — 35%. Did the task complete and produce a mergeable result? A partial success counts as a half.
• Satisfaction — 22%. Your thumbs up or thumbs down on the outcome.
• Efficiency — 18%. How this agent's run duration compares to peer agents on the same category of task. Faster than peers scores above the neutral 50; slower scores below it.
• Recency — 15%. Exponential decay on a 30-day half-life.
• Override decay — 10%. The one nobody else has.

Override decay is the score watching you overrule it. When the system recommends an agent and you pick a different one, that rejection is recorded and costs the agent 15 points off this component — itself decaying on a 30-day half-life, so last quarter's rejection has faded and Tuesday's has not.

Every other component asks how did the agent do. That one asks and did the human believe us. An agent that keeps getting recommended and keeps getting swapped out has a real problem, and no success-rate figure would ever surface it, because the swapped-out runs never happened.

There's a second design decision worth more than it looks: the composite is multiplied by a confidence factor derived from sample count, and confidence doesn't reach 100% until an agent has 10 recorded runs. An agent with two runs cannot post a high score. It isn't that the number is unreliable and you should mentally discount it — the number is mechanically held down until the evidence exists. Every spreadsheet anyone has ever built to track this has the opposite bug: three runs, three successes, "this agent is at 100%."

Recency deserves attention for the same reason. Models change underneath you. A prompt strategy that worked in February can quietly degrade after a model update — and an all-time average smooths that away completely. You'd be looking at a comfortable 78 while your last twenty runs were garbage.

The five are load-bearing together in a way none of them is alone. Success rate by itself rewards an agent that reliably produces something technically mergeable and useless. Efficiency by itself rewards whichever agent gives up fastest. Satisfaction by itself is vibes with a number attached.

Unit two: the spend

This is the layer that's underbuilt nearly everywhere else, and it's where the argument gets teeth.

Every model call the app makes is written to a cost ledger, and every row is tagged with the sub-stage that fired it. Not "task execution" as one undifferentiated bucket — around 34 distinct sub-stages, including all the passes most tools wouldn't even count as spend: prompt refinement, architecture validation, task execution, PR review, PR improvement, documentation, level-of-effort assessment, backlog prioritization, task decomposition, complexity scoring, commit message generation, release notes, compliance scanning, failure coaching, memory extraction.

Failure coaching costs money. If you don't attribute it, it shows up as an unexplained percentage on your bill and you go looking for it in the wrong place. The point of the sub-stage tag is that when cost per task climbs, you can answer which part climbed instead of guessing.

On the outcome side, the dashboard reports cost per merged line of code — joining the cost ledger against real git statistics for the task (lines added, lines removed, files changed, commit count, merge timestamp). That's an outcome metric in the strict sense. Tokens measure effort; cost per merged line measures result.

The single most useful number on that screen is rework share: the fraction of your in-progress spend that went to retries. One figure telling you what proportion of your money is being spent doing things twice. A high rework share is almost never a model problem or an agent problem — it's a specification problem, and it stays invisible until somebody adds up the retries.

There's a forecasting layer on top. The app estimates what a task will cost before you run it, then calibrates those estimates against your actual outcomes: empirical-Bayes shrinkage, so a factor fitted from few samples shrinks back toward no-correction and a cold-start project is a strict no-op; leave-one-out backtesting before the global bias correction is trusted at all; hard caps on every coefficient so one freak run can't drag the model. It doesn't just forecast — it grades its own forecasts and adjusts. That's the difference between a cost estimate and a cost estimate you can plan against.

Unit three: the decision

Duels are where measurement stops being a dashboard and becomes an experiment.

Take one task specification and run it twice, as two arms, with different configurations — different agent, different model, different settings. Both arms run in isolation against the same base. Then a judge scores the two resulting diffs against a versioned, weighted rubric, producing per-criterion scores rather than a thumbs up.

The judge is a model, and here is what makes it an experiment rather than a demo: the judge is blind. Its prompt contains the task spec, the rubric, and two diffs labeled arm A and arm B. It does not receive the agent names. It does not receive the model names. It cannot know which arm was the expensive one — so it structurally cannot do the thing every human reviewer does, which is decide the frontier model won before reading the code.

Results feed Elo ratings per agent, both project-scoped and global, updated from head-to-head outcomes, with per-arm cost attached so you can see what a win cost you. Draws are recorded honestly as draws. Over time you stop asking "does this agent feel good" and start asking "what is its record against the field, on my repository."

The structural answer to 2,500 pull requests

Nobody read them all. Verification is structural.

Work moves through five Kanban stages — to do → in progress → in review → document → done — and the stages aren't decoration. Each one fires a default command:

• In progress runs prompt refinement, then architecture validation, then execution.
• In review runs a PR review pass, then an improvement pass against that review.
• Document runs a documentation pass.

Nothing reaches done without transiting that sequence, and the review and improve passes are deliberately separate passes rather than one. The reviewer is forbidden from implementing its own fixes — it checks the diff against a written standards document and its job ends when the findings are posted. A different pass picks those findings up and acts on them. That separation is the point: a finding has to survive being written down and handed off, rather than being quietly patched by the same context that noticed it. Compliance scanning is its own pass again, with its own line in the cost ledger.

The human sits at the top of that pipeline rather than in the middle of it, which is precisely what a functioning engineering organization does with a director. You don't read every diff. You build a system that surfaces the diffs that need you.

And you can check whether the system works, because the repository has a floor: CI enforces coverage thresholds of 93% statements, 94% lines, 88% branches, and 90% functions across roughly 1,600 test files. 2,500 pull requests through a gate like that is a different claim from 2,500 pull requests.

What a score is actually for

A composite score doesn't make decisions. If your database designer agent sits at 41 while your backend developer sits at 88, that does not mean the database agent is bad. It means go look. Maybe the tasks routed to it were underspecified. Maybe your schema conventions aren't written anywhere it can find them. Maybe it's genuinely the wrong agent for your stack. Maybe its confidence is 60% because it only has six runs.

You wouldn't have known to look. That's the whole value. Measurement doesn't answer the question — it tells you where the questions are.

Optimize: Change the System, Not the Vibes

Optimization without measurement is superstition. "It seems to work better when I phrase it this way." Maybe it does. You have no idea.

With the data in hand, five moves become available.

1. Route models per sub-stage — and understand why the obvious win is opt-in. Because every stage is separately instrumented, every stage can separately be assigned a model. The defaults already do this: the documentation pass runs on Haiku, because writing docs does not need a frontier model. And the In-Progress Efficiency panel offers a one-click, per-project, reversible action that down-tiers the two planning sub-stages — prompt refinement and architecture validation — to Haiku as well.

That sounds like free money, and the codebase explicitly refuses to make it the default. The reasoning is written into the source: down-tiering prompt refinement trades plan quality for drafting cost, and a weaker plan can raise downstream execution cost by more than it saved upstream.

The optimization can lose money. There is no way to know which way it goes for your repository without running it and reading the numbers — which is this entire article compressed into one product decision. Ship the lever, refuse to pull it for you, provide the instrument. A "save 40%" button would be a lie in some fraction of cases, and nobody would ever find out which.

2. Route work by record, not intuition. Once you can see which agents perform on which categories of task in your repository — and once duels give you head-to-head Elo rather than self-reported success rates — assignment stops being a guess. This is the cheapest available win, and most developers never get it because they never had the data.

3. Make context explicit instead of rediscovered. This is the cost story nobody warns you about. When a codebase is small, prompts are cheap — there's little to read. As the repository grows, every prompt re-triggers the same expensive discovery: the agent goes hunting for the same architectural facts, again. Cost per task climbs while task difficulty stays flat.

That's a context problem, not a model problem, and it has two fixes that both shipped:

• A prompt-cache boundary. The context pack assembled for a run is deliberately partitioned. Sections that don't vary between runs for a given project — your conventions file, your cross-repository documentation — go above a frozen marker; sections that vary per run — retrieved chunks, learnings, the repo tree, the task body — go below it. The invariant half becomes a cached prefix the provider bills at a fraction of the rate, and the cache-read tokens land in the ledger where you can watch it work. The classification is the load-bearing decision and it's counterintuitive in places: the retrieved-rules block looks invariant and isn't, because chunks are selected by similarity against the task body.
• A shared context ledger. Agents in isolated worktrees are each a fresh mind, and by default each re-derives what the last wave already established. The ledger is a small typed database stored at the shared git directory, so every worktree reads the same one. An agent's first action is a warm-start read: here's the pinned base commit, here's what was already decided about the files you own, here's who currently owns what. Discovery happens once instead of twenty times — and it shows up directly in your efficiency numbers, so you can confirm it worked instead of assuming.

4. Fix the input, not just the agent. Task intelligence — decomposition with tracked dependencies, plus a complexity scoring pass that gets its own ledger line — is optimization at the front of the pipeline. A poorly scoped task produces a poor result regardless of which agent gets it, and burns the same money doing it. When success rate craters on a specific class of task, the cause is usually upstream of the agent.

5. Buy yourself disagreement. Multi-Agent Debate applies the loop to decisions rather than code: for an architectural choice, multiple specialized agents each propose an approach, critique the others, and a moderator synthesizes a consensus — which is then written to a markdown file and committed to your repository.

That last detail isn't incidental. The output is a decision record, which means the next agent to touch that subsystem can read why the call was made. Optimization that gets written down compounds. Optimization that lives in your head evaporates.

And disagreement is the real deficit of working alone — more than headcount. When you work solo, nobody tells you the idea is wrong before you've spent four days on it.

Why the Loop Beats the Funding

Here's the thesis, stated plainly: a funded company runs the same loop, but their cycle time is measured in quarters and yours is measured in afternoons.

They measure too. Their measurement arrives in a quarterly review. Their optimization requires cross-team alignment, a migration plan, and someone's sign-off. Every person added makes that slower, because coordination cost grows faster than headcount.

You open the efficiency panel, see that architecture validation is eating 19% of your in-progress spend, down-tier it on one project, run five tasks, read the delta, and keep it or revert it — before lunch. No meeting, no consensus, no migration plan.

You are strictly worse on raw capacity and strictly better on iteration speed. Iteration speed compounds.

Where this doesn't apply

We'd rather be accurate than triumphant, so: fifty engineers give you things no loop replaces. An enterprise sales motion. Support at scale. Ten years of accumulated domain knowledge. Regulatory and compliance depth. The ability to survive one person getting the flu.

And the loop makes you faster at building whatever you already decided to build. If you decided wrong, you now reach the wrong destination in a third of the time. Velocity is not direction.

Start at Two, Not Twenty

The most common failure is starting at the headline number. Don't.

Start with two agents. One teaches you nothing about orchestration. Twenty teaches you everything simultaneously, at maximum volume, while you're on fire. Two makes the coordination problems visible while they're still cheap to fix.

This is what that concurrency dial is for. Twenty is what the architecture supports once your process deserves it, which is why it isn't the shipping default.

Then measure before you scale further:

• Let the stage pipeline run. Don't disable the review and improve passes to save money before you know what they're catching.
• Get an agent past 10 runs so its score carries full confidence and means something.
• Watch your rework share for a week.

Only then add agents — because now each one inherits a system that works instead of amplifying one that doesn't.

The order is a dependency chain, not a slogan. You can't optimize what you haven't measured, and there's nothing worth measuring until you've scaled past what fits in your head. Each step earns the next.

The Window

The reason this advantage exists at all is that the tooling is lopsided. Enormous investment is going into step one — every vendor alive wants to sell you more agent throughput. Almost nothing is going into step two.

That asymmetry is temporary, and it cuts both ways. Closing the loop is an advantage available right now to anyone willing to do it, and it's one that gets competed away as the category matures. The developers who build measurement discipline now will keep it. The ones waiting for the tools to get easier will start from zero against people with two years of data.

Scale quickly. Measure honestly. Optimize on the evidence.

---

Prefer to watch or listen? The same loop, condensed into a narrated explainer: Episode 003: Scale, Measure, Optimize.