AI-Assisted Development: Real Gains, Realistic Expectations

Over the past year, I have had several opportunities to work with AI-assisted development on both greenfield and brownfield projects. In small-team settings, the initial acceleration was undeniable; early progress came faster than anything we had seen before. But as the sprints progressed and more of the system took shape, I noticed a shift. More time went into review and debugging. Early design decisions made by the AI drifted from common industry best practices, requiring meaningful effort to work with the tools to refactor significant portions of the codebase. In some cases, the tools were over-eager, proposing broader changes than the task warranted, adding complexity rather than resolving it.

This pattern brought me back to the Pareto Principle, the idea that roughly 80% of outcomes come from 20% of effort. In software development, the first 20% of elapsed time tends to produce 80% of visible progress: the scaffolding is standing, the endpoints are responding, the UI is taking shape. It looks like the project is nearly done. The remaining 20% of visible progress — edge cases, integration, debugging subtle assumptions, finalizing architecture — consumes the remaining 80% of the timeline. These were exactly the areas where I was feeling the friction.

That experience raised a set of questions I wanted to explore more rigorously:

When AI compresses that first 80% of visible progress, what actually happens to the remaining 20%? Are the savings equally great? Do they disappear? Where does the work shift, and how much does team size matter?

I went looking for answers in the research. What follows is an honest account of what I found, and what it means for how we plan and invest.

Controlled studies confirm what I observed in the field: AI coding tools deliver genuine speed improvements on the mechanical work that dominates early development. Scaffolding, boilerplate, test stubs, data models, and documentation are where AI excels. And multiple independent studies report 30–55% speed improvements on scoped tasks of this type. [1] A large-scale randomized controlled trial across Microsoft, Accenture, and a Fortune 100 enterprise found a 26% increase in tasks completed across nearly 5,000 developers, with no measurable drop in code quality. [1]

For greenfield work in mainstream languages, the evidence is particularly strong, 25–40% productivity gains in well-controlled conditions, depending on task complexity. [1, 2] The case for investment is solid, and the early-sprint experience is not imagined. But the headline numbers require context.

The aggregate headline gain of 15–35% across a full project is a weighted average of large early-phase gains and near-zero (or negative) gains in the work that follows. Researchers describe this as the “70% problem.” AI handles boilerplate and scaffolding reliably, but struggles with the edge cases, error handling, and integration complexity that define production-quality software. [1]

The most striking data point comes from METR’s 2025 randomized controlled trial. Sixteen experienced developers worked in mature codebases they had contributed to for an average of five years. With AI assistance, their task completion time increased by 19%. The overhead of prompting, reviewing, and correcting AI output exceeded the time saved by code generation. [3] This mirrors the pattern I experienced. The tools were producing output faster than I could confidently validate it.

Planning to the aggregate gain without understanding where it comes from is the most common source of AI-related schedule overruns. Early velocity creates expectations that the second half of the project cannot sustain.

Greenfield and brownfield represent fundamentally different environments for AI tooling. Greenfield work (new projects, popular languages, no legacy constraints) gives AI optimal conditions. The research reflects this: 30–40% gains in low-complexity greenfield contexts drop to 0–10% in high-complexity brownfield work and sometimes go negative. [3]

In brownfield systems, AI tools can only work with what you show them. They have no visibility into the institutional knowledge, implicit contracts, or accumulated decisions holding a mature codebase together. Early design choices drift from established patterns. Suggestions compile but break things elsewhere. Researchers call this context rot, a degradation in AI output quality that occurs as the tool's context window (the fixed amount of code and conversation it can hold in view at once) fills with project-specific complexity, leaving it with an increasingly incomplete picture of the system it is modifying. The result: changes that look correct in isolation but break things elsewhere in ways that are not always immediately visible. [1]

One counterintuitive finding: a well-architected brownfield codebase can give AI more to work with than a blank slate. Consistent patterns and documented conventions guide the tools toward coherent output. The practical implication:

Investing in codebase legibility before AI adoption multiplies returns. [4]

