Estimating agent work in agent time.

The agent prices work at human speed, not tokens-per-second. I keep its estimate and translate it into agent labor and wall-clock using my own traces.

One trail. Several honest ways to describe the distance.

Sometimes, after an in-depth planning session, I ask the agent to estimate the work. The answer sounds like a traditional software estimate: “roughly 75 to 130 hours.”

As a schedule, that number is wildly off, and the reason is simple. The agent is pricing the work at human reading, thinking, and typing speed, not at its own tokens-per-second. So it never answers the question I actually have: How much time should I set aside for the agent run?

I do not want to replace the agent's estimate. Decomposing the request into familiar human hours is useful work. I want to translate that estimate into agent time, using my own traces. The forward skill does the conversion with a confidence cone; the look-back writes the ledger that conversion reads.

The central conversion

Keep the estimate. Change the units.

What the agent gives youHuman-equivalent effort

Work size for one experienced person working alone. Keep the agent's own breakdown, range, assumptions and dependencies.

÷ 43.8

Your own overall multiplier — human-equivalent hours per attended agent hour (mine labels the attended denominator as assumed).

What the work costsAgent labor

The sum of every worker's time. Four agents running for 15 minutes is about one hour of agent labor.

→ critical path

Dependencies, real parallelism and the serial gates you cannot skip.

What you actually waitAttended wall-clock

Elapsed time from dispatch to a verified stopping point, including serial integration.

Paying it forward

Take the skills—and the coefficients.

Todd shared the seed in public, so I want to do the same with my fork. These are the complete, portable Markdown skills I currently use—not abbreviated prompts or screenshots. Estimation carries work-type rates and the 43.8× overall multiplier; look-back carries the 60/35/22/14/10 lines-per-hour tiers and the separate 120-lines-per-hour cleanup rate. Both include formulas, guardrails and output templates. Copy one into a SKILL.md file wherever your agent loads skills, then replace my starting coefficients as your own actuals accumulate.

Before the work

Forward estimation

Produce a conventional estimate first so it stays unanchored.
Classify items by work type.
Read measured rates (countable medians and coverage).
Project agent wall-clock with a confidence cone.
Fall back to look-back tiers when the countable basis is thin.
Cite n and the rate used — not a lone confident number.

Download Markdown

After the work

Look-back accounting

Inspect the completed git range.
Exclude generated and vendored material.
Classify insertions by file complexity.
Keep deletion-only cleanup separate.
Label wall-clock measured, reconstructed, or assumed.
Append an anonymized row to the private ledger.

Download Markdown

Current personal coefficients

43.8×

Overall human-equivalent hours per attended agent hour, from 243 anonymized work-item rows (2026-06-17 through 2026-07-14; v2.1-countable-medians). Attended denominator: assumed.

T1TrivialConfiguration and boilerplate60 lines/hr
T2RoutineTests, documentation, simple UI and scripts35 lines/hr
T3MediumBusiness logic, data access and integrations22 lines/hr
T4HighArchitecture, migrations and state machines14 lines/hr
T5SpecialistParsers, systems, cryptography and GPU work10 lines/hr
ΔCleanupDeletion-only credit, kept separate120 lines/hr

I think agents are about 40× faster in my workflow. That coefficient still isn't “the speed of agents.”

They stream around 50 tokens per second of thought and code. They can think and type at that rate. I can't. They also work in parallel: I usually spin up 2 to 4 at once.

Planning is the other difference. The back-and-forth between me and the agent is usually about 25% to 50% of wall-clock. When there's more agent effort, planning is a smaller share of the clock. On larger work, less of the wall-clock is planning. With about 2 hours of planning I can usually execute the equivalent of about 80 hours (or more) of human time.

I round the belief to about 40×. The measured conversion here is 43.8× under its assumptions, not a universal speed claim. Your number will probably be different. Workflows, project types, models, tools, verification gates, and attendance assumptions all change the calibration. Judge thin basis on countable coverage, not raw row count, and treat the overall multiplier as one global constant until worker durations are attributed per item.

In a future post I plan to share the trace-harvesting repository behind this experiment so you can collect the same kind of evidence from your own sessions and derive coefficients for your own work.

Good enough to prioritize

From 64 hours to 1.5 was the useful result.

Agent estimate: 75–130 human hours
Estimate from forward-estimation skill: ≈64 human-equivalent hours≈1.5 total agent-labor hours
Estimate from look-back skill: 59.7 human-equivalent hours
Wall-clock time: ≈7 minutesObserved with the Grok 4.5 harness

The human-equivalent work estimate held up: about 64 hours going in versus 59.7 in the look-back.

Neither the original agent estimate nor my conversion assumed parallel execution. The ≈1.5-hour result is total agent labor, not a parallel wall-clock forecast.

The observed run used Grok 4.5. In my measurements, its prefill and decode speeds were at least 50% faster than the Codex and Claude API routes behind my coefficient, and the harness also ran work in parallel. Those unmodeled advantages help explain the ≈7-minute wall-clock.

I don't need to model every variable. The conversion already tells me what matters: work the agent sized at 64 human hours is about 1.5 hours of actual agent work. Good enough to kick it off and go walk my dog.

Credit before conclusions

The look-back idea did not originate with me.

This work was seeded by Todd Saunders’s public /cost-estimate prompt: lines of code plus complexity translated into senior-developer hours. I used it publicly on March 5, 2026 with both hours and dollar return-on-investment framing.

My current fork retires the dollar layer, keeps hours-only look-back accounting, separates agent labor from attended wall-clock, and calibrates a forward forecast against my own session ledger. The adaptation (and any mistakes in it) is mine.