New Research from Harvard & Jellyfish: AI Is Making Developers Faster. So Where’s the Business Impact?

New research from Harvard Economics reveals a productivity paradox: AI coding tools are delivering on speed, but business outcomes haven’t caught up yet.

We’re excited to share a preliminary version of a new paper from our collaborators at Harvard Economics, Fiona Chen and James Stratton. Their study analyzed Jellyfish data covering 100,000 software engineers across 500 companies – making it one of the largest empirical studies of AI coding tools in real-world production environments.

The headline findings won’t surprise anyone who’s been paying close attention: AI is making coding faster, and code quality doesn’t seem to be suffering. These results are consistent with our own research and with what we’re hearing from engineering leaders across the industry.

But the more interesting finding is what isn’t happening yet.

The Productivity Paradox

Despite measurable gains in coding speed, the Harvard researchers found something striking: productivity improvements aren’t yet translating into the business outcomes that actually matter. The study found no significant increase in features shipped, and no observable shift toward higher-value work.

In other words, engineers are coding faster, but organizations aren’t necessarily delivering more value to customers.

This matches what we’re seeing in our own data and hearing in conversations with customers. The productivity story is real at the individual task level – developers are completing coding tasks more quickly, PRs are moving through pipelines faster, and cycle times are compressing. But scaling those gains to organizational outcomes is proving harder than many expected.

Why the Disconnect?

Every good engineer knows that optimizing one part of a complex system doesn’t automatically speed up the entire system. Software delivery is no exception.

A few factors may explain the gap:

• Coding isn’t the bottleneck. For many teams, the limiting factor on delivery isn’t how fast code gets written – it’s requirements gathering, design decisions, code review, testing, deployment, and coordination across teams. Making the coding step faster doesn’t help much if work is stuck waiting on upstream or downstream dependencies.
• Efficiency gains get absorbed. When individual tasks take less time, that capacity often gets redirected to other activities – additional testing, more thorough reviews, addressing tech debt, or simply taking on more complex work. These are valuable uses of time, but they don’t necessarily show up as “more features shipped.”
• Measurement lags behind adoption. Many organizations are still in the early stages of AI adoption, and it may simply be too soon to see effects on higher-level business metrics. Productivity improvements may need to compound over time before they show up in delivery outcomes.
• The work itself is changing. AI tools may be shifting the nature of engineering work in ways we don’t fully understand yet. Our previous research found that AI-assisted PRs contain 18% more code on average. If engineers are producing more robust, better-documented, or more thoroughly tested code, those quality improvements may not translate directly into “more features.”
• Companies are playing it safe. Many organizations are being cautious about where they deploy AI – pointing it at lower-risk work like bug backlogs and maintenance tasks rather than high-priority, customer-facing features. This is understandable from a risk management perspective, but it also means AI isn’t being applied to the work that most directly drives business value. To really unlock ROI, companies may need to take the leap and point AI at the work that actually matters—which inevitably comes with more risk.

What This Means for Engineering Leaders

The Harvard findings underscore what many engineering leaders are discovering firsthand: AI adoption is table stakes, but realizing ROI requires more than just turning on the tools.

For most tech companies, 2025 was about AI adoption and exploration – getting tools deployed, encouraging usage, and measuring basic productivity metrics. 2026 is about figuring out ROI: understanding where AI is delivering real value, where it’s falling short, and what organizational changes are needed to close the gap.

Here are a few questions worth asking:

• Where are your actual bottlenecks? If coding isn’t the constraint, speeding it up won’t move the needle. Map your delivery pipeline and identify where work actually gets stuck.
• How is AI changing the work? Track not just speed metrics, but also changes in code composition, complexity, and quality. Understand what engineers are doing with the time AI frees up.
• What organizational friction remains? Faster coding can expose bottlenecks elsewhere – in review processes, testing infrastructure, or cross-team coordination. Be prepared to invest there too.
• Are you measuring the right things? If you’re only tracking PR throughput and cycle time, you may be missing the bigger picture. Consider metrics that connect engineering activity to business outcomes.

The Path Forward

All of this reinforces that we’re still in the early stages of AI transformation. The productivity gains are real, and they matter – but the path from “faster coding” to “better business outcomes” isn’t automatic. It requires intentional effort to identify bottlenecks, invest in infrastructure, evolve how teams work, and ultimately be willing to point AI at the work that really matters.

This paper is an important contribution to our understanding of AI’s impact on software engineering, and we look forward to seeing how this research evolves as AI adoption matures across the industry.

Read the full paper here.

For more on AI’s impact on software engineering, check out our research on code architecture and AI productivity, AI adoption patterns, and the language effect on AI ROI.