On This Page
AI is now the fastest tool ever built for building AI itself.
A developer can describe a feature in plain English and watch a working prototype emerge in minutes. By every reasonable measure, the recursive loop should be collapsing the failure gap.
But it isn't. By RAND's latest count, roughly 80 percent of AI projects still fail to reach meaningful production — twice the failure rate of conventional IT, and unchanged through 2026.
If the best tool for building AI is now AI itself, why is the gap this persistent? We asked several experts.
Where AI Accelerates AI Project Development
Walk into a team building AI in 2026 and you'll find LLMs almost everywhere, not just in the code editor. Google's 2025 DORA report, drawn from a survey of nearly five thousand technology professionals, puts the daily-use rate among developers at around 90 percent — up roughly fourteen percentage points in a single year.
Where the acceleration actually lands varies more than the headline numbers suggest. In requirements engineering, the model functions as a forcing function for clarity. "We use LLMs as a structured 'second brain' during discovery," explains David Hunt, COO at Versys Media. "On a recent internal product, we took a 12-page requirements draft and ran it through a prompt that forced explicit assumptions, edge cases, data flows, and failure modes. That cut our iteration on the spec from about 2 weeks to 3 days and reduced change requests later by roughly 30% based on JIRA issue history."
Downstream the pattern repeats — but the source of expertise shifts from individual practitioners to the broader research base. LLMs stress-test architecture decisions rather than generate them, surfacing scaling concerns and failure modes that would otherwise emerge in production. They draft initial QA scenarios for human refinement, ghostwrite documentation off codebases, summarise standups into project boards. In coding itself, the 2023 GitHub/MIT controlled study put completion times around 56 percent below baseline with an AI pair programmer; DORA's 2025 numbers suggest the practice is now near-universal.
What's worth pausing on is where the acceleration actually lands. None of these gains arrives in the same place for every organization. Where AI helps most in AI project development depends less on the tooling than on what the team was already slow at.
AI Amplifies; It Doesn't Correct
This is the single most important finding of the DORA 2025 report, and it puts in plain language what many engineering leaders have been describing privately for two years: "AI's primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones."
The corollary is unflattering. AI doesn't fix bad reasoning — it accelerates it. It makes clear thinkers faster, and unclear thinkers faster at being wrong. For an organization with vague requirements, AI compresses the period during which that vagueness produces damage. For an organization with sharp internal discipline, it compounds the advantage. This is where prior building experience starts to matter in ways most leaders underestimate.
"The mistake I keep watching companies make is building AI in-house without anyone who's shipped a hallucination-mitigation layer before," says Eugene Sandugey, founder of Elevated Signal. "AI models hallucinate. They sound confident doing it. If nobody on your team has built a system designed specifically to catch that, the first time it happens in front of customers is the first time anyone realizes the layer was load-bearing. Going external for that one layer is cheaper than learning it the public-incident way."
The expertise isn't in the model — it's in the harness around it. And you only learn what that harness needs by watching one fail.
External Partners Ship AI Projects Where Internal Builds Stall
The clearest current data on the build-versus-buy question comes from MIT's NANDA initiative. Its GenAI Divide: State of AI in Business 2025 report analysed roughly three hundred publicly disclosed AI deployments alongside 150 leadership interviews and found that only about 5 percent of enterprise pilots produced rapid revenue lift; the rest stalled. Solutions built with external partners reached production at roughly three times the rate of internally built ones. The driver of the in-house failure rate is rarely budget or geography. It's prior AI fluency, measured in scar tissue.
Ritwick Dey, CTO of Panto AI, has tracked the gap across his engagements: "Teams that engaged external ML specialists because they lacked data pipelines and SRE capacity shipped model-backed features in around three months versus nine to twelve months in-house. Measurable differences included a 2× reduction in false positives and a faster adoption curve among engineers."
Incentive structures reinforce the gap. External teams operate with defined deliverables and reputational accountability — conditions that sharpen decision-making in ways that diffuse internal ownership often doesn't.
The exception is the organization that already sits at the intersection of deep domain knowledge and lived AI experience — sometimes a single person carrying both. A founder who codes AI-paired through every build cycle, sitting on two decades of operational quirks, can outpace any external partner. The institutional context is the moat; AI lowers the cost of acting on it.
That combination is uncommon. Most organizations have one or the other. In those cases, partnership isn't a fallback — it's the faster route to both.
As AI lowers the cost of building, the bottleneck shifts. Development capacity is no longer the scarce resource. What's scarce is the domain understanding deep enough to build the right thing.
Sharpen the Question, Not Skip It
The instinct, when bringing in outside help, is to picture it as execution outsourcing: internal teams own the strategy, external teams write the code. Reality is messier — and better.
The most common in-house mistake isn't insufficient technical capacity. It's starting with the tool instead of the problem. Organizations buy a chatbot, plug it in, and wonder why nothing changed.
A subtler version of the same failure: teams that do identify the right problem still struggle to describe it with enough precision for AI to act on. The gap between a business intuition and a working specification is wider than most expect before they've tried to close it.
Good external work doesn't bypass the internal conversation about what to build. It structures and accelerates it. The first task of a serious AI engagement is converting a vague business intuition into a concretely defined operational problem — which workflow is changing, against which KPI, with what acceptance thresholds. Strategic intent and domain context stay internal. The methodology to translate them into a working system is what the partnership adds.
AI lowers the cost of execution. It does not lower the cost of judgment.
AI Project Handoffs Lose More Than Code
AI systems aren't static software. Models drift, data distributions shift, output quality degrades unless someone is actively calibrating against it. The institutional knowledge that keeps such a system healthy isn't in the codebase or the documentation — it's in the heads of the people who built it. Why this architecture. Why this mitigation layer. Why these acceptance thresholds.
Hand the system to a team without that history and you don't lose code; you lose the reasoning that made the code right. The McKinsey State of AI survey from November 2025 makes the corollary visible at scale: among the 88 percent of organizations that now use AI, only 39 percent report any EBIT impact at all, and the single strongest predictor of being in that minority is having redesigned end-to-end workflows before selecting modeling techniques. That redesign — the operational reasoning that anchored the model in the business — is exactly the knowledge that vanishes in a poorly managed handoff.
Who Ships AI Projects, and Who Quits
The temptation, reading the failure data, is to treat the decision as ideological — build for control, buy for speed. The honest read is different.
If an organization already has both — operational depth in the domain and people who have shipped AI systems before — internal builds are legitimate, often the better path. If one of those is missing, the question isn't whether to involve outside help. It's whether the missing competence is best acquired by spending years learning, or by working alongside people who already have it.
AI is the fastest tool ever built for building AI. But it doesn't start by itself, and it doesn't decide when to stop. The teams that ship are the ones who already know where to point it.