Estimating AI-Assisted Development | Coding Capybaras

Photo by Stanislav on Unsplash

Estimating AI assisted development work is mostly a question of estimating the second half of the job, because the first half stopped being the expensive part. When an AI assistant writes the code, the drafting time collapses and the verification time doesn't — so the old instinct of "this is a two-day feature" produces a number that's wrong in both directions depending on the task. The estimate that holds up now has a different shape: how long until a working draft exists, plus how long until you trust it enough to deploy. This post covers why the old numbers break, what the research says, and a scoping method that keeps you honest.

TL;DR

• AI collapses drafting time and leaves verification time roughly intact — so estimate the two halves separately instead of as one number.
• Your speedup depends almost entirely on how well-trodden the task is. Familiar CRUD gets fast. Novel integration work barely moves.
• Measured speedup and felt speedup diverge badly. A randomized trial from METR found developers believed they were 20% faster while actually running 19% slower.
• Scope features to one working session. If you can't describe the finished state in a paragraph, it's two features.
• Track your own multipliers for a month. Your ratio beats anyone's published benchmark.

Why your old estimates break when AI writes the code

The estimate you carry in your head is a bundle. "Two days for CSV export" quietly contains: figuring out the shape of the data, writing the query, writing the serializer, wiring the route, handling the empty case, handling the huge-file case, styling the button, testing it, and fixing the two things that broke.

AI assistants annihilate some of those line items and leave others completely untouched. The serializer appears in ninety seconds. The empty case appears in ninety seconds. The "huge file times out because a serverless function has a max duration and nobody told me" discovery still takes you the same afternoon it always did, because that's a fact about your infrastructure that no amount of generation speed changes.

So the bundle comes apart. If your feature happens to be 80% drafting and 20% discovery, you'll finish it in a fraction of the old time and feel like a genius. If it's 20% drafting and 80% discovery, you'll finish it in roughly the old time and feel like the tools failed you. Neither feeling is information. Both are just the mix of that particular task.

The second thing that breaks is the relationship between progress and done. Traditionally those tracked each other reasonably well: if the code existed, it was code you'd written, which meant you understood it, which meant you were close. Now code can exist that you have never read. Google's DORA team calls the consequence a verification tax — in their thematic analysis of 1,110 open-ended responses from Google software engineers, the time saved during generation gets re-spent auditing output. One engineer in that study put it plainly: they spend less time writing code and more time "babysitting the AI and reviewing what it is trying to do."

For a solo founder that tax lands entirely on you. There's no reviewer downstream to catch what you waved through. Every line the assistant wrote is a line you are personally on the hook for at 2am when a customer emails.

The third breakage is the sneakiest: the last mile got relatively more expensive. DORA describes this as the workflow gap — a prototype appears almost instantly, but the production version, with edge cases and real integrations, can take more effort than if you'd built the whole thing by hand. Their recommendation to leaders is blunt, and it applies just as well to a founder estimating their own week: "Don't reduce estimates before investing to close this gap."

That's the honest starting position. AI moved the work around inside the estimate. It did not uniformly shrink the estimate.

What the research actually says about AI speedup

Here's the study that should make everybody humble about their own estimates.

In early 2025, METR ran a randomized controlled trial with 16 experienced open-source developers working 246 real issues in their own repositories — mature codebases averaging 22,000 stars. Each issue was randomly assigned to "AI allowed" or "AI disallowed." Developers recorded their screens and reported their implementation time.

Before starting, they forecast that AI would make them 24% faster. Afterward, having lived through it, they estimated AI had made them 20% faster. The measured result was a 19% slowdown.

Now the necessary caveats, because this result gets misquoted constantly. METR themselves label it a snapshot of early-2025 tooling and explicitly decline to claim it generalizes to most developers or most work. The participants were deep experts on their own mature codebases — the setting where an assistant has the least to teach you and the most implicit style, testing, and documentation conventions to trip over.

What happened next is just as useful. METR ran the study again from August 2025 with 57 developers across 143 repos and 800+ tasks — and published in February 2026 that the design had broken. Not the result, the design. Too many developers refused to work without AI, and 30% to 50% of participants admitted they were withholding tasks from the experiment specifically because they didn't want those assigned to the no-AI condition. One developer described working without an agent as "trying to get across the city walking when all of a sudden I was more used to taking an Uber."

