No controlled study has actually measured how long it takes an AI-assisted engineer to become productive in a codebase they didn't write. What exists instead is a shipping-velocity proxy from DX, a study of experienced developers that gets misapplied to this question constantly, and a vendor timeline with no data behind it. None of the three answers the question cleanly, and treating any of them as if they do will get a CTO the wrong hiring or onboarding decision.
Here's what each piece of evidence actually shows, and where the gaps are.
The closest real data point, and what it leaves out
DX, the engineering-metrics platform, tracks a metric called "time to 10th pull request" across roughly 400 companies with 500 or more developers each. It's one dataset, not two separate samples, and it's built from actual commit and PR activity rather than survey responses, which makes it the most concrete thing anyone has published on this question.
In an analysis published April 9, 2026, DX put the current average at 33 days for developers using AI tools daily. That's down from where the same metric stood in early 2024, though DX doesn't publish an exact day count for that earlier baseline. What the company states is a "more than 50% reduction" since Q1 2024, and that's the figure worth repeating, not a specific number DX never printed.
DX also ran a direct cohort comparison for the fourth quarter of 2025, a separate and earlier reporting period than the October 2025 to February 2026 window behind the 33-day average: developers with no AI usage took 91 days to reach their 10th pull request, against 49 days for developers using AI daily. That's close to half the time, and it's the cleaner comparison of the two figures, since both numbers come from that same Q4 2025 cohort rather than a multi-year trend line, even though the cohort itself predates the current average above.
Now the part that matters more than either number. DX says plainly that this metric doesn't measure code quality, how much rework the AI-assisted commits generate later, or how deeply the developer actually understands the system they're shipping into. Ten pull requests is ten pull requests, whether they're clean, well-reasoned changes or a stream of small edits that a senior engineer quietly fixes in review. A new hire who ships fast and creates a pile of technical debt hasn't ramped up. They've just moved the cost downstream. Treat "33 days" as a velocity number, not a comprehension number, because that's exactly what DX built it to be.
Why a familiar-codebase study doesn't answer an unfamiliar-codebase question
The other data point that keeps getting dragged into ramp-time conversations is METR's July 2025 study, and it needs a direct correction: METR did not study ramp time, and it did not study new hires.
METR followed 16 experienced open-source developers across 246 real tasks, all inside codebases those developers already knew well. With AI assistance turned on, they were 19% slower than without it. Before the study, they'd forecast a 24% speedup. Afterward, despite running measurably slower, they believed they'd been about 20% faster. That gap between felt speed and measured speed is the study's real finding, and our deeper look at what the AI-speed research actually shows covers it alongside Microsoft's and Google's numbers in full.
None of that transfers directly to a new hire learning an unfamiliar system. But the analogy is worth making explicitly, because it cuts against the optimistic assumption baked into most AI-hiring pitches. If AI assistance doesn't reliably speed up developers who already have deep context on the code they're touching, there's no evidence base for assuming it reliably substitutes for the context a brand-new hire simply doesn't have yet. METR's self-assessment gap also matters for a different reason: a new hire who reports feeling productive with AI tools in their first month is reporting a feeling, and feelings about AI-assisted speed have already been shown to run 40 points off measured reality in at least one careful study.
For scope, Microsoft's controlled study measured 55.8% faster completion on a from-scratch HTTP server build, and Google's internal RCT found a raw 96-versus-114-minute difference (significant at p=.038) on a bounded logging patch to an existing 474-line repository, with the frequently-quoted ~21% figure being the covariate-adjusted estimate that lands at p=.086, short of conventional significance. Both are real, well-designed studies. Neither is a ramp-time study. They measured developers completing one assigned task, not learning a system well enough to work in it independently, and the full study comparison is the place to see how they stack up against METR and the DORA survey data.
The vendor claim you should discount
Search this topic and you'll eventually run into a chart, published by HatchWorks, comparing an "AI-native" staff-augmentation engagement reaching full productivity in about two weeks against a traditional full-time hire taking roughly six months to get there through recruiting, training, and ramp.
That chart carries no methodology, no sample, and no case study behind it. It's a marketing claim on a vendor's own blog, and it should be read as exactly that: one company's pitch for why its model beats direct hiring, not an audited finding. If a vendor hands a CTO a hard number with no data trail, the honest response is to ask where it came from, not to repeat it in a board deck.
HighCircl doesn't have a ramp-time or productivity figure of its own to offer instead, and it would be dishonest to manufacture one just to fill the gap HatchWorks left. What HighCircl does document is how it tries to reduce the risk that ramp-up turns into a slow, expensive discovery process: a four-stage, engineer-led vetting process run by senior engineers, roughly 1 in 10 applicants passing, and a shortlist of 3 to 5 candidates delivered within 72 hours. That's a hiring-quality claim, not a speed claim, and the two shouldn't be confused. How engineer-led vetting actually works and how architectural judgment gets assessed cover the mechanics.
What this means for hiring and onboarding
None of the available evidence tells a CTO a specific number of days or weeks until a new AI-assisted engineer is fully productive in an unfamiliar codebase. What it does tell you is where to put your attention instead of chasing a headline figure.
First, track shipped output with the same skepticism DX applies to its own metric. If you're measuring ramp with something like PR count or ticket throughput, pair it with a rework or defect-rate check, because a fast starter who generates cleanup work later hasn't actually ramped faster, they've just deferred the cost.
Second, don't take a new hire's self-reported comfort with AI tools as evidence of real productivity. METR found a wide gap between how fast experienced developers felt they were working and how fast they actually were, and there's no reason a new hire, with far less context than an OSS maintainer of years, would self-assess any more accurately.
Third, weight vetting over tooling. Our guide to how the senior engineer's job has shifted with AI makes the case that reviewing and architecting code, not typing it faster, is what separates a hire who ramps well from one who doesn't. An engineer who can reason about an unfamiliar system's architecture will get more out of AI tooling in month one than one who can only prompt their way through isolated tasks. That's a hiring bar you can actually test for, unlike a ramp-time figure nobody has published.
Frequently asked questions
Is there a reliable study on how long it takes a new AI-assisted engineer to ramp up?
Not one that directly measures it. The closest available data point, DX's "time to 10th pull request" metric, tracks how fast developers ship pull requests, not how long it takes them to understand an unfamiliar codebase. It's a real, commit-based dataset covering roughly 400 companies, but DX itself says it doesn't capture code quality, rework, or depth of understanding.
What does the DX ramp-up data actually say?
DX found that developers using AI tools daily currently reach their 10th pull request in an average of 33 days, a reduction of more than 50% since Q1 2024, though DX hasn't published the exact day count for that earlier period. In a direct Q4 2025 comparison, developers with no AI usage took 91 days to hit the same milestone, against 49 days for daily AI users.
Does the METR study prove AI speeds up onboarding for new hires?
No, and it isn't designed to. METR studied 16 experienced open-source developers working in codebases they already knew, not new hires learning unfamiliar systems, and found they were 19% slower with AI assistance despite believing afterward that they'd been faster. The relevant lesson for hiring is by analogy: if AI doesn't reliably speed up developers with deep existing context, there's no basis for assuming it compensates for a new hire's total lack of that context.
Should I trust vendor claims like "productive in two weeks"?
Treat them as marketing until you see a methodology. HatchWorks publishes a chart claiming roughly two weeks to productive delivery for an AI-native staff-augmentation hire against about six months for a traditional full-time hire, with no data, sample, or case study attached. That doesn't make the underlying idea, that augmented hires can ramp faster than a full recruiting cycle, wrong. It just means the specific number isn't backed by anything you can verify.