Are AI Coding Tools Worth It? One Repository, Audited

Are ai coding tools worth it: for producing artifacts, unambiguously yes, and the margin is large enough that it stops being interesting. The question that decides a purchase is what the artifacts were for and what they cost, and both sides of that ratio are measurable. We measured them against this site's own repository — 33 calendar days of agent-written work, audited on 2026-08-25 with a script that ships in the repo it audits.

npm run check:worth classifies every tracked file by who it is for, then looks for a record of what any of it cost:

npm run check:worth
# → 405 tracked files, 7281 kB, 73 articles, 183,788 article words
# → 49 commits over 33 calendar days (2026-07-22 to 2026-08-24)
# → 155 of 405 files (38%) exist so the other 240 could be made
# → 0 of 5 delivery mechanisms exist
# → 0 cost records on disk

Key takeaways

• Throughput is real and large. 183,788 article words in 33 calendar days, averaging 5,569 words and 1.5 commits per day including the days nobody worked.
• 38% of the files serve the process, not the reader. 155 of 405 tracked files are instruments, fixtures, governing documents and cover specifications that no visitor can ever receive.
• None of it has been delivered. Zero of five delivery mechanisms exist — no deploy configuration, no CI, no container — so 5.2 MB of reader-facing output is inventory rather than output.
• The denominator was never recorded. The repository carries no token count, no invoice and no hour, which makes every published return-on-investment figure for tools like these an estimate of something nobody measured.
• A negative result held. Volume did not correlate with delivery at any point in 33 days, and the one blocking task has been open the entire time.

The short answer

Buy the tool if your constraint is producing artifacts. Do not expect it to move a constraint that sits anywhere else.

This repository is close to a controlled case for that claim. One operator, one agent, one editorial pipeline, 33 days. The agent wrote the articles, the components, the data layer, the admin panel and 39 measurement scripts. Output ran at a rate no unassisted writer sustains. Over the same 33 days the project's own single blocking task — putting the site on the internet — did not move once.

Both facts are in the same git log. If you are weighing seats, the useful reading of "are ai coding tools worth it" is not whether the tool works. It is whether the thing your team is short of is the thing the tool makes more of. For a full breakdown of what the seats themselves cost, our pricing comparison covers every vendor's metering model.

What the ledger measures

The script takes three passes over the working tree, and each one is a number that a productivity claim usually leaves out.

• Volume. Every tracked file, sized on disk, over the calendar span of the git history. Rates fall out by division.
• Destination. Each file classified by who can receive it. reader is anything a browser can be sent. process is anything that exists so the reader bytes can be made. toolchain is the configuration any project of this shape carries.
• Cost. Seven paths where a spend, token or invoice record could plausibly live, checked for existence.

The classification is directory rules rather than semantic analysis, and it is deliberately generous to the reader side: assets/ counts as reader-facing in full even though it is the largest tree here, and lib/ counts in full even though parts of it only ever serve the build. Both errors push the reader share up, so 71% is a ceiling, not an estimate.

33 days of output

The volume side is not close, and pretending otherwise would waste your time.

Those are calendar days, not working days, and they include every day nobody touched the project. The corpus is 73 articles across six clusters, each with frontmatter, a table of contents, FAQ pairs that render FAQPage JSON-LD, a generated cover image and a committed script that regenerates that cover.

Who the output was for

This is the split that changes the answer, and it is the one a lines-of-code count cannot show you.

155 of 405 files exist so the other 240 could be made. By file count that is 38% of everything the agent produced. Opening the process class up:

• 146 files under scripts/ — 39 measurement scripts, 23 fixtures recording what each one measured, and 75 cover specifications, one per article.
• Three governing documents totalling 526 kB, of which roadmap.md alone is 472 kB. A single file that no reader will ever load is 27% of the process bytes.
• Two subagent definitions under .claude/.

None of that is waste. The instruments are what let this article quote a number instead of a feeling, and the workflow audit that counted them found 36 of them at the time. But it is work the tool created, it accrues maintenance, and it belongs on the cost side of the ratio rather than the output side.

Do ai coding tools help, or move the work

Both, and the second is the part worth budgeting for. The honest answer to "do ai coding tools help" from this tree is that they collapsed the cost of producing an artifact and left every other cost where it was.

Three costs did not move at all:

• Deciding what to produce. The 472 kB roadmap is the record of that decision-making, and it grew faster than the articles did.
• Verifying it. 39 instruments exist because an agent's claim needs an artifact behind it, and each one had to be written, run, and corrected when it was wrong.
• Shipping it. Unchanged, at zero, for the entire span.

That last one is the finding. When the cost of producing drops by an order of magnitude and the cost of shipping does not, the bottleneck moves to shipping immediately and stays there. Ai coding productivity gains are real and they are local, and a local gain on a non-binding constraint produces exactly what this tree shows: inventory.

