A refactor of an existing Markdown-review app produced a candidate that passed extensive checks, but it did not prove that AI agents made the work faster or cheaper. In Aashish Bhandari’s case study, a principal agent led implementation with delegated workers, an independent agent reviewed the designs and code, and a human set priorities and approved checkpoints. The measurements offer a useful project-level baseline—with important limits on what the token counts and test results can show.
What was refactored
ReviewWithAI was already an alpha application, not a product generated from scratch. It lets users select text in Markdown documents, attach comments, hand work to an external coding agent, check changed anchors, record repairs, and accept a specific source revision.
As an Amazon Associate I earn from qualifying purchases.
The refactor addressed the product’s server and browser structure, authorization, persistence, tests, operational diagnostics, documentation, and release tooling. Bhandari describes Goku as the principal architect and implementing agent, Naruto as an independent design and code reviewer, and himself as the person setting priorities, resolving material decisions, and authorizing review checkpoints.
Eleven designs, three checkpoints
The work comprised eleven low-level designs addressing twelve review findings; Q3 and Q4 were combined in one design. The designs were handled in three review checkpoints: engineering housekeeping and controls; a first implementation group; and the remaining implementation and release candidate.
#1 Best Overall
Among the reported changes were typed handlers and a more modular browser application; clearer transaction ownership and rollback behavior; redacted diagnostics; stricter inputs for agents; bounded document discovery; handoff provenance; contributor documentation; and release curation.
What the candidate checks establish
Bhandari reports that the candidate passed independent checks, including tests, browser workflows, and reproduction of its package. The case study lists 100/100 TAP tests and 73/73 browser checks, along with other candidate-level evidence. Those results establish a reviewed engineering outcome; they do not establish production readiness or prove that the process was efficient.
A passing test suite is evidence about the checks that were run—not proof that every defect was found, that the application was safe to deploy, or that another workflow would have delivered the same quality with less work. The case study makes no production-readiness claim.
How to read the token figures
For the measured implementation task, the report covers the parent agent, sixteen delegated worker threads, and approval-review components. It records 1,505 activations and 158,137,319 processed tokens for those measured components. Cached input is included in the processed-token total.
Rank #3
These are session-accounting figures, not counts of unique code or text, energy consumption, quota use, or an itemized subscription bill. The measurement excluded the human developer’s time and Naruto’s separate review sessions. The collector also omitted some compaction activity, and routine counters did not explicitly capture some terminal failure information. Approval reviewers used resources separately, while the evaluation session’s total could not be cleanly isolated from other work.
The 28.49% figure is not a waste estimate
Bhandari reports that parent activations that issued waits were associated with 10,281,999 processed tokens, or 28.49% of the parent’s canonical tokens. That is the token share associated with activations that issued a wait—not a measurement of the marginal cost of waiting. Some waits returned completed work, and the report does not show what those activations would have cost without waiting. As Bhandari puts it: “Some waits returned completed work, so that share cannot simply be called waste or promised as recoverable savings.”
It would therefore be inaccurate to call 28.49% “wasted tokens,” or to say that another orchestration strategy could reclaim that amount. The figure identifies a part of this task’s recorded activity for further evaluation; it does not establish an efficiency gain.
Worker reuse is an open question
The report says worker consumption was concentrated in four reused threads. Reusing a worker may preserve useful context, but the data do not establish whether that continuity improved correctness or whether fresh workers could have maintained quality with less effort. There was no controlled comparison between reused and fresh workers.
Rate equivalents are not charges
The case study also calculates analytical price equivalents using model rates frozen to 15 September 2026. They are estimates based on recorded token categories, not measured charges or current price guidance. Most recorded input was cached, and the report does not show that switching to cheaper model rates reduced the total work involved.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What would show whether an agent workflow is efficient?
A useful comparison needs more than a token total or a successful candidate. This case study has no matched alternative run, so it cannot rank its orchestration choices or demonstrate equal-quality savings. A follow-up evaluation would need to compare complete runs and report:
- Accepted quality: what was accepted and whether the compared outcomes met the same quality bar.
- Rework and recovery: what failed, how much repair was needed, and whether the workflow recovered successfully.
- Human effort: time spent directing agents, reviewing output, resolving decisions, and intervening.
- Elapsed time: how long each run took, not just how many activations or tokens it recorded.
- Resource accounting: model use and token categories, including cached and uncached input, alongside review and orchestration overhead.
- Worker strategy: continuity with reused workers versus fresh workers, tested without assuming either is more efficient.
Bhandari identifies deterministic counters, evaluation budgets, and controlled comparisons that include accepted quality, recovery, and human effort as useful next steps. These measures would make a later efficiency claim more meaningful than token totals alone.
Free tools Windows power users keep installed
One-click scans. No signup required.
What this case study says—and does not say—about AI coding agents
The project shows a substantial refactor in which a principal agent and delegated workers implemented changes under human direction, with an independent agent reviewing the designs and code. It also reports a candidate that passed a broad set of checks. That is useful evidence of a reviewed result in one product task.
It is not evidence that AI coding agents are generally efficient, that waits account for a comparable token share in other projects, or that a different agent setup would have achieved the same result for less effort. The measured task lacked a matched alternative, excluded some human and review effort, and did not isolate all activity. Its strongest contribution is a concrete baseline—and a clear reminder that engineering outcome and process efficiency are separate questions.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
