The pitch for agentic development usually arrives as a multiplier. Ten times the output. Half the headcount. A feature shipped over lunch. The numbers are real enough in a demo, and they are the wrong numbers to budget against. Agentic development does not delete the cost of building software. It moves it to places your current org chart does not have line items for.
If you are a decision-maker trying to decide whether this is worth the investment, the useful question is not "how much faster is it." It is "where does the cost go, and am I set up to pay it there."
What actually gets cheaper
Two things genuinely drop, and they are worth being precise about.
The first is the cost of producing a unit of plausible code. An agent will draft a component, a migration, a test file, or a refactor in a fraction of the time a person spends typing it. For well-specified, well-bounded work, this is real and it compounds. The second is the cost of parallelism. A traditional team of three works on three things. A fleet of role-specific agents can have a dozen issues in flight at once, each in its own branch, without the coordination overhead a dozen humans would incur.
Those two savings are where the multiplier stories come from. They are real. They are also only half the ledger.
Where the cost actually goes
The cost does not vanish. It relocates to four places.
Specification. An agent is only as good as the brief it is handed. Vague issues produce confident, wrong PRs. The work of turning "make the dashboard better" into an acceptance-criteria list an agent can execute against does not disappear. It moves upstream, onto whoever writes the issues, and it becomes the bottleneck. Teams that adopt agents successfully spend more time writing specs, not less.
Review. Agents are fast and confident, which is the dangerous combination. Every PR still needs a human to decide whether it is correct, and more importantly whether it is the right change. The review load goes up, because the volume of diffs goes up. The skill that matters is not reading code line by line, it is smelling when a diff passes CI but is architecturally wrong. That skill is scarce, and it does not scale by adding junior reviewers.
Failure recovery. When an agent ships something subtly broken, it will keep building on top of the broken thing with total conviction. The cleanup is more expensive than the equivalent human bug, because the mistake has had time to propagate and because nobody felt the friction that usually flags a bad direction early. You pay this cost in incident time and in the prompt-and-guardrail changes that stop the failure from recurring.
Operating the system itself. The agent fleet is software you now maintain. Prompts drift as the project evolves. Guardrails need tuning. The orchestration needs babysitting the first few weeks. This is a standing operational cost, not a one-time setup fee, and it is the one most adoption plans forget entirely.
The throughput trap
Here is the failure mode I see most often. A team adopts agents, output explodes, and everyone celebrates the throughput. Three months later the codebase is larger, the architecture is muddier, and nobody can confidently explain how a given feature works, because no single human ever held it in their head.
The trap is treating throughput as the goal. Throughput is an input. The goal is shippable, maintainable software, and that is gated by review and specification capacity, not by typing speed. If you uncork the typing bottleneck without expanding the review and spec capacity behind it, you do not get more good software. You get more software, of unknown quality, faster. That is usually worse.
The mental model that keeps you out of the trap is the contracting agency, not the magic factory. If you hired ten contractors tomorrow, you would not expect ten times the output, because you would immediately become the bottleneck on briefs and reviews. Agents are the same. They are cheap contractors who type quickly and never push back on a bad brief. The supervisory layer is what converts their speed into value, and it is the part you have to staff.
For a fuller picture of what that supervisory role looks like day to day, see What an agentic developer actually does.
A more honest budget
If you are pricing this out, budget for the move, not the multiplier:
- Less time spent typing code and coordinating parallel work.
- More time spent writing specifications and acceptance criteria.
- More time spent reviewing a higher volume of smaller diffs.
- A standing line item for operating and tuning the agent system.
- A reserve for the more expensive class of failures agents introduce.
Net, the good teams come out ahead. The savings on production and parallelism genuinely exceed the new costs, often by a comfortable margin. But the margin only exists if you actually fund the new costs. The teams that skip the supervisory layer to bank the full multiplier are the ones that quietly abandon agentic development six months later and conclude it does not work.
The bottom line
Agentic development is worth it when you treat it as a shift in where engineering effort goes, not a discount on engineering effort overall. You will spend less on typing and more on judgment: what to build, whether it was built right, and how to keep the system honest as it grows. If your organisation is set up to invest in judgment, the economics are good. If it is only set up to count lines shipped, you will be disappointed, and the disappointment will not be the technology's fault.
If you are trying to figure out where the costs land for your specific situation, get in touch. The honest version of the ROI conversation is worth having before you commit a quarter to it.