Docs / How it works / ADE against plain sessions and a hand-built loopVIEW .MD

ADE against plain sessions and a hand-built loop

A real project had been running for weeks on an agent loop its owner built and tuned by hand: their own scripts and prompts driving Claude Code and Codex, with no ADE. It is not an earlier version of ADE. We moved the project onto ADE and set its first week beside the loop's 32-day record. Before the loop, the same project ran on plain Claude Code sessions, tasked by hand, for most of August. We set all three side by side.

On a real project

Plain sessions, a hand-built loop, and ADE.

Case study: ADE's first week. A person supervised most of day 1; after that it mostly ran on its own.

A real project ran for weeks, first on plain Claude Code sessions, then on an agent loop its owner built by hand. We moved it onto ADE and set its first week beside both. In that week ADE cleared a backlog that had been growing for over three months: 47 active cards, done in just over four days.

Plain sessions (19 days)A hand-built loop (32 days)ADE (first week)

Product work per unit of plan

↑ higher is better

about 120× more

vs the hand-built loop · about 21× vs plain sessions

product cards landed per 1% of a week's plan

Plain sessions (19 days)0.15
A hand-built loop (32 days)0.03
ADE (first week)3.2

Product work per day

↑ higher is better

about 20× more

vs the hand-built loop · about 5× vs plain sessions

product cards landed per day

Plain sessions (19 days)3.0
A hand-built loop (32 days)0.6
ADE (first week)13.6

Usage per day

↓ lower is better

about 5× less

vs the hand-built loop · about 5× vs plain sessions

of a week's plan used each day

Plain sessions (19 days)about 20%
A hand-built loop (32 days)about 23%
ADE (first week)about 4%

Time to land

↓ lower is better

about 5× faster

vs the hand-built loop · about 2× vs plain sessions

from starting a change to landing it (median)

Plain sessions (19 days)69 min
A hand-built loop (32 days)146 min
ADE (first week)31 min

Reached the product

↑ higher is better

about 10× more

vs the hand-built loop · about 1.6× vs plain sessions

of the landed work built or shipped what a user sees or runs

Plain sessions (19 days)40% (57 of 141)
A hand-built loop (32 days)6% (20 of 328)
ADE (first week)62% (101 of 163)

Shares of the week are priced with our credit-burn model, fitted to the live usage meter. Plain sessions are the same project in August, before any loop or kit, priced at today's limits. ADE's side is its first week; a person supervised most of day 1: an early record, not a benchmark.

How to read it#

  • Product work per unit of plan: higher is better. Product cards landed per 1% of a week's plan. Plain sessions looked productive per task, but most of their commits were the agents repairing their own scaffolding. The hand-built loop let that machinery take over: only 6% of its cards furthered the product. ADE landed about 3.2 product cards per 1% of the plan, around 120 times the loop and about 21 times plain sessions. And 21× flatters plain sessions. The project was already sliding: only about 1 in 10 of its commits changed the product, and the rest was agents repairing their own scaffolding. Left running, its figures would have drifted much closer to the hand-built loop's, and it certainly wouldn't have done as well the next month.
  • Product work per day: higher is better. Product cards landed a day: 3.0 for plain sessions, 0.6 for the loop, 13.6 for ADE.
  • Usage per day: lower is better. How much of a week's plan the project used each day: about a fifth for plain sessions, about a quarter for the loop, about 4% for ADE, the project's own use with the kit's own seats split out.
  • Time to land: lower is better. The median minutes from starting a change to it landing, every wait included. The loop's was 146 minutes, plain sessions' 69, ADE's 31 over 163 landings. Not counting waits for a person's approval, ADE's cards were ready to land in a median of 11 minutes. Neither baseline had an approval stop, so their start-to-landed is their ready time.
  • Reached the product: higher is better. Of the cards that landed, the share whose work furthered the product, on one rule for all three sides and counted per card: 40% of plain sessions' cards, 6% of the loop's, 62% of ADE's (101 of 163).

What the hand-built loop was#

The loop wasn't a naive setup. It was a layered system: seats under two coordinators, each with its own trunk, under an overseer and a root operator. It had a graph of the codebase's dependencies, opposite-engine adversarial review, a work store, a four-stage test suite, custom worktrees, generated briefs and handovers, safe-point self-compaction, a live pane watcher, and a guard on every step of the loop, around 1,200 of them. The ideas were good. The shape was wrong, and every gap was patched by adding more, until keeping it running took most of the effort.

The figures#

MeasureBetter whenPlain sessions (19 days)A hand-built loop (32 days)ADE (first week)How it was measured
Product work per unit of planHigher0.150.033.2Product cards (see Reached the product) per day, divided by the share of a week's plan used per day. ADE: 101 product cards over 7.4 days at about 4.2% a day.
Product work per dayHigher3.00.613.6Product cards landed per day. Plain sessions: 19 days; the hand-built loop: 32 days; ADE: 101 product cards over 7.4 days.
Usage per dayLowerabout 20%about 23%about 4%Share of a week's plan per day, priced with our credit-burn model. ADE: the project's own use over its first week (29.5 points over the meter week of 1 to 8 November), with the kit's own seats split out. The loop: 32 days. Plain sessions: the same project in August, before any loop or kit, with sessions tasked by hand.
Time to landLower69 min146 min31 minMedian minutes from a card starting to its change landing, every wait included. ADE: 163 landings over 7.4 days, not counting two reverted, several lanes at once; not counting waits for a person's approval, its cards were ready to land in a median of 11 minutes. The loop: rebuilt from its git history and run journals, rescues included; it had no approval stop and almost never waited on a person. Plain sessions: the same project in August, sessions tasked by hand, no approval stop.
Reached the productHigher40% (57 of 141)6% (20 of 328)62% (101 of 163)Cards whose landed work furthered the product (the app, the site, the rebuild, product research and specs, and release, hosting and deploy work), against all cards that landed. Fixing tests, probes, agent docs, validation, tooling and housekeeping don't count. The same rule on all three sides, counted per card. In August much of the agents' own repair work landed uncarded inside product cards: by commit, only about 1 in 10 of August's commits changed the product.

Over its first 7.4 days ADE landed 163 changes (two more were reverted), 101 of them product work, with a median of 31 minutes from start to landed, or 11 minutes to ready to land.

ADE's first week#

A person supervised most of day 1; after that ADE mostly ran on its own. The backlog was 47 active cards on the old board, and the last of them closed 4.2 days after the move began. The oldest recorded date is from late August, but the card store only began recording dates then, so some cards may be older.

How the usage figure is made#

The project's own use over its first week was 29.5 points of the meter week of 1 to 8 November, about 4.2% of a week's plan a day, with the kit's own seats split out. Every Claude Code surface on the machine reads higher, since it includes ADE's own terminal seat; the project's figure is the one we report.

What the numbers are, and are not#

Shares of the week are priced with our credit-burn model, fitted to the live usage meter. Plain sessions are the same project in August, before any loop or kit, priced at today's limits. ADE's side is its first week; a person supervised most of day 1: an early record, not a benchmark.

One week so far, with a person supervising most of day 1 only, with several lanes running at once. A longer record will replace them as it grows. The usage shares come from the credit-burn model behind our other usage pages.