Their raw second-round numbers lean toward speedup without establishing it. The 10 returning participants came in around 18% faster, with a confidence interval spanning -38% to +9%; the 47 newly recruited developers came in at 4% faster, CI -15% to +9% — statistically indistinguishable from no effect. METR attributes the selection problem partly to developers who refuse to work AI-free and partly to a pay cut from $150/hr to $50/hr, and is explicit that the whole thing is weak evidence. The honest summary is: the direction probably improved since 2025, and nobody has a clean figure.

Meanwhile the perception data is consistent and lopsided. The separate 2025 DORA State of AI-assisted Software Development report found 90% of technology professionals using AI at work, with over 80% believing it raised their productivity — while 30% simultaneously reported little to no trust in the code it generates. Stack Overflow's 2025 developer survey found 84% using or planning to use AI tools, 66% naming "almost right, but not quite" as their top frustration, and 45% saying debugging AI-generated code is more time-consuming.

The practical takeaway for estimating isn't "AI is slow." It's that your felt sense of speed is an unreliable instrument, and you should not build a schedule on it. Every group measured so far overestimates their own uplift. Assume you're doing the same.

The four multipliers that decide your real estimate

Instead of one speedup number, I run a feature through four questions. Each one nudges the estimate up or down, and together they get me much closer than gut feel.

1. How well-trodden is this? An assistant is fastest on code that resembles a million other codebases: a CRUD endpoint, a form with validation, a Stripe checkout session, a table with sorting. It's slowest on anything genuinely specific to you — your weird pricing rule, your data model's one unusual join, your customer's specific integration demand.

2. How much context does it need? A change confined to one file is a different animal from a change threading through six. The more of your codebase the assistant needs to hold correctly at once, the more it will guess — and guesses show up as invented file paths and imaginary function names. A well-maintained CLAUDE.md file shifts this multiplier meaningfully in your favor, which is most of why I keep one.

3. How bad is being wrong? A dashboard chart that renders wrong is embarrassing. A billing change that computes wrong is a refund, an apology, and a trust problem. High-consequence code demands real review time regardless of who or what drafted it — that's the verification tax at its heaviest, and it's a tax you should want to pay.

4. Do you already know what "done" looks like? This is the biggest one and the one founders skip. If you can't describe the finished state precisely, you're not estimating implementation — you're estimating design plus implementation, and design time has never been predictable.

| Task shape | Drafting time | Verification time | Net vs. hand-coding | | --- | --- | --- | --- | | Standard CRUD, one file, spec is clear | Collapses | Light | Much faster | | New UI screen, several components | Collapses | Moderate | Faster | | Third-party integration with real docs | Shrinks some | Heavy | Modestly faster | | Billing, auth, or anything money-adjacent | Shrinks some | Very heavy | Roughly flat | | Debugging a bug you can't reproduce | Barely moves | N/A | Flat or worse | | Feature you haven't actually designed yet | No help | N/A | Unchanged |

That table is a framework, not a benchmark — the exact numbers are yours to discover. But the ordering holds across everyone I've compared notes with, and it maps cleanly onto what the research shows: the more your task looks like the common case, the more the tools help.

The practical move is to stop estimating features and start estimating task shapes. "Add team invitations" is unestimatable. "Add an invitations table, an invite endpoint, an email send, and an accept flow" is four rows in that table.

How to scope a feature to a single working session

The unit I now estimate in is the session: one uninterrupted block, typically 90 minutes to three hours, where I open the project with a specific finished state in mind and close it having reached that state or learned why I couldn't.

Session-sized scoping fixes three problems at once. It bounds the blast radius when the assistant goes sideways. It keeps the change small enough to actually review. And it gives you a real feedback signal — you find out today whether your estimate was right, not next Thursday.

Here's the test I use. If you can't write the finished state in one paragraph, including what happens when it fails, you have more than one feature. Not a vague paragraph. A paragraph a stranger could check your work against.

Bad: "Users can export their data."

Good: "A signed-in user on the settings page clicks Export, and within ten seconds downloads a CSV of their own records with a header row and ISO-8601 dates. Empty accounts get a file with just the header. Accounts over 10,000 rows get a queued job and an email instead. The button is disabled while a job is running."

The second version is estimatable because every clause is either drafting or verification, and you can see which is which. It also happens to be most of a spec — which is the whole argument behind spec-driven development with AI. The spec isn't bureaucracy. It's the artifact that makes the estimate possible.

Two more rules I've landed on.