My own experience was in small-team settings, and the research suggests that is where AI’s gains are most likely to reach actual delivery. The LeadDev AI Impact Report 2025, surveying 883 engineering leaders, found that 59% of teams with fewer than five engineers reported productivity improvements exceeding 10%, the strongest result of any cohort. [1]

The mechanism is structural. In a small team, coding represents a larger proportion of each person’s day, so AI’s gains on the coding step translate more directly into project velocity. In larger teams, Brooks’s Law is already absorbing significant time in coordination, meetings, and review loops. AI does not compress those activities, so its coding gains are partially (sometimes entirely) absorbed before they reach delivery outcomes.

The Faros AI analysis of over 10,000 developers across 1,255 teams puts numbers to this: high AI adoption teams completed 98% more pull requests, but review time rose 91% and bugs increased 9%. Organizational delivery metrics were flat. [5] That 91% rise in review time is the primary hidden cost, the mechanism that traps teams in a state of high activity but stagnant delivery, absorbing the coding gains before they reach the customer. A two-person team shipping more PRs moves faster. A ten-person team shipping more PRs creates a review backlog that the speed gain never escapes.

Drawing the evidence together, the table below offers directional planning ranges by context. These are not guarantees. Treat the upper bounds as achievable with structured AI practices and clean codebases, and the lower bounds as the conservative floor for complex or brownfield work.

• Invest in codebase legibility before AI tooling. Documented architecture and consistent conventions give AI the context it needs to produce coherent output, and limit the pattern drift I experienced firsthand.
• Plan for phase-specific velocity, not average velocity. Communicate clearly to stakeholders that early milestones will arrive faster than history suggests. Later milestones will not compress at the same rate. Setting this expectation early protects delivery credibility.
• Scale review alongside coding. AI increases PR volume and size. Without proportional investment in review capacity (including AI-assisted review tooling) delivery metrics stagnate regardless of individual speed gains.
• Measure delivery, not activity. Commits, PRs, and lines of code all inflate mechanically with AI usage. Cycle time, defect escape rate, and deployment frequency tell the real story.

Bottom line: AI-assisted development is a genuine competitive lever, and the investment case is strong,  particularly for small teams and greenfield work. The early-sprint acceleration is real and repeatable. What the research confirms, and what I observed directly, is that the gains are front-loaded. The second half of any project still demands the judgment, domain knowledge, and architectural thinking that remain distinctly human. Plan for both halves.

A note on the evidence

AI tooling in software development is genuinely new, and the research base is still forming. The studies referenced here span 2024–2026 and include some of the most rigorous work currently available: randomized controlled trials, large-scale telemetry analysis, and multi-company surveys. But they measure different tools, different team compositions, and different definitions of productivity. No individual number should be treated as a settled benchmark. This body of evidence offers consistent directional signals: where AI helps most, where it tapers, and where organizational dynamics absorb the gains before they reach delivery. The field will sharpen these numbers. For now, they are early observations; consequential enough to act on, but held with appropriate humility.

References

• Addy Osmani. The Reality of AI-Assisted Software Engineering Productivity. Primary synthesis of multi-company RCT, METR, Faros AI, Google RCT, Stack Overflow 2025, and LeadDev AI Impact Report data. https://addyo.substack.com/p/the-reality-of-ai-assisted-software (August 2025)
• Stanford Software Engineering Productivity Research Group. Ongoing study of 120,000+ developers across 600+ organizations. Portal: https://softwareengineeringproductivity.stanford.edu — Findings presented by Yegor Denisov-Blanch, AI Engineer Conference 2025.
• Becker et al. / METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (July 2025). https://arxiv.org/abs/2507.09089
• Strom Capital. Why AI Works Better on Existing Codebases (January 2026). https://www.stromcapital.fi/blog/brownfield-advantage
• Faros AI. AI Software Engineering Productivity Research (2025-2026). Primary telemetry study of 10,000+ developers across 1,255 teams. https://www.faros.ai/blog/ai-software-engineering