Every agency claims a number. “50% faster.” “Ship in half the time.” Almost none of them say where that number came from. We’d rather show you the real research first. Then we’ll tell you what it actually measures. After that, we’ll explain what we track ourselves. That’s a more useful way to think about AI-assisted development speed than another unverifiable headline figure on a homepage.
This is the third piece in our series on what a Claude Code development workflow looks like in practice. The first two covered the daily workflow itself and the review stage specifically. This one steps back and asks a harder question. What does the evidence actually say about speed? And which parts of that evidence should you actually trust?
What Independent Research Actually Shows
Start with the most cited number in this space. GitHub ran a controlled experiment. Developers were asked to build an HTTP server as fast as possible. The group using an AI coding assistant finished 55% faster than the control group. Outside researchers later replicated the setup and confirmed the result. That’s a real, statistically significant finding. It’s also a narrow one. One task, one language, a lab setting rather than a messy production codebase.
Field studies tell a more nuanced story. A joint study between GitHub and Accenture covered roughly 4,800 developers. It found pull request cycle time dropping from 9.6 days down to 2.4 days. Successful builds jumped 84% over the same period. A separate randomized trial involving Google engineers found a smaller, but still meaningful, 21% reduction in time spent on complex, enterprise-grade coding tasks. A six-week study at ANZ Bank found productivity gains varied sharply by experience level. Beginners improved by roughly 52%. Advanced developers improved closer to 40%.
Here’s the part most marketing pages leave out entirely. Recent academic analysis has started pushing back on some of these headline figures. Measured gains vary enormously by task type. They can also be overstated when studies don’t account for code review time, rework, or long-term maintenance cost. We think that pushback deserves to be taken seriously, not dismissed. It’s exactly why we don’t quote a single flat percentage number for our own team’s work.
Why the Metric You Pick Changes the Number
Speed isn’t one thing. It’s several different measurements, and each one tells a different part of the story.
Task completion time
This is the easiest metric to measure, and also the easiest one to game. It answers “how fast did someone finish this specific task.” That’s useful in a lab. It doesn’t capture what happens after the code actually ships to real users.
Pull request cycle time
This measures how long code sits between being opened and being merged. It’s a better real-world proxy than raw task completion time, because it includes review time, back-and-forth discussion, and fixes. It’s also the metric that improved most clearly in the GitHub-Accenture field data mentioned above.
Build and merge success rate
This one matters more than it sounds like it should. A team that ships fast but breaks builds constantly isn’t actually faster once you account for the cleanup. Rising build success rates alongside faster cycle times is a much stronger combined signal than either number alone.
Rework and defect rate
Almost nobody advertises this one, because it’s the metric that can quietly cancel out every speed gain listed above it. Code that ships fast but needs three follow-up bug fixes wasn’t actually faster. It just moved the time cost to a different week, usually a more expensive one.
What We Actually Track Internally
We don’t publish a single flat “X% faster” number, and we’re not going to invent one here either. It wouldn’t hold up to the same scrutiny we just applied to everyone else’s numbers. What we do track, consistently, across projects:
- Review cycle length. Shorter, because the AI-assisted review pass we covered in our last article catches mechanical issues before a human reviewer opens the file.
- Late-stage bug reports. Fewer, because the planning stage of our workflow surfaces edge cases before they reach QA, not after a customer finds them.
- Onboarding time on unfamiliar codebases. Faster, particularly on outsourcing engagements where our engineers need to get productive inside someone else’s existing code quickly.
- Rework rate on delivered features. Roughly stable to slightly improved, and this one matters more to us than raw speed. A feature that ships fast and needs to be rebuilt later isn’t actually a win.
Those are directional, honest observations about how our delivery process has changed. They aren’t a controlled experiment with a p-value attached, and we won’t pretend otherwise. We think that distinction matters. We’d rather be clear about it than dress up an internal impression as academic-grade research.
A Simple Way to Read Any Speed Claim
Here’s a habit worth adopting whenever you see a number like this, ours included. Ask which of the four metrics above the number is actually measuring. A 55% figure from a lab task means something very different from an 84% jump in successful builds across thousands of real developers. Neither number is wrong. They’re just answering different questions, and conflating them is where most marketing claims quietly go astray.
It’s also worth asking over what time window a claim was measured. A speed gain measured over a single sprint can look very different from one measured across a six-month engagement, once onboarding time, documentation debt, and maintenance work get factored back in. Short-window numbers tend to look better than they hold up over time, simply because the harder, less repetitive work hasn’t shown up yet.
Where AI-Assisted Development Speed Gains Disappear
This matters just as much as where the gains show up. Complex integrations with legacy systems don’t get meaningfully faster just because AI sits somewhere in the workflow. Neither do projects where the biggest time cost is waiting on a client decision, or navigating an undocumented third-party API. Speed gains concentrate heavily in boilerplate-heavy, well-understood work. Think CRUD scaffolding, standard API endpoints, repetitive test setup, and common UI patterns.
That lines up with the research above too. Task-specific gains vary enormously depending on the kind of work involved. The largest measured improvements tend to cluster around repetitive, well-defined tasks rather than judgment-heavy architectural decisions. Anyone promising a flat speed multiplier across every kind of project is glossing over that variance, whether they mean to or not.
The Honest Way to Evaluate a Vendor’s Speed Claims
If an agency quotes you a specific percentage, ask what it’s actually measuring. Task completion time in a lab setting is a very different claim than pull request cycle time across a real production codebase. Ask whether the number accounts for rework and defect rates, not just how fast the first version of the code got written. Ask whether the gain holds across different kinds of work, or only shows up on the easiest, most repetitive tasks.
Those questions matter more than the headline number itself. A vendor who can answer them clearly, with real methodology behind the claim, is a far safer bet than one who just repeats “50% faster” without being able to explain where the figure came from in the first place.
This matters even more on outsourcing engagements specifically. When a client hands a project to an external team, they’re trusting a claim about AI-assisted development speed that they usually can’t verify firsthand. That trust gap is exactly why we’d rather explain our methodology openly than lean on a number that sounds impressive but doesn’t survive a follow-up question. A client who asks “how do you measure that” deserves a real answer, not a deflection.
Where This Fits Into How We Work With Clients
Speed only matters if the software that ships actually holds up afterward. Our software development services — Laravel, React, Next.js, and NestJS builds — are structured around the Plan, Build, Review, Ship workflow described across this series, specifically because it balances speed against the metrics that actually matter. Fewer defects. Shorter review cycles. Code that’s still maintainable a year later, not just fast to write today.
If you want to see what that balance looks like in finished work, our portfolio covers the kind of admin panels, dashboards, and integration builds this workflow supports regularly. You’re also welcome to read more about our team and how we operate before deciding whether an AI-assisted delivery process is the right fit for your next project.
The Honest Takeaway
The real research on AI-assisted development speed is genuinely encouraging, and genuinely more nuanced than a single percentage on a homepage. Gains are real, but they’re uneven. They’re task-dependent, and easy to overstate if you only measure the part of the process that’s simplest to measure. We’d rather tell you what we actually track, and where we’ve seen gains disappear entirely, than hand you a number we couldn’t defend under a few direct questions.
If you want a straight answer about how this applies to your specific project, rather than a generic industry statistic, request a free quote and we’ll walk you through it honestly.