Put a timer on the stuck state. When the assistant's third attempt still doesn't work, that's not a coding problem anymore, it's a context problem, and more prompting makes it worse. I cap it at twenty minutes before I stop and restructure — which is the same discipline I wrote about in breaking out of the AI stuck loop. Budget for one of these per feature and you'll stop being surprised by them.

Estimate the review, explicitly, as its own line. Not "and then I'll check it." An actual number. If you generated 400 lines touching auth, reviewing properly is an hour and you should write down an hour. Most blown estimates I've had were review time I pretended was free.

Where this connects to the rest of your week: session-sized work is what makes time-blocking as a solo founder function at all. A two-hour block only produces something shippable if the thing you put in it fits.

Build your own multipliers in one month

Published research tells you the shape of the effect. It cannot tell you your number, because your number depends on your codebase, your stack, your tooling, and how long you've been doing this. The good news is that measuring it is almost free.

For four weeks, before each session, write down two things: the one-paragraph finished state, and your guess in minutes. When you close the session, write the actual. That's it — a text file, three columns.

By week three you'll see patterns that no benchmark could have given you. Mine, roughly: familiar CRUD lands close to my guess or better. Anything involving Stripe runs about double, every time, because the verification bar is high and the failure modes are subtle. Debugging estimates are worthless in either direction — I now scope debugging by timebox rather than by estimate, which is a different tool entirely.

Two things that make this measurement honest. First, log the estimate before you start, not after; retrospective estimates drift toward whatever actually happened. Second, log the session where you bailed after forty minutes with nothing to show. Those sessions are where your real average lives, and they're exactly the ones that feel too embarrassing to record.

This is also the only defense against the perception gap in the METR data. Those developers weren't careless — they were experienced people, working in their own repos, wrong about their own speed by nearly 40 percentage points. The instrument that fixed it was a stopwatch and a log. You have both.

One caution on what you're measuring. Speed is not the only thing that moved. DORA found higher AI adoption associated with increased delivery throughput and increased delivery instability — faster shipping, more breakage. If your estimates are improving while your bug count climbs, you haven't gotten faster; you've moved the work into next month. Track both or you'll fool yourself.

Frequently asked questions

How much faster is AI-assisted development, really?

Nobody has a trustworthy general number, and anyone quoting one confidently is overselling. The best controlled evidence — METR's early-2025 trial — found a 19% slowdown for experts on mature codebases, and METR's own 2026 follow-up suggests modern agentic tools do better while admitting the data is compromised by selection effects. The variance across task types dwarfs the average, so your own measurements are worth more than any published figure.

Should I tell customers a shorter timeline now that I'm using AI?

No. Quote based on what you've measured, not on tool capability. The part of delivery that AI compresses — drafting — was rarely the part that made you late. Discovery, integration, and the production last mile still run on their old clock, and DORA explicitly warns against cutting estimates before you've closed that gap.

What's a good default multiplier when I have no data yet?

Estimate the feature as if you were writing it by hand, then split the number: drafting and verification. Cut drafting substantially, leave verification alone, and add a fixed block for one stuck-loop episode. That gets you a defensible first guess. Replace it with real data as soon as you have four weeks of logs.

Why do my estimates feel accurate when they aren't?

Because generation speed is extremely visible and verification time isn't. Watching 200 lines appear in eight seconds creates a vivid memory; the forty minutes you then spent reading them doesn't. Every study that has measured perceived speedup against actual speedup has found the perception running well ahead.

Does better prompting actually improve my estimates?

Indirectly, and mostly through specificity. A precise, well-scoped request reduces the number of wrong attempts, and wrong attempts are the main source of estimate blowout. But no prompt removes the verification tax on high-consequence code, and treating prompting skill as a substitute for review is how founders ship billing bugs.

Should I estimate debugging the same way?

No — timebox it instead. Debugging estimates are unreliable with or without AI because you're estimating how long until you understand something you don't yet understand. Give it a fixed block, and if the block expires, change approach rather than extending.

Estimating AI assisted development, in one line

Estimating AI assisted development comes down to separating the half of the work that collapsed from the half that didn't, then measuring your own ratio instead of trusting how fast it feels. Drafting is cheap now. Understanding, verifying, and getting to production-grade are not, and those were always the parts that made you late. Scope to a session, write the finished state in a paragraph, log your guess against the actual for a month, and you'll have estimates that beat anything a benchmark could hand you.

If you're shipping a SaaS with AI coding tools and want a codebase where the boring infrastructure is already estimated and done, Coding Capybaras is the free boilerplate I built for exactly that workflow.