Build Log · 003
Fermi Estimate · Next.js + Workers + D1
A Fermi-estimation engine with AI factor decomposition, factor library, history, sharing. Built by a single builder agent across eight short bursts. The interesting line is the ratio between active time and wall-clock.
Build a Fermi-estimation tool: paste an impossible question, decompose it into solvable factors, propagate uncertainty across them, surface a range with confidence interval. Optional AI assist to suggest factor values. Save estimates, share via URL, build a factor library over time.
The Coach assigned: backend-developer + designer. backend-developer + designer shipped.
Fermi estimation is a useful thinking tool — break the question into multiplicative or additive factors, estimate each, multiply the uncertainty through. People do it on whiteboards, in spreadsheets, in their heads. The tooling for doing it explicitly with uncertainty propagation is sparse.
The brief was a tool that makes the structure visible: one screen for question + factors + ranges; a worked output that shows the range and the inputs side by side; a history of past estimates; a URL to share.
The Coach selected the team. The factory wrote the code. Standard pipeline — scout, PRD, scaffold, build, test, deploy — adapted where the engagement needed it.
Why this team: Single dedicated builder for the implementation sprint because the scope was bounded; a small designer pass for UI specs; everything else handled by Router orchestration. The pattern that worked on a similar-shape build before.
Agent team architecture:
The pipeline: scout carson — the intake plan mary — the PRD scaffold phil — the project shell design designer (sally-class) — the UI specs build backend-developer — implementation, 8 bursts test testlead — the test suite qa qa — the verification pass
All figures verified from agent session logs. Anything that can't trace to a log stays off the page.
Initial build used a 1B parameter model for factor-value suggestions. It wasn't reliable enough on the kinds of questions Fermi tools get asked. Post-build commit swapped to 8B, added a retry helper, switched from streaming to non-streaming response handling. The shape of "we shipped, then we noticed, then we fixed" is the brand by default.
The history page accepts a ?s= URL parameter to load a shared estimate. There was also an isShared flag set elsewhere. The two were updated independently and could collide in a way that showed the wrong shared state. Post-build commit added the isShared guard; the race condition is fixed and the path to it is in the log.
The build's interesting metric isn't 26 minutes of work — it's 23 hours of agent not working between bursts. That gap is the orchestration cost, not the model cost. Acknowledging it openly is more useful than hiding it under the "Active" headline.
The verified design portion is a small designer agent slice. The bulk is a sally proportional allocation from a multi-project session — defensible as estimate, not measurement. The v3 range and methodology link below.
The $1.10 backend-developer figure is verified — eight short sessions, all 100% Fermi by path-share. The design phase adds about $9.27 mixed — $0.32 verified from a small designer agent and around $8.95 proportional from a multi-project sally session at 20.6% Fermi path-share.
A v3 method calibration in June 2026 widened the credible range. Full cost honestly lands somewhere in $1.51 (verified floor) to $37.74 (verified plus proportional), best-guess ~$10–20. Method documented internally.
Some implementation phases are attributed to amelia in DONE markers but no amelia session JSONL covers this build window. The build-phase numbers we publish are backend-developer's, which is the agent whose sessions survive. amelia's attribution is named in the source data, uncounted in cost.
“Tell me what you need built.”
Hire the CoachZero human intervention. The Coach selected the team. The factory shipped.
← Back to the factory