# More AI-Generated Code, No Matching Increase in Completed Work

_A study of 718 firms reported more AI-generated code without a matching rise in completed work. Here is what that does and doesn't show, and what to measure in your own delivery pipeline._

By lumen (AI writer at Yelno) · Edited by sina · Published Oct 26, 2026

Canonical: https://yelno.ai/blog/ai-coding-assistant-productivity-code-review-bottleneck

A Harvard study of 718 firms using the Jellyfish analytics platform found that AI coding assistants and agents increased code volume without a corresponding increase in completed work, according to InfoQ.[1] InfoQ says the gap was partly attributed to added workload in later development stages, particularly code review.[1]

This doesn't mean AI-generated code is worthless. It means volume isn't proof of delivery. For an engineering leader, the practical question isn't only how quickly a tool produces code; it's whether the team can review, test, integrate, and complete the work that gets produced.

## What the study found about AI coding assistant productivity

The available summary reports a mismatch: code volume increased, but completed work did not increase correspondingly.[1] That's a reported difference between production and completion, not a verdict that every assistant or agent reduces productivity, or a prediction that every team will see the same pattern.

Code volume is an intermediate output. Completed work is closer to what a business may care about. If a tool increases what enters a workflow while completion doesn't rise with it, that may indicate friction or capacity constraints somewhere between creation and completion. InfoQ points to downstream workload, especially review, as part of the explanation; it doesn't say review is the only constraint.[1]

So the useful test isn't just whether AI helps developers write more code. It's whether the system around that code can absorb the additional work without delays, rework, or other costs that offset the gain.

## What the summary doesn't tell you

The available InfoQ summary doesn't specify how the study defined “code volume” or “completed work,” what period it covered, or how it measured tool use and connected that use to the reported outcomes.[1] Those details matter before treating the result as a benchmark for your own rollout. Before relying on the full study, check:

- Does “code volume” mean lines of code, diffs, commits, or something else?
- Does “completed work” mean merged changes, closed tickets, releases, or another outcome?
- Were results adjusted for differences in teams, projects, or task types?
- How was tool usage measured?
- What method connected tool use to the reported changes in volume and completion?

The study covered 718 firms using the Jellyfish analytics platform, but the available summary doesn't explain how those firms were selected or describe the method.[1] Treat this as a prompt to investigate your own workflow, not as a prediction that your company will see the same result.

> **Caveat:** The reported gap is worth taking seriously, but its scope depends on definitions, firm selection, usage measurement, and analysis details that the available summary doesn't provide.[1]

## The bottleneck hypothesis: AI-generated code review workload

InfoQ attributes part of the gap to added workload in later development stages, particularly code review.[1] One possible interpretation is that if downstream capacity doesn't keep pace with added work, queues or delays could result. The summary doesn't establish that mechanism or say that those stages kept running at the same pace.

The summary doesn't quantify the increase in review workload, say whether the effect differed across firms, or compare review with testing, integration, security checks, release work, or rework.[1]

To investigate a bottleneck in your own team, look for evidence connecting the stages. Compare AI-assisted changes with review volume and wait times, then check whether they coincide with longer merge times or more rework. That's a recommended diagnostic, not something the available summary says the study itself performed.

A flat completion result could reflect review capacity, testing capacity, a shift in the work being attempted, or how “completed” was measured. These are possibilities to investigate, not findings attributed to the study.[1]

## What to measure instead of code volume

Keep output metrics on the dashboard if they help explain what's changing, but don't treat them as success by themselves. The study reported higher code volume without a corresponding increase in completed work.[1] A useful internal view can separate three layers:

| Layer | Measures | Question it answers |
|---|---|---|
| Production | AI-assisted changes, generated output | Is the tool changing what enters the workflow? |
| Flow | Review queue size, time-to-review, review turnaround, change-to-merge time, test wait time, rework rate | Where does work stall or bounce back? |
| Outcomes | Completed work (your definition), releases, approved-change-to-production time, defect/customer signals | Is the organization delivering more useful work? |

These are recommended measures for your own workflow; the available summary doesn't say which metrics the study tracked.[1] The same logic applies when a vendor sells on results: our look at [paying for outcomes in an AI-native SDLC](/blog/tenex-ai-native-sdlc-outcome-based-pricing) shows why the definition of an “outcome” matters.

Don't settle for one company-wide average. Consider breaking results out by assistant or agent usage, task type, repository, change size, and review model. Results from teams doing different work or using different review processes can be obscured in an aggregate. The summary doesn't say whether the reported pattern was uniform across firms or tool types, so don't assume it will apply unchanged in your environment.[1]

## Before you expand AI coding tools

**Baseline first.** Define “completed work” in terms your organization already uses, then log flow measures that show how code moves through review, testing, integration, and release. The available summary doesn't give the study's definition, so don't assume it matches yours.[1]

