How AI Changes Software Estimation (and What It Doesn't)

AI makes writing code cheaper, but writing code was never most of what a software project costs. Discovery, decisions, integrations, data migration, review and deployment still take human time, and review gets bigger, not smaller. An honest AI-assisted estimate prices those phases separately instead of applying one AI discount to the whole project.

A founder sends me a quote. Somewhere in it, or in the sales call that came with it, is the line: "We use AI, so we can build this faster and cheaper." Often there's a second quote from a team that doesn't say that, and it's higher.

I build production software with AI coding agents every day, so I'm not skeptical of the claim. AI really does change what software costs to build. It just doesn't change it evenly, and the estimates that go wrong are the ones that assume it does.

Does AI make software cheaper to build?

Some of it, yes. The part it makes cheaper is the typing. Turning a clear decision into working code is far quicker than it used to be. Scaffolding a new app, building a CRUD screen (the create, read, update and delete forms behind most business apps), drafting tests, renaming something across a whole codebase: that kind of work now goes fast.

Now think about where the money in a software project went before AI. Very little paid for typing. It paid for working out what to build, waiting on decisions, connecting to other people's systems, moving old data, fixing what testing found, getting the thing deployed, and the long last stretch where a demo becomes a product.

AI compresses the first of those hard and barely touches the rest. So the honest answer to "does AI make software cheaper?" is: it makes the cheapest part cheaper. How much that moves your total depends on how much of your project was that part.

What gets cheaper when your developers use AI?

The work that gets cheaper has two things in common: it's well defined, and a person can check it quickly.

That saving is real, and a vendor who uses AI well should be passing some of it on.

What doesn't AI make cheaper?

Everything that depends on people, other companies' systems or decisions. These lines take about as long as they always did:

• Discovery. Working out what the business actually needs. AI can't sit in the meeting where finance and operations disagree about what "approved" means.
• Decisions. Architecture, trade-offs, what to build and what to leave out. That's judgment, and judgment runs on calendar time.
• Integrations with other people's systems. Third-party APIs with thin documentation, sandbox accounts that take a week to approve, a vendor whose support replies on Thursdays. AI also invents API endpoints and options that don't exist, so integration code needs testing against the real service.
• Data migration. Old data is messy in ways nobody wrote down. Someone has to look at it, decide what's wrong with it and decide what to do about it.
• Your time. Feedback, content, approvals, sign-off. Your side of the project doesn't speed up because the developer's side did.
• Deployment and operations. Environments, domains, secrets, backups, monitoring.
• Coordination. Every extra person adds handoffs, and AI doesn't remove them.
• The last 20%. Edge cases, error states, performance, the polish that turns a demo into a product. I wrote about why that stretch stalls in Why Your AI Project Is Stuck at 80%. AI gets you to the demo sooner. It doesn't shrink the gap after it.

If most of your project lives in this list, AI will move your total less than the pitch suggests. An integration-heavy build with a messy data migration is mostly this list.

What gets more expensive when AI writes the code?

This is the part almost nobody puts in a quote.

1. Review capacity. When code arrives faster, someone has to read more of it. If a team generates code faster than a reviewer can read it carefully, either review time grows or review quality falls. There's no third option. I've covered where the human checkpoints belong in Human in the Loop: Why AI Still Needs Human Oversight.
2. Verification. AI-written tests tend to confirm the AI's own understanding. If it misread the requirement, its tests pass anyway. Someone skilled has to check the tests against what the business actually asked for.
3. Security. AI suggests packages that may not exist, repeats insecure patterns that look perfectly normal, and has no idea which of your data is sensitive. Security review now covers more code, written faster.
4. Code nobody fully read. This is the long-term cost. Code that shipped without anyone understanding it is expensive to change, because the first person to touch it has to learn it from scratch, usually under pressure, often during an outage. That bill arrives in maintenance, long after the estimate is forgotten.

None of this is a reason to avoid AI. It's a reason to see these lines in the estimate, with time and a name next to each.

How do you estimate an AI-assisted project?

1. Estimate by phase and risk, not by lines of code. Break the project into phases: discovery, design, build, integrations, data migration, testing, security review, deployment, launch support. Mark the risk in each. Then ask how much AI changes each one. Usually the build phase changes a lot and the rest change a little.

2. Separate "generate" from "verify". For each feature, think in two numbers: the time to produce it and the time to confirm it's right. AI shrinks the first. The second is human time, and on anything security-sensitive (logins, payments, permissions, anything that deletes data) it can be the bigger number.

3. Budget review as its own line. Who reviews the code, and how much time do they have? If nobody on the team is senior enough to review AI output, that's a staffing gap, not a saving.

4. Never apply one AI discount to the whole project. "This would normally cost X, but with AI it's Y" across the board is the red flag. Discovery doesn't get a discount. Neither does your feedback loop, the data migration or a third-party API that's down for maintenance.

In practice it looks like this:

Everything else a credible estimate needs still applies: assumptions, exclusions, contingency, a definition of done. I've laid those out in How to Evaluate a Software Development Estimate. AI changes the numbers inside some of the lines. It doesn't change what a trustworthy estimate has to contain.

What should you ask a vendor who says AI makes it faster or cheaper?

1. "Which phases does AI speed up, and which doesn't it?" A good answer names build work, tests and documentation, and admits that discovery, integrations and migration aren't much faster.
2. "Who reviews the AI-generated code, and how much time is budgeted for it?" You want a name and a line item.
3. "Who writes the tests, and who checks them?" Tests from the same AI that wrote the code are a start, not proof.
4. "What security review happens before each release?" "We're careful" is not a process.
5. "If your lead developer left, could someone explain this code?" If nobody fully understands what's being delivered, you're inheriting a maintenance bill.
6. "Is the AI saving coming to me, or to your margin?" Either answer can be fair. You should still know which one it is.

Vague answers don't prove a vendor is bad. But a vendor who can't explain where AI helps and where it doesn't probably hasn't thought about where it hurts.

How I estimate my own AI-assisted work

I work with ten specialized AI agents, each with a defined role: principal engineer, technical PM, front-end and UI, security, DevOps, QA, SEO, messaging, content and database. The repetitive technical work runs through them: scaffolding, checklist reviews, documentation, regression sweeps. Architecture, trade-offs, and what to build or refuse stay with me. Every release runs a security checklist before it ships. The full setup is on the AIwhirks process page.

When I estimate, the agents change the build lines. They don't change the discovery, decision, migration or review lines, so I don't discount those. The wider picture, from building it yourself to hiring a studio, is in The Founder's Guide to AI-Augmented Development.

That's how TowerSight, a multi-tenant SaaS, was designed, built, migrated and shipped by one engineer, live in under four months. It's also how Blazin Safety's platform went from zero automated tests to 103, with ten of thirteen gated phases complete. Neither shows AI doing the job alone. Both show that AI under engineering discipline ships real systems, and that the discipline is the part you're paying for.

Get the estimate checked before you sign

If you're holding a quote that leans on AI and you can't tell whether the savings are real, get a second opinion from someone who isn't bidding on the work.

This is exactly what a Technical Assessment covers: I read the estimate against the scope, separate the lines AI genuinely changes from the ones it doesn't, check who is reviewing what, and tell you in writing whether the number holds up and where it's likely to move.

FAQ

Related Reading

• How to Evaluate a Software Development Estimate (Before You Sign): What a credible estimate contains, with or without AI, and the red flags to push back on.

• Human in the Loop: Why AI Still Needs Human Oversight: Where the human review belongs, and why it's the line most AI estimates leave out.

• Why Your AI Project Is Stuck at 80% (And How to Actually Ship It): The last stretch AI doesn't shorten, and how to plan for it.

If a vendor has told you AI cuts your project cost and you can't see where the savings come from, ask before you sign. Get in touch if you want a second set of eyes on the estimate.