The denominator nobody writes down

The delivery pass checks five ways a repository can reach a reader. All five are absent:

npm run check:worth
# → deploy configuration       absent      vercel.json
# → linked Vercel project      absent      .vercel
# → CI workflows               absent      .github/workflows
# → deploy configuration       absent      netlify.toml
# → container build            absent      Dockerfile

Then it looks for a cost record — costs.json, spend.json, usage.json, tokens.json, an invoices/ directory, or a spend fixture. There are none.

The asymmetry is the point. Every commit carries an author, a timestamp and a byte count. Not one carries a token count or a dollar figure. So for this project, and for most projects that will read this article, the question "are ai coding tools worth it" cannot be answered as a ratio at all — the numerator is instrumented to four significant figures and the denominator was never captured.

That is a fixable process gap, not a property of the tools. If you want a real answer for your own team, the cheapest possible instrument is a file that records monthly seat cost and metered spend next to the work it paid for. It costs one commit. Nobody here made it, which is why this article reports a shape instead of a number, and token efficiency is measurable per byte if you want a proxy in the meantime.

What did not work

The first measurement was bytes grouped by top-level directory, and it produced a headline that was arithmetically correct and substantively false.

By that reading, the largest thing the agent produced was assets/ — 3,454 kB across 78 files, 47% of the entire repository. Read as output, that credits the agent with 3.4 MB of authorship. It authored none of it. Those images are rendered by a script from 75 specifications totalling 330 kB, a 10:1 expansion performed by headless Chrome and sharp, and the same ten lines of CSS produce a 40 kB WebP or a 400 kB one depending on the gradient.

The correction is the reason this article leads with file counts rather than byte shares. 38% of files is a claim about how many separate things had to be written; 24% of bytes is a claim about how big they happened to be, and generated output makes the second one meaningless. The byte column is still printed, and the script's header now records that the reader share is an upper bound rather than a measurement.

When ai coding tools are worth it, and when they are not

A decision rule, from what this tree actually shows.

• Worth it when production is your binding constraint. Content sites, migrations, test scaffolding, documentation, repetitive refactors across many files. The throughput is not marginal and it arrives immediately.
• Worth it when verification can be automated. Every claim in this corpus has a script behind it because scripts are cheap to generate. That is a genuine compounding gain.
• Not worth it when your constraint is distribution, review capacity, or a decision. None of those moved here in 33 days. An agent will happily generate more of the thing that is already backing up.
• Not worth it if you will not record the spend. Without a denominator you cannot tell a good month from a bad one, and you will renew on vibes.
• Budget for the process tax. Expect roughly a third of the artifacts to serve the pipeline rather than the product, and expect to maintain them.

Common mistakes in measuring ai coding productivity

• Counting output and calling it productivity. Volume is the numerator. It is not the ratio, and this repository is 183,788 words of proof that the two can diverge completely.
• Counting generated bytes as authored bytes. Our first pass credited the agent with 3,454 kB of images expanded from 330 kB of source. Any measure that a renderer, a compiler or a lockfile can inflate will be inflated.
• Letting the classification skip files. If every file does not land in exactly one class, the split is flattering whichever class it drops. The guard here exits non-zero on an unclassified path for that reason.
• Treating generated instruments as free. 146 files under scripts/ are real maintenance that the tool created.
• Never recording spend. The single cheapest fix on this list, skipped here for 33 consecutive days.

What we are not claiming

This is one repository, one operator, one 33-day span and no control arm. There is no counterfactual for how long the same corpus would have taken by hand, and the script deliberately estimates none — a made-up baseline would put a fabricated multiplier at the centre of the article.

Nor is the reader-versus-process split a quality judgement. The process files are the reason the other articles on this site can quote measurements at all, and the workflow audit argues they are underbuilt rather than overbuilt. The claim here is narrow: they are a cost, they are large, and productivity arithmetic that omits them is wrong in a predictable direction.

The delivery figure is about this project's discipline, not about any vendor. Nothing prevented a deploy. It simply never became the next thing anyone did.

Conclusion

Buy AI coding tools if you produce artifacts for a living and your bottleneck is producing them; the throughput is not in doubt and this repository averaged 5,569 words a day for a month. Before you do, add the one file this project never wrote — a record of what the seats and the tokens cost, next to the work they paid for — because without it you will be renewing on a number you never measured. Then read what the same repository's workflow audit found about enforcement: 273 written rules, 36 instruments, and nothing at all that runs on its own.

Frequently asked questions

Muhammad Kashif

Founder and editor of Devventa, covering AI coding assistants, Next.js and the modern AI development stack.