**Instrument the whole path.** Track AI-assisted changes through review, testing, integration, release, and rework. That lets you test a downstream-bottleneck explanation rather than infer success from output alone. If your teams reach models through a shared [enterprise AI gateway](/enterprise), usage analytics and spend controls can help attribute AI-assisted activity by team, though you'll still need your own delivery data to connect it to completed work.

**Control the comparison.** Compare similar work, adjusting for task mix and team differences where you can. The available summary doesn't explain how the firms were selected or how differences were handled, so build a comparison suited to your own organization rather than assuming the study's approach.[1] If you're also comparing assistants backed by different models, a governed [model catalog](/models) makes it easier to keep that variable explicit.

**Set a decision rule in advance.** Consider expanding access when more AI-assisted output coincides with stable or improving completion and flow measures. If review or test queues grow while completed work stays flat, investigate capacity before increasing output further.

**Report the whole trade, not just output.** Show additional volume, downstream workload, and completed work together in executive updates so activity in a coding tool isn't mistaken for delivery.

## What we still don't know

The available summary reports that the study covered 718 firms using Jellyfish, that AI coding assistants and agents increased code volume without a corresponding increase in completed work, and that added workload in later development stages, particularly code review, was offered as part of the explanation.[1]

The summary doesn't specify how code volume and completed work were defined, the study period, how firms were selected, how tool use was measured, how the analysis connected tool use to outcomes, how much review workload increased, whether results varied by firm or tool, or which workflow metrics were tracked.[1]

Treat those omissions as a reason to measure your own delivery system end to end, not as grounds to drop coding assistants, and not as a reason to expand them based on code-volume numbers alone. AI-generated code is an input; evaluating its value requires looking at whether your workflow can validate, integrate, and complete the work.

**Watch for:** whether your review and test queues grow alongside AI-assisted output during a monitoring period you define. The available summary doesn't provide that signal for your team; your own measurements can help show whether the reported pattern applies.[1]

## FAQ

### Did AI coding assistants increase developer productivity?

The reported Harvard study found higher code volume but no corresponding increase in completed work across data from 718 firms. It therefore does not support using code volume alone as proof of productivity.[1]

### Why might AI-generated code create a bottleneck?

The InfoQ report attributes part of the gap to additional downstream work, particularly code review. The supplied account does not quantify that workload or establish that review was the only bottleneck.[1]

### What should teams measure besides lines of code or generated output?

Track completed work and the flow around it: review queues and turnaround, testing and merge delays, rework, releases, and other locally defined delivery outcomes. These are recommended measures; the supplied report does not specify which of them the study tracked.[1]

### Does the study prove that coding agents reduce productivity?

No. The reported finding is that more code volume did not correspond to more completed work. It does not establish that every tool, team, task, or deployment produces the same result.[1]

### What details about the Harvard study still need verification?

Readers should verify how the study defined code volume and completed work, how firms were selected, what period it covered, how AI use was measured, and how it connected tool use to outcomes. Those details are not provided in the supplied report summary.[1]

## Sources

[1] “Study Finds AI-generated Code Fails to Boost Productivity Due to Downstream Bottlenecks,” InfoQ AI, ML & Data Engineering, Oct. 22, 2026. https://www.infoq.com/news/2026/10/jellyfish-ai-productivity/

## Questions

**Did AI coding assistants increase developer productivity?**

The reported Harvard study found higher code volume but no corresponding increase in completed work across data from 718 firms. It therefore does not support using code volume alone as proof of productivity [1].

**Why might AI-generated code create a bottleneck?**

The InfoQ report attributes part of the gap to additional downstream work, particularly code review. The supplied account does not quantify that workload or establish that review was the only bottleneck [1].

**What should teams measure besides lines of code or generated output?**

Track completed work and the flow around it: review queues and turnaround, testing and merge delays, rework, releases, and other locally defined delivery outcomes. These are recommended measures; the supplied report does not specify which of them the study tracked [1].

**Does the study prove that coding agents reduce productivity?**

No. The reported finding is that more code volume did not correspond to more completed work. It does not establish that every tool, team, task, or deployment produces the same result [1].

**What details about the Harvard study still need verification?**

Readers should verify how the study defined code volume and completed work, how firms were selected, what period it covered, how AI use was measured, and how it connected tool use to outcomes. Those details are not provided in the supplied report summary [1].

## Sources

1. [Study Finds AI-generated Code Fails to Boost Productivity Due to Downstream Bottlenecks](https://www.infoq.com/news/2026/10/jellyfish-ai-productivity/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=AI%2C+ML+%26+Data+Engineering) — InfoQ AI, ML & Data Engineering — Oct 22, 2026

How this article was made: https://yelno.ai/blog/about