Logbook · Economics

What agentic development changes about cost and timelines — and what it doesn’t

Agentic development genuinely changed what software costs and how long it takes. It also left several costs completely untouched — and the gap between those two lists is where inflated claims live. A buyer’s guide to which is which.

Muhammad Hammad · 31 Aug 2026 · 7 min read

Short answer

Agentic development collapsed the cost of producing code and narrowed estimate variance, which is why fixed quotes and week-long timelines became normal. It did not touch the cost of deciding what to build, understanding your domain, reviewing correctness, or being wrong — so well-defined projects got much cheaper and vague ones barely did.

There is a lot of noise in this area, in both directions — claims that software is now nearly free, and claims that nothing has really changed. Both are wrong, and the useful version is specific: agentic development collapsed the cost of producing code, and left the cost of deciding what to build almost exactly where it was.

If you are buying software, the practical value is in knowing which of your costs sit on which side of that line. This is the buyer's view; if you want the mechanics of how the work actually runs — the pipeline, fan-out, verifier separation — that is a separate piece.

What genuinely changed

Production got much cheaper

Scaffolding, boilerplate, test suites, first drafts of a component, migrations, the fourth CRUD screen that resembles the first three — this was always a large fraction of the hours on a build, and it is the part agents do well under review. That is a real reduction, and it is why timelines that were quarters are now weeks for a whole class of work.

Estimates got more reliable, which is what enables fixed pricing

This one is underrated. Fixed pricing was always better for clients; it was risky for vendors because the honest spread between the good case and the bad case on a three-month build was wide, and any fixed number had to carry a risk premium the client ultimately paid.

Shorter projects are easier to estimate, and working software every week means a wrong assumption surfaces in week two rather than month three. Lower variance means a smaller premium — which is the actual mechanism behind fixed quotes becoming normal rather than exceptional.

The team shape changed

The old pyramid — a senior architect over several juniors doing volume — existed because volume needed hands. When agents do volume under review, one senior engineer covers work that needed a small team. Fewer people also means less coordination overhead, which was itself a real cost nobody itemised.

What did not change at all

This is the more useful list, because it is where inflated promises get made.

CostWhy agents don't touch it
Deciding what to buildRequires knowing your business, your users and your constraints. No model has that context, and getting it wrong is still the most expensive mistake available.
Understanding an unfamiliar domainMotorsport telemetry, clinical workflows, freight — the learning is conversational and human, and it happens before code.
Undocumented integrationsAn agent cannot read a manual that does not exist. Protocol archaeology is still archaeology.
Review and correctnessMore code produced means more code to review. This cost went up per unit of output, not down.
Being wrongBuilding the wrong thing quickly is still building the wrong thing. Speed raises the value of deciding well.
After launchMaintenance, OS upgrades, support — entirely unchanged.

The honest arithmetic

If production was, say, half of a traditional project's cost, and that half is now substantially cheaper, the total falls meaningfully — but nowhere near to zero, because the other half did not move. That is why our numbers look like $4,500 rather than $45,000, and not $450. Anyone quoting the third number is either not doing the review, or not doing the thinking.

It also explains an asymmetry worth knowing when you compare quotes: well-defined projects got much cheaper; ill-defined ones barely did. If your requirements are clear, you capture the full benefit. If nobody knows what the product should do yet, most of your cost is still discovery, and a very large discount there should make you suspicious rather than pleased.

What this means for how you buy

On quality, since it is the obvious worry

Agent-written code is as good as the review around it. Unreviewed, it accumulates the same kinds of problems unreviewed junior code always did — plausible-looking work that is subtly wrong. The difference is volume: it arrives faster, so the review discipline has to be stronger, not weaker.

Which is why the useful vendor question is about process rather than tooling. Every project should ship with tests, and a human should be able to explain any part of the system you point at. If nobody can, it does not matter who or what wrote it.

The short version: producing code got much cheaper; deciding what to build did not, and neither did review, undocumented integrations, or being wrong. Well-defined projects captured most of the saving. Ask who reviews the output, expect a fixed quote and weekly working software, and put your own effort into being clear about what you want.
Want to see what that costs for your project?

Book a free 30-minute discovery call — an honest read on whether it's worth building, and a fixed quote within 48 hours if it is.

Book a free discovery call