AI-Assisted Development · Estimation

AI Made the Coding Faster. It Didn't Make the Project Faster.

"You use AI now, so this should ship in half the time." The demo that produced that expectation timed the one phase of your project that was never the bottleneck.

Where AI actually saves time Estimate by slice, not a multiplier When to walk from a vendor

You use AI now, so this should ship in half the time. If you run engineering, some version of that sentence has already reached your desk, from a board member, a founder, or a client who watched a demo. The expectation is reasonable, and the demo was real.

The problem: that demo timed the one phase of your project that was never the bottleneck.

The speedup is real, on the slice that was never the problem

GitHub ran a controlled study where developers built an HTTP server in JavaScript. The group using GitHub Copilot finished in 71 minutes against 161 minutes for the group without it, about 55% faster. That number is real, and it is the source of every "half the time" expectation you are now fielding.

Look at what the task was. A self-contained problem, built from scratch, with no existing system to understand, nothing to integrate against, and no production bar to clear. That is the slice where AI is genuinely fast, and it is usually the smallest slice of a real project.

What we see in delivery: the forcing function is gone

For years, slow coding did something useful that nobody noticed. Building was expensive, so teams were forced to think hard about the requirement before they wrote a line, because getting it wrong meant weeks of rework.

AI removed that expense. A developer can now build a working feature from a rough, half-specified requirement in an afternoon, and a UI prototype can appear in hours. So the deliberation that used to happen up front quietly stops happening.

What happens next is consistent, and we see it over and over. The application gets built fast, and it gets built in the wrong direction. Then the real time begins: round after round of changes and re-verification to bring it back to what the client actually meant, and that tail runs far longer than the hours the prototype saved.

The time did not disappear. It moved downstream, and it grew.

The data behind the feeling

This is not only our observation. In 2025, METR ran a randomized study with experienced developers working on their own mature codebases, using Cursor with Claude Sonnet, the frontier tools available at the time. The developers were 19% slower with AI, while they had predicted a 24% speedup and still believed, afterward, that AI had made them about 20% faster.

Look at that gap. Your team can feel like it is flying while the calendar quietly slips a fifth. AI removes the friction of starting and typing, so the work feels effortless even when it takes longer, and effort is what people mistake for speed.

It is one study, with a small sample, on open-source repositories. We would not lean on it alone. We lean on it because it matches what we watch happen on client projects every quarter.

The backdrop was already bad. Across more than 5,400 IT projects, McKinsey and the University of Oxford found the average one runs 45% over budget and 7% over time, with software carrying the highest schedule risk of all. AI optimism does not fix that baseline; it shortens the promise while leaving the work the same size.

Optimistic timelines are also how good projects quietly become the ones that never reach production.

Where the delivery time actually goes

If you break an estimate into the parts that actually consume the calendar, six of them show up:

Where a software estimate actually goes
  • Understanding the requirement and the existing system
  • Design decisions
  • Writing the code (the slice AI compresses)
  • Integration with everything already running
  • Verification that it is actually correct
  • Coordination and review

Writing code is the slice AI compresses, and on most real projects it is the minority of the total. Understanding and verification dominate, and both get heavier, not lighter, when an agent is generating code at speed that someone still has to confirm is correct.

That is why a blanket "AI, so half the time" is not an estimate. It is a discount applied to the wrong line item.

How to estimate honestly: give understanding its weight

The fix is not to slow down. It is to put the saved time where it earns its return. This is the phase we protect hardest in our own delivery, and it maps to the U in how we run AI-assisted work: Understand before you build.

Estimate by slice, not by a single multiplier. Cut the code-authoring slice, because AI genuinely shrinks it.

Hold or raise the verification slice, because code an agent wrote at speed needs more review, not less. And refuse to cut the understanding slice, because that is where every hour of downstream rework is either created or avoided.

This is not anti-AI. It is what makes AI pay off.

Our engineers use Claude Code every day, AI writes and runs test cases, and AI reviews every pull request. None of that helps if the team built the wrong thing quickly, so the tools earn their keep only after the requirement is understood.

Understanding a live system is its own discipline. It is the work behind what an agent must know before it edits a 12-year-old codebase and the codebase archaeology most AI workflows skip.

If you are the one evaluating a vendor, this gives you a sharp question to ask. Ask how they estimate the verification and requirements slices of the work. A team that has shipped AI-assisted code knows those slices grew; a team selling you the demo will wave them away.

When "half the time" is real, and when to walk

To be fair to the demo, sometimes half the time is exactly right. Greenfield builds, well-scoped internal tools, prototypes, and throwaway spikes are close to the GitHub task: little to understand, little to integrate, a low bar to clear. Ask for aggressive timelines there and hold the team to them.

The mature, integrated, or regulated system is the opposite. A wrong change there is expensive to find and expensive to undo, and the correction tail is the whole game.

The signal to watch: a vendor who offers to ship your brownfield platform in half the time has not priced the correction tail.

You will pay for it later, in slipped dates. That is the moment to walk.

The honest version of the estimate

The ship date was never set by how fast anyone types. It is set by how well you understood what was actually needed, and how hard you verified that you built it. Get those two right and AI is a real accelerant.

Skip them, and AI simply gets you to the wrong place sooner, then bills you for the trip back.

That is the honest version of the estimate, and it is the one we would rather give you before the work starts than explain after a deadline has moved.

If price is the real question underneath the timeline, we broke that down separately in what an agentic AI pilot actually costs.

Get an honest timeline for your build

Send us the shape of your build. We come back with a timeline sliced by where the time actually goes, one you can take to your board without flinching.

Start the conversation

AnAr Solutions builds and modernizes software with AI in the loop on every project, from requirements through verification. We would rather give you an accurate timeline than an optimistic one, and we engineer products to that standard.

Our Latest Blogs
Clear Filters
The Codebase Archaeology Phase Most AI Workflows Skip
Robot with a magnifying glass examining legacy code, asking what the code is not telling an AI agent, for a post on the codebase archaeology phase AI workflows skip
What an AI Agent Needs to Know Before It Edits a 12-Year-Old Codebase
An AI coding agent reading a legacy codebase before editing it: the system, the change site, and the invariants
The Real Cost of an Agentic AI Pilot (It’s Not What You Think)
Senior leader at a whiteboard sketching an agentic AI workflow
What We Tell Every CTO Before They Start an Agentic AI Project
Agentic AI Readiness for CTO
Why 88% of Agentic AI Pilots Never Reach Production (And How to Be the 12%)
Why-Agentic-AI-Pilots-Fail
Why AI Coding Tools May Hurt Your Productivity and What You Can Do?
Why AI Coding Tools May Hurt Your Productivity and What You Can Do
MCP vs API: Choosing the Right Path for AI Integration
MCP-vs.-API-Choosing-the-Right-Path-for-AI-Integration
Agentic AI vs. Generative AI: Which Will Shape the Future?
Agentic AI vs. Generative AI
Privacy Preferences
When you visit our website, it may store information through your browser from specific services, usually in form of cookies. Here you can change your privacy preferences. Please note that blocking some types of cookies may impact your experience on our website and the services we offer.