The AI discount is real and smaller than expected

You know the cost of a project when it’s done. Every budget before that point is a guess, and for most digital projects that guess gets submitted before discovery, the research that tells you what the work involves, has started. Budget requests take time to prepare and move through official channels. Whatever number goes in becomes the ceiling whether or not it holds up once the team learns what the work involves.

AI has changed what people expect that number to be. Buyers arrive looking for a discount, and vendors have reason to offer one. The savings are real. They are also narrower than expected, and they arrive with costs that budgets rarely include.

The parts AI can’t shortcut

AI speeds up first drafts: code, tests, documentation, research summaries, prototypes. We’ve seen the upside firsthand. On one of our projects, a feature pushed a dev-effort estimate high enough to put it at risk of getting cut. A designer used AI to build a rough working version directly instead of waiting on a full build estimate, and that unlocked a feature that otherwise wouldn’t have shipped.

It’s a legitimate AI win. The work was limited, though, and a senior person drove it, judging the output the whole way; it says nothing about the rest of the project’s cost. A faster first draft can make a whole project look smaller, even though the parts that set the cost still take just as long.

AI is better suited to repetitive, well-known tasks: familiar code patterns, first-pass tests, low-risk interface work. It can’t shortcut user research or decisions about what the service should become. That’s where creativity and novel problem-solving live, recognizing a new situation and deciding what to do about it. AI generates from patterns it has already seen, and a new situation needs judgment beyond any pattern it holds. AI can summarize the research; a person decides what the findings mean.

Knowing which kinds of tasks AI suits is half the question. The other half is whether faster work on those tasks shows up in the project as a whole. Practitioners report that it doesn’t. In GitLab’s 2026 AI Accountability Report, a study of 1,528 software and security professionals across six countries, roughly eight in ten agreed that individual developer productivity has improved with AI while overall software delivery has not accelerated at the same pace. 85 percent agreed the bottleneck has moved from writing code to reviewing and validating it, and respondents named compliance, security scanning, releasing software, and responding to live-system problems as the places AI has helped least.

The same survey found 60 percent reporting returns above expectations. Something is working. It lands downstream of where a buyer is trying to price it, and the work it creates still has to be paid for.

Measured results point the same way. A 2025 randomized trial by METR followed 16 experienced open-source developers across 246 tasks in large, established projects where they averaged five years of prior experience, close to the conditions of most transformation and modernization work. They forecast that AI would cut their time by 24 percent. It increased completion time by 19 percent, and afterward they still estimated it had made them 20 percent faster. It’s a small study using early-2025 tools, so treat it as a caution with a shelf life. The gap between believed speed and measured speed is the part that survives.

The checking costs something too. Veracode’s 2026 GenAI Code Security Report found that roughly 44 percent of AI code generation tasks produced a known vulnerability. Models now write syntactically correct code close to 100 percent of the time, while the security pass rate has barely moved since the 2025 report, from 55 to 56 percent. Coding-specialized models and larger models scored about the same as everything else, so the gap holds regardless of which model you pick. That output needs a person reviewing it, especially anywhere it touches personal data or payment flows.

Faster code and faster delivery are different things. Budgeting as if they were the same will be wrong in the same direction every time.

Push one cost down, another pops up

Every estimate is a bet on what’s known and what isn’t. AI shortens the odds on the known part and leaves the unknown part exactly where it was.

That’s the question to ask about your own project, task by task: is this piece well-understood, with a track record, where AI narrows the range? Or is it waiting on something you don’t have yet, like a decision or a partner’s confirmation? AI applied to the first kind can lower cost or risk. Applied to the second kind, it adds output for your team to review without reducing what you don’t yet know.

Quality follows the same split. AI-assisted work still needs someone who can spot a plausible answer that’s wrong. Price that review into the budget from the start, alongside whatever AI saves elsewhere.

Price the setup, too. Getting a usable result out of a tool takes more than a licence: writing and testing prompts, building something around the model, then tuning it until the output holds up. A tool that trims the time spent summarizing research interviews carries that build cost first, and that cost stays the same whether the engagement is large or small. The same goes for the oversight that follows. In GitLab’s survey, 98 percent of organizations had allocated a budget for governing and tracing AI-generated code or expected to within the year, and half were already evaluating tools. That’s a line item almost everyone ends up paying and almost nobody puts in the original estimate.

Buying a scope versus buying a team

The answer changes depending on what you’re buying.

If you’re procuring a fixed scope, don’t leave AI use as an unstated assumption inside someone else’s price. Ask vendors to state where their approach uses AI, and where it doesn't. That’s what makes bids comparable. Without it, one vendor’s number and another’s aren’t pricing the same thing. It also gives you a basis to judge the answer: some tasks are well-understood enough that AI use there is low-risk, even welcome. Others carry quality or judgment risk if AI is doing more of the work than you'd want. You need a view on which is which before you can evaluate what’s in front of you.

If you’re procuring a team (a full agile team, or individuals to add to an existing internal team), the evaluation looks different from the start. You’re buying capacity. Vendors get assessed on past experience and rate, and there’s usually no written approach to check AI assumptions against in the first place. That puts the responsibility on you: know what you want to see from a team’s experience with AI, and build your own view of where the work should incorporate it as the engagement runs.

Either way, someone on your side needs to be experienced enough to catch a claim that doesn’t hold up: a line in a bid, or a pattern in how a team is working.

Seeing what’s inside a project

Both routes come down to the same judgment: which tasks AI moves, and how much of the project those tasks represent. To test that judgment on our own numbers, we built Baseline, an estimating tool that shows the process for custom software builds. It shows what it takes to turn “AI might help here” into a number someone can defend, and how much research sits behind a single line in an estimate. Every task starts at what past projects actually took, then AI proposes where the hours can come down, held inside a range that hands-on research has already set for it. Each savings carries a confidence rating (evidenced, plausible, or speculative), so anyone reading the estimate can see how much of it rests on solid ground and how much is still unproven.

Set the expectation before the number is fixed

How much AI reduces cost depends on how much of the work is bounded and well understood already. That’s where to expect a real gain. The tasks that depend on judgment, novelty, or a decision still pending will cost what they’ve always cost, and someone senior still has to check the work either way. Set that expectation before discovery starts, and the number you submit has a better chance of surviving contact with the project.