Artificial Intelligence in the Firm: Bottlenecks in Software Production — Summary (October 31, 2026)

Authors: Fiona Chen and James Stratton
Institution: Harvard University, as stated in the authors’ affiliations
Study version analyzed: October 31, 2026, 120 pages
Synthesis revision: Version 2, November 1, 2026
Publication status: Academic manuscript identified as a Job Market Paper; the document consulted does not report publication in a journal or establish that it has undergone peer review
Original source: Current address of the PDF made available by the author

This article is an editorial synthesis of the study by Fiona Chen and James Stratton, developed in stages and revised with support from ChatGPT 6.1 Sol Extra High. Authorship of the original research and its results belongs entirely to the researchers. This text is not an official publication of Harvard University or of the study’s authors.

The results and page references in this synthesis refer to the October 31, 2026 copy. The author’s URL can be updated and may display a later version.

AI Produces More Code. Why Does Software Output Grow Less?

An analysis of Fiona Chen and James Stratton’s study of assistant and agent adoption, the constraints on code review, and the difference between accelerating tasks and expanding firm output.

The adoption of artificial intelligence in software engineering brings two different questions into the same discussion. The first is how much more code a team can produce. The second is how much of that work becomes completed, validated software available for use. A positive answer to the first does not, by itself, determine the answer to the second.

Fiona Chen and James Stratton investigate this transition from activity to output at real firms, tracking records of development, issue management, code review, and employment. The study’s central contribution is to examine complementary stages of the production process rather than assessing only a tool’s performance on an isolated task.

The results are consistent with substantial gains in coding capacity, particularly when measured through commits and code submissions for review. However, the estimated increases in completed work are smaller and statistically uncertain. Review takes longer after agent adoption, while the data do not identify a statistically detectable change in aggregate engineering employment attributable to the tools over the observation window.

This matters for investment decisions because code generation capacity is an input into software production. It does not directly measure revenue, customer utility, or financial returns. To understand AI’s organizational effects, the study follows what happens after the code is written.

Contents

1. The study from an executive perspective
2. What the data represent
3. How the study identifies the effects of adoption
4. More code, more submissions, and smaller gains in software output
5. The code review bottleneck
6. The quality of submitted code and final software
7. How work changes and where effects differ
8. What was observed about employment
9. The economic model of bottlenecks
10. What the calibration allows us to infer
11. Firm adjustment and future scenarios
12. What the study does not establish
13. Implications for technology management
14. Conclusion
15. Bibliographic reference

Page references indicate positions in the 120-page PDF, counting the title page as page 1. Unless otherwise specified, “Figure” and “Table” refer to the main figures and tables; supplementary material is identified as being in “Appendix D” or “Appendix E.”

1. The study from an executive perspective

The study distinguishes two generations of tools. Assistants provide suggestions and answers during coding. Agents execute longer sequences of actions semi-autonomously in response to an instruction. The analyses use different windows: up to 16 months after assistant adoption and up to 12 months after agent adoption.

Six findings guide the discussion.

• Intermediate output increases. In the final month of each window, assistant adoption is associated with estimated increases of 25.5% in commits and 25.2% in pull requests opened per worker. For agents, the estimated additional increases are 36.0% and 35.7%. These effects are statistically significant at the 5% level.
• Gains in completed work are smaller. The estimates are 2.0% for issues and 1.7% for epics with assistants; for agents, they are 13.7% and 18.0%. None of these final-month estimates is statistically significant at the 5% level.
• There are gains beyond review. Pull requests actually merged into the codebase also increase: 24.0% with assistants and 26.0% with agents. Review therefore does not prevent all output growth.
• Review takes longer with agents. The interval between opening and merging a pull request increases by 56.1% in the month-12 estimate. Both the wait until the first human comment and the subsequent interval until merge increase.
• No change in aggregate engineering employment is detected. The uncertainty intervals still allow economically meaningful changes; the finding does not establish that the true effect is exactly zero.
• The long-run scenarios are conditional exercises. They depend on the evolution of review capacity, demand for software, and assumptions about firm adjustment. They are neither observed outcomes nor probabilities assigned to the future.

Sources: Sections 4–6, pp. 27–46; Figures 6–13, pp. 54–61; Appendix D, Figure 10, p. 81.

A crucial distinction: The effect of agents is estimated relative to a situation in which firms were typically already using assistants. The two columns of results do not constitute a simultaneous comparison of technologies under identical conditions. Nor should their percentages be added to claim an observed cumulative gain.

2. What the data represent

2.1 Records of firm activity rather than a laboratory experiment

The primary source is Jellyfish, a platform that integrates data firms use to monitor their engineering teams. The study uses data from customers who authorized its use for scientific research and met the conditions required for analysis.

The dataset described covers 655 firms and 720,542 workers, from January 2021 to August 2026. The reference to approximately 445 million events combines different types of records. It does not mean 445 million independent experimental observations or 720,542 programmers using AI simultaneously.

Table 1 reports version control and issue management coverage for all firms in this dataset. Calendar data are available for 192 firms, or 29.3% of the sample. HR data exist for only some workers. The authors supplement these sources with professional profiles and firm characteristics obtained through Revelio Labs.

These totals describe the body of data presented in the manuscript. Each estimate uses the records relevant to the outcome, technology, observation window, and coverage requirements. The document does not provide a complete count of firms, workers, and observations for each regression. It would therefore be incorrect to assign the totals of 655 firms and 720,542 workers automatically to every result.

Sources: Section 2, pp. 8–13; Tables 1–3, pp. 62–64.

2.2 Which firms and workers are represented

The firms are predominantly established, medium-sized or large organizations. In January 2023, the average firm had approximately 1,677 workers overall, according to Revelio, and 249 active workers in Jellyfish. The average firm age was 19.4 years. Dispersion is substantial, with a tail of much larger firms.

The sample includes firms that sell software licenses, digital service providers, and organizations that develop software as an input into their own operations. The study is therefore not limited to enterprise software vendors, although that setting has a substantial presence.

In the available occupational classification, 76.6% of workers are in software engineering. The remainder includes data and research, product and design, other engineering roles, and administrative or commercial functions. The total worker count should not be presented as if all workers were developers.

The diversity of firms broadens the organizational relevance of the findings. Even so, the sample is not random: it consists of customers of an engineering analytics platform who consented to research use and have the required integrations.

2.3 From code to software output: what the measures mean

A commit saves a change. A pull request, or PR, submits a set of changes for review. A merge integrates the changes into the shared codebase. Integration does not necessarily mean that the feature is already in production.

The authors interpret issue and epic resolution as a proxy for work completed and made available, supported by the practices described in the systems and interviews. This interpretation is closer to the final outcome of development than a commit count, but it still depends on how firms maintain their records.

An issue may also represent a bug fix or another technical task. Thus, “issues resolved” is not synonymous with “new features,” and neither expression automatically measures economic value.

Sources: pp. 9–11 and 26–27; Figure 1, p. 49.

2.4 Interviews and supplementary data

The paper includes qualitative interviews with 21 professionals in engineering, engineering management, product, and related areas. These help interpret tool procurement and organizational mechanisms. They are not a representative sample from which to estimate the prevalence of experiences or problems.

The authors also report a survey of 100 engineers recruited through Prolific, used to compare self-reported time allocation with the allocation imputed from work records. These 100 participants should not be confused with workers in the Jellyfish panel.

The manuscript reports financial support from programs associated with Stripe, Harvard Kennedy School, and Schmidt Sciences. It also states that Jellyfish reviewed the document to verify that it did not disclose proprietary information, rather than to assess its scientific content. This contractual review is not equivalent to academic peer review.

Sources: p. 1; pp. 11 and 36; Appendix C, pp. 68–71.

3. How the study identifies the effects of adoption

3.1 Difference-in-differences with staggered adoption

Comparing a firm before and after AI adoption would be insufficient: it might have been growing for other reasons. Comparing adopting and nonadopting firms at a single point in time would also be insufficient because they may have differed from the outset.

A staggered difference-in-differences design seeks to combine both comparisons. Firms adopt the tools in different months; the trajectories of earlier adopters are compared with those of firms that had not yet adopted. The analysis is organized into firm-month observations, with effects reported in months relative to adoption.

The main specification incorporates:

• permanent firm characteristics through firm fixed effects;
• conditions common to each month through calendar-time fixed effects;
• controls allowing different trajectories related to initial firm size;
• controls for the expansion of data coverage after firms join Jellyfish.

Standard errors are clustered at the firm level, consistent with the level at which adoption is defined. The size of the event dataset does not eliminate uncertainty across firms.

The event studies follow eight months before adoption and up to 16 months afterward for assistants or 12 months for agents. Unless explicitly stated otherwise, the estimates highlighted in this article’s tables correspond to the final month of each window.

Sources: Section 4.2, pp. 27–29.

3.2 What must hold for a causal interpretation

The central assumption is parallel trends: absent adoption, firms adopting at different times would have followed comparable trajectories in the outcomes analyzed, conditional on the controls.

The authors argue that differences in the time required for evaluation, procurement, legal approval, security review, and piloting generate variation in adoption timing that may be weakly related to production trajectories. The interviews describe processes ranging from rapid approval to several months.

This is a rationale for the design, not randomization. Larger firms adopt earlier, which motivates the size controls. Preadoption coefficients and robustness checks help assess the plausibility of the comparisons, but they do not establish that every unobserved factor has been eliminated.

Simultaneous changes in management, staffing, or strategy remain a potential concern. A causal interpretation must remain conditional on the design’s assumptions, even when the findings appear intuitive.

3.3 How adoption is identified

For assistants, the adoption date combines the first signals of enterprise license activation for GitHub Copilot and Cursor. For agents, the researchers combine the Claude Code integration with traces in bot accounts, commit messages, and PR descriptions. Review tools are identified through their own signals.

This procedure provides broader coverage than reliance on a single API. It does not, however, observe all usage: an individual license, an unintegrated tool, or use without a recognizable signature may escape detection.

The first observed adoption also does not imply intensive use across the entire team. In Figure 5, the estimated coefficients for the individual adoption rate are +37.58 percentage points at month 16 for assistants and +35.30 percentage points at month 12 for agents, among workers already coding in the reference window. They represent estimated increases within this fixed cohort, not a direct count of users among all workers in the dataset. Nor can the observed rate in the corresponding month be reconstructed by mechanically adding the coefficient to the baseline mean, because the counterfactual trajectory must also be considered.

Firm adoption rates are similarly limited in scope. In July 2026, the authors identify agent adoption at 98.3% of the firms included in that measurement. This does not represent the adoption rate among all firms in the market.

Sources: Section 2.4, pp. 13–17; Figure 5, p. 53; Appendix F.1, pp. 99–101.

3.4 Robustness and per-user estimates

Regressions with firm and time fixed effects can produce problematic comparisons when adoption is staggered and effects vary across groups and periods. The study compares its main estimate with four alternative approaches developed to address this problem.

This exercise, focused on the effect of agents on lines of code, yields similar patterns and magnitudes. Other specifications vary the comparison group, controls, panel composition, and measurement per worker or at the firm level. The final estimated effect on lines per worker ranges from 38.3% without the controls to 73.8% in the balanced panel; the main specification reports 44.0%. Measurement of firm-level totals yields 77.6%.

The direction of the result is relatively persistent across these exercises, but its magnitude is not invariant. Moreover, robustness demonstrated for lines of code does not automatically validate every employment or review result.

The authors also use firm adoption as an instrument for individual adoption. The aim is to estimate per-user effects, distinguishing tool diffusion from other changes over time. The final estimates for lines of code are large, at 161.8% for assistants and 172.1% for agents, but imprecise and not significant at the 5% level.

The individual-level interpretation requires a strong additional assumption: firm adoption would affect a worker’s output only through that worker’s own use of the tool. The study itself acknowledges that this may fail when colleagues who do not use AI receive more code to review. Underdetection of users may also inflate the effect attributed to each observed user.

There is also an inconsistency in how the first stage of this analysis is presented: for assistants, the body of the manuscript reports adoption by 22.02% of active workers at month 16, while the caption of Appendix D, Figure 5 reports 0.251, or 25.1%. This discrepancy is separate from the change in denominator relative to the cohort of coders in the main Figure 5. The documentation does not allow it to be fully reconciled. The effects of 161.8% and 172.1% are retained as estimates reported by the authors; they have not been recalculated by selecting one of the rates or through a simple division, which would not reproduce the full instrumental variables specification either.

These numbers should not be read as a proven gain in individual productivity applicable to any developer. Nor does the study find a clear time pattern that would separate learning, improvements in models, and changes in the composition of adopters.

Sources: Sections 4.4–4.5, pp. 31–33; Appendix D, Figures 4–5, pp. 75–76.

4. More code, more submissions, and smaller gains in software output

4.1 The main quantitative findings

Percentages reported by the authors relative to the preadoption mean in each analysis. The absolute values and means printed in the manuscript are rounded; recalculating percentages from them may produce small differences. The columns use different treatments, periods, and reference points.

Sources: pp. 29–34; Figures 6–7, pp. 54–55; Appendix D, Figure 10, p. 81.

Lines of code draw attention, but they are a noisy measure, sensitive to the length and style of implementations. Evidence of increased intermediate output does not rest on them alone: commits and PRs opened also increase, with more precise estimates.

For agents, the final-month effect is approximately 9.51 additional commits per worker-month, against a baseline mean of 26.43, and 1.73 additional PRs, against a mean of 4.83. For assistants, the corresponding values are 4.73 commits, against 18.55, and 0.888 PRs, against 3.52.

These measures do not establish that every unit has the same utility or complexity. They indicate that productive activity expanded across more than one measure.

4.2 What a nonsignificant effect of 13.7% means

For issues resolved after agent adoption, the final-month estimate is 0.350 additional issues per worker-month, with a standard error of 0.220, against a baseline mean of approximately 2.55.

The point estimate is positive. Uncertainty is nevertheless sufficient for a 95% confidence interval to include zero. The authors report that they can rule out increases greater than 30.7% in this outcome. This limits interpretations involving very large gains without establishing that the true effect is zero.

For epics, the estimate of 18.0% is also imprecise; the reported upper bound is 41.5%. The clearest quantitative constraint on software output growth therefore applies to issues, rather than indiscriminately to every concept of final output.

There is a further statistical distinction: a significant estimate for PRs and a nonsignificant estimate for issues do not, by themselves, constitute a test of the difference between the two effects. The study’s argument combines estimated magnitudes, uncertainty intervals, code integration, and evidence from the review process.

Source: Section 4.6, pp. 33–34.

4.3 Gains beyond review and work not yet merged

Merge counts provide evidence against the interpretation that all additional code remains blocked. With assistants, growth in merged PRs, at 24.0%, is close to growth in PRs opened, at 25.2%.

With agents, growth in merges, at 26.0%, is smaller than growth in openings, at 35.7%. The authors compare the absolute effects and calculate a ratio of approximately 62.7% between additional merges and openings, against a baseline ratio of 86.1%.

This ratio relates estimates of aggregate flows. It does not follow an individual cohort of PRs to their eventual outcomes and does not establish that the remaining PRs were rejected or useless. Some may still be pending at the end of the observation period.

In addition, software can be merged before it is deployed. The difference between merges and issues resolved preserves the relevance of subsequent stages or other requirements for completing a task.

Source: p. 30; Appendix D, Figure 10, p. 81.

4.4 The final month and the period average are not equivalent

The most frequently cited percentages refer to the ends of the windows. They do not describe a constant average gain throughout the first year.

For agents, Figure 6 reports a pooled effect over the period of 0.79 additional PRs per worker-month, compared with 1.73 at month 12. For issues, Figure 7 reports a pooled effect of 0.16, compared with 0.35 at month 12.

The difference may reflect the gradual expansion of use within firms and other dynamic components. The instrumental variables analysis does not isolate a clear increase in the per-user effect over time. The full progression therefore cannot be attributed to learning or technological improvement.

Sources: pp. 32–33; Figures 6–7, pp. 54–55.

5. The code review bottleneck

5.1 Three different intervals

Review connects submitted code to code accepted into the shared codebase. The study distinguishes the total interval until merge and two components proxied through human comments.

Sources: Section 5.2, pp. 37–38; Figure 10, p. 58.

“Active review” is an elapsed interval, not a measure of hours of continuous reviewer attention. Between the first comment and merge, the author may make corrections, further interactions may occur, and there may be waiting and other activities.

The first comment is also an observable proxy for the start of review. A worker may read code without commenting immediately. The measure does not directly record every moment at which someone begins examining a PR.

All three increases in the table are statistically significant at the 5% level. Their values should not, however, be added: total time covers a broader set of PRs with observed merges, while the decomposition depends on PRs that received a comment. The baseline means are 3.56, 2.78, and 3.98 days, respectively. The difference in samples explains why the published components do not reconstruct the overall mean.

5.2 More arrivals, constrained capacity, and greater effort

The mechanism investigated has two parts.

First, higher output sends more code into review. If reviewer capacity does not grow at the same pace, the backlog increases. This channel can arise even without a deterioration in the quality of submitted code.

Second, submissions may require more iterations of verification and correction. In that case, effective review capacity falls: the same review work produces fewer approvals per unit of time. Waiting may increase further.

The combination of more time until the first comment and more time after the first comment is consistent with these two channels. It does not identify each cause perfectly, but it provides more specific evidence than simply observing a longer total interval.

The stock of open PRs also increases in Figure 10. This finding complements the evidence of congestion without, on its own, revealing the utility or difficulty of each accumulated change.

5.3 What comments and requested changes show

Following agent adoption, the final-month estimates indicate:

• 0.629 more comments per PR, with a standard error of 0.221, equivalent to 38.6% of the mean of 1.63 comments; significant at the 5% level;
• a 4.61-percentage-point increase in the share of PRs receiving a comment, with a standard error of 3.06 percentage points, against a mean of 35.17%; a relative increase of 13.1%, not significant at the 5% level;
• a 1.07-percentage-point increase in the share of PRs formally blocked by a request for changes, with a standard error of 0.751 percentage points, against a mean of 2.77%; a relative increase of 38.5%, not significant at the 5% level.

The distinction between percent and percentage points is material. The share of blocked PRs does not increase by 38.5 percentage points: the estimated effect is approximately one percentage point on a small baseline.

Comments may also record questions, style requirements, documentation, integration issues, or implementation preferences. The convergence of these measures is consistent with greater review effort and a possible deterioration in the submitted input, but it does not turn every comment into a confirmed defect.

For assistants, the study does not find the same increase in total duration, waiting time, and time after the first comment. This prevents treating all AI use as if it produced the pattern observed with agents.

Sources: pp. 37–38; Figure 10, p. 58; Appendix D, Figure 11, p. 82.

5.4 Why any worker cannot simply be reassigned to review

Review depends on localized knowledge. In 82.8% of observed reviews, the reviewer had previously made commits or opened PRs in that codebase. In the authors’ comparison exercise, which assigns reviews to random PRs from the same firm and month, that familiarity would be 17.2%.

Seniority also appears in the division of work: senior workers perform 75.7% of reviews of PRs written by seniors, compared with 32.8% of reviews of PRs written by juniors.

These statistics are descriptive, not effects of AI. They support the idea that substitution between coding and review faces constraints related to experience and familiarity. They do not establish that juniors are incapable of reviewing or define a universal approval rule.

Source: Section 5.1, pp. 36–37; Figure 9, p. 57.

5.5 AI review already exists, but adoption does not mean full coverage

In July 2026, 79.1% of firms had used AI review tools. However, 23.3% of review comments were AI-generated, and 10.8% of PRs received at least one AI comment.

The three percentages have different denominators. None directly measures the share of all code actually examined by AI, the depth of that examination, or the share of automated approvals.

The study shows that adoption of review tools coexisted with substantial human participation and the observed bottleneck. In this section, it does not present a causal experiment isolating the effects of those tools on review. The findings therefore do not establish that AI review is ineffective or that a future generation of these tools will eliminate the constraint.

Source: Section 5.3, p. 39; Figure 11, p. 59.

6. The quality of submitted code and final software

The study does not observe the full contents of commits. Its assessment of submitted code quality relies on process signals: comments, requests for changes, and time until review completion. The authors interpret these signals together as consistent with deterioration in the input reaching reviewers.

The quality of final software is examined separately through the number of bugs reported in Jira per worker. This measure shows no statistically significant change after assistant or agent adoption.

The final-month estimates are −0.122 reported bugs per worker-month for assistants, with a standard error of 0.078, and −0.062 for agents, with a standard error of 0.150. The point estimates are negative, but they do not justify announcing a proven improvement in quality.

This finding matters because it runs counter to the interpretation that more review comments prove more failures in delivered software. Review may catch problems before deployment; there are also limits to what bug reports can capture. The study does not identify these possibilities as a causal decomposition of quality.

The authors also examine whether comments increased simply because PRs became larger. They find no significant change in the average number of lines added per PR. This weakens a simple mechanical explanation, but it does not measure every dimension of a change’s complexity.

Nor are detectable changes found in the proxies for issue size. These proxies use text descriptions classified by AI and models trained on preadoption data. The absence of a change in these measures does not certify that every task retained the same difficulty or value.

The scope of the evidence: There are signs of greater effort to review agent submissions; there is no demonstration of increased defects in production, reduced security, or a general deterioration in architecture.

Sources: Section 4.6, pp. 33–34; p. 38; Appendix D, Figures 8–9 and 12, pp. 79–80 and 83.

7. How work changes and where effects differ

7.1 Coding occupies only part of the workday

Before examining technological change, the study estimates the composition of work. In the imputation based on Jellyfish records, coding accounts for 40.8% of time; review, 17.7%; and the broad management category, 41.5%. In the survey of 100 engineers, the self-reported percentages are 30.8%, 21.8%, and 47.4%, respectively.

The imputation maps work signals to categories and assigns each signal the interval since the preceding one, capped at two hours. It does not function as a stopwatch for activities. The management category also includes planning and other interactions; it does not correspond solely to work performed by people with management titles.

Despite differences between the two sources, both show that coding occupies only part of the workday. A tool that accelerates that portion does not automatically multiply capacity across all other activities.

The study does not detect a meaningful change in the total number of meetings per worker. Estimates for meetings identified as review-related are positive but imprecise. Calendar coverage is partial, and identifiable review meetings are rare. This measure therefore does not establish that time allocation remained unchanged.

Sources: pp. 36–38; Figure 9, p. 57; Appendix D, Figure 17, p. 88.

7.2 Baseline activity, seniority, and technical role

Relative effects on code output are larger among workers with less coding activity before adoption. This does not mean that AI benefits less-skilled workers more: a lower initial number of PRs may reflect roles involving more management or review.

The effects are somewhat larger among seniors, who initially coded less, but the difference by seniority is small and not significant. There is little systematic variation across roles such as front-end, back-end, and other technical specialties.

There is also little heterogeneity in review outcomes by the characteristics of the code’s author. The study therefore does not establish a simple division in which one group produces all the additional code and another absorbs all the cost.

The comparisons are percentages relative to each group’s baseline mean. A larger relative increase from a smaller base does not establish a larger absolute increase. Moreover, not all workers could be classified along every dimension.

Source: Section 5.4.1, p. 40; Appendix D, Figures 18–19, pp. 89–90.

7.3 Adoption intensity and firm characteristics

Among firms adopting agents, the estimated increase in PRs per worker is 21.4% in the third with the lowest take-up, 41.9% in the middle third, and 67.0% in the third with the highest take-up.

The association is informative, but intensity is measured in the six months after adoption. It is neither a predetermined characteristic nor a randomly assigned dose of usage. Firms with better results may expand usage more quickly, and other characteristics may influence both outcomes.

Across firm size, sector, and whether software is an output or an input, the paper does not find consistent differences across the two generations of tools. This limits the basis for identifying any sector or size category as a universal beneficiary.

Codebase complexity produces a pattern more closely aligned with the review mechanism. For agents, time to merge increases by 69.7% in the third of firms with the most repositories, compared with 25.4% in the third with the fewest. Growth in PRs opened is 30.0% and 64.3%, respectively. The number of branches shows a similar gradient.

Effects on issues resolved remain similar across these groups. The result suggests greater review difficulties in organizationally complex codebases, but repositories and branches are proxies rather than a comprehensive assessment of technical complexity.

Sources: Section 5.4.2, p. 40; Appendix D, Figures 20–25, pp. 91–96.

7.4 What was not measured about learning

The evidence on codebase familiarity shows the importance of specific knowledge for review. It does not measure loss of cognitive capacity, deterioration in learning, declining technical proficiency, or psychological dependence on the tools.

Nor does the study follow the development of new specialists over many years. Its model assumes constraints related to seniority, but it does not estimate a complete process of knowledge acquisition or loss.

The shift in hours between coding and review, presented below, is an inference from the calibrated model. It should not be reported as a direct measurement of each worker’s postadoption workday.

8. What was observed about employment

8.1 Engineering: no detectable effects, with meaningful intervals

The main measure of engineering employment is the number of active workers in Jellyfish in each firm-month. It is a platform-based proxy rather than a payroll count.

The ranges reproduce the manuscript’s approximate percentage presentation of log coefficients. They are not exact exponential conversions.

Neither analysis finds an effect significant at the 5% level. Particularly for agents, however, the interval allows substantial reductions. The appropriate formulation is that the study does not detect a change attributable to adoption during the period analyzed, given the available precision.

Source: Section 4.7, pp. 34–36; Figure 8, p. 56.

8.2 Overall employment, seniority, and worker flows

Using Revelio data, the authors also examine overall firm employment, including roles outside engineering. The final-month log estimates are −0.001 for assistants, with a standard error of 0.031, and +0.039 for agents, with a standard error of 0.033. Neither is significant at the 5% level.

Separating junior and senior workers also reveals no significant effects on the respective employment stocks. This analysis uses Revelio’s classification and covers workers at the firms, not exclusively programmers.

The hiring and separation results contain some differences that a narrative of “no effect on anything” would miss:

• for assistants, there is an estimated increase in hiring, statistically significant at the 5% level, driven primarily by senior workers;
• for agents, no significant change in overall hiring or separations is detected;
• the reduction in junior hiring documented in some other studies does not appear;
• senior separations after agent adoption increase with only marginal evidence, without significance at the 5% level.

The hiring and separation measures use the logarithm of one plus the count. Their coefficients should not be mechanically converted into exact percentage changes in people hired or separated.

Sources: pp. 35–36; Appendix D, Figures 13–16, pp. 84–87.

8.3 Why this finding does not settle the employment debate

The horizon is short for organizational transformation. Firms may change the mix of tasks before hiring or separating workers, and the data do not track all subsequent adjustments.

The design also identifies partial-equilibrium effects: what changes at an adopting firm relative to others within the analytical framework. If some of its expansion comes from customers previously served by competitors, employment effects may occur outside that firm.

The findings therefore do not establish the absence of displacement across the entire market, permanent protection for juniors, or the inevitability of future layoffs. They delimit what was detected at specific firms and over specific periods.

9. The economic model of bottlenecks

9.1 Two complementary stages

The model formalizes an economic idea: increasing capacity in one activity may generate little additional output when another necessary activity cannot keep pace.

The authors represent software production through two stages, coding and review. In simplified notation:

Y = (1/n) × min{C, R}.

Here, Y represents software output; C and R are the code and review inputs put into production; and n is the number of approved code changes required for one unit of final output.

The function uses the smaller of the two inputs because they are treated as perfect complements. Additional code without corresponding review does not become final output. This structure, known as a Leontief production function, is an analytical simplification rather than a claim that all real processes operate identically.

Each stage’s capacity depends on productivity and the labor allocated to it: coding productivity multiplied by coding hours, and effective review productivity multiplied by review hours.

The latter is affected by the need to rework or correct code. In the model, a higher probability of bugs implies more rounds before approval. Effective review capacity can fall even if the raw speed at which a reviewer examines one round remains constant.

Sources: Section 3, pp. 17–26; proofs in Appendix G.1, pp. 103–107.

9.2 The limit on reallocation

The same people can code and review. The model does not assume two completely separate workforces.

However, some review requires senior workers. The combination of the share of seniors available and the share of review requiring that experience determines a ceiling on the share of labor allocated to review.

Faster coding and greater correction requirements push the organization in the same direction: toward more review capacity. The ceiling limits how far this shift can go.

This mechanism is supported by the evidence on codebase familiarity and reviewer seniority. Even so, its representation through a single ceiling compresses a more complex reality in which experience, product, architecture, and the distribution of knowledge may matter in different ways.

9.3 Short, medium, and long run have specific meanings

The short-run proposition, in which a coding gain may have zero pass-through to output, is a model conclusion under fully fixed labor. It is not an estimate that AI adoption had zero effect on software output at all observed firms.

Even with optimal internal reallocation, pass-through may be incomplete: some labor previously used to write code must shift to review. If review capacity reaches a ceiling, further coding gains cease to expand final output.

9.4 Why demand matters for employment

In the long run, producing more per hour allows both output expansion and a reduction in the hours required. The net effect depends on how much additional software the market absorbs when its cost and price change.

The authors introduce linear demand and a firm with market power that chooses output and employment. In this model, total labor is the sum of coding and review labor; it does not represent employment across all firm functions, which appears separately in the Revelio data. They retain assumptions such as constant returns to scale and a given wage. The price elasticity of demand governs the balance between expansion and labor displacement.

For small productivity changes, the theoretical formulation yields an elasticity threshold of 3 for total coding and review labor. For the discrete shock calibrated in the study, the calculated threshold is 3.68; for coding labor, it is 6.83. These are distinct exercises, and the numbers are not interchangeable.

The model therefore does not imply a universal employment decline when productivity increases. With sufficiently elastic demand, expansion can outweigh the reduction in labor required per unit of output.

Sources: pp. 23–26 and 44–45; Figure 12, p. 60; Appendix G.3.1, pp. 110–111.

10. What the calibration allows us to infer

10.1 Hourly productivity and allocation are not directly observed

The records allow code, reviews, and tasks to be counted, but do not perfectly measure how many hours produced each outcome. The authors use the model to infer changes in these parameters.

The calibration combines six empirical moments, including growth in PRs opened and merged, issues resolved, the backlog trajectory, and the share of submissions receiving a comment. Minimum-distance estimation seeks parameters that bring the model’s relationships close to those outcomes while respecting labor constraints.

Source: Section 6.2, pp. 42–43; Table 5, p. 66; Appendix G.2, pp. 108–109.

The 73.7% gain is not a direct observation that all engineers began writing 73.7% more code per hour. It is the productivity parameter recovered under the model. Its magnitude exceeds PR growth because the calibration simultaneously infers a reduction in labor allocated to coding.

The baseline shares of 65.7% for coding and 34.3% for review refer to the restricted universe of coding plus review used in the calibration. They do not represent the full workday and do not contradict the 40.8% coding share in the broader imputation.

10.2 Using comments as a proxy for bugs

The empirical link between quality and review productivity warrants attention. The calibration proxies the probability of bugs through the share of PRs receiving a comment, which rises from approximately 35.2% to 39.8%.

A comment is not necessarily a bug. The mapping from an observed comment to bug probability is a measurement assumption in the model. It allows the parameters to be estimated, but limits a literal interpretation of the 7.0% decline as an independent measure of reviewer efficiency.

Nor does the documentation allow the increase in comments to be causally decomposed into human interactions, bot participation, and changes in review practices. The first-human-comment criterion is explicit in the time decomposition, but this does not turn the overall comment count into an exclusive measure of human effort or defects. The growing presence of automated review is one possible explanation for part of the change in recorded comments, without the study having separately estimated its contribution.

There is also a question of compatibility between the measures. In the simplified model, time in review equals the inverse of effective productivity. The calibrated log coefficient of −0.073 would imply an increase of approximately 7.6% in that inverse, while the observed interval after the first comment increases by 58.5%. This interval is not directly included among the six moments used to fit the calibration, which recovers review productivity through the comment proxy.

The comparison does not justify replacing the calibrated decline with another percentage or formally rejecting the model. The observed interval is calendar time, includes corrections and waiting, and refers to the subsample with comments; its equivalence to a reviewer’s continuous working time is a theoretical simplification. Without comparable measures in a common sample and their joint uncertainty, the difference remains an open methodological question. Consequently, the calibrated 7.0% decline should not be presented as a direct quantitative explanation of the entire 58.5% increase in the interval termed active review.

Sources: p. 19; p. 37; Table 5, p. 66; Appendix G.2, pp. 108–109. The value of 7.6% is an arithmetic comparison based on the printed coefficient, not an additional estimate produced by the authors.

The structural changes in labor also depend on this link. They therefore cannot serve as entirely independent additional confirmation of the measures that fed into the calibration.

10.3 What explains the gap between capacity and final output

The parameter n absorbs part of the gap between code changes and completed final work. It may represent changes in work fragmentation, such as opening more PRs to complete the same task, or constraints in other stages, such as management and testing.

The study does not identify these explanations separately. An estimated increase in n does not establish that a known share of code is useless or directly measure a management bottleneck.

In the authors’ decomposition, 62.4% of the log gap between the coding productivity shock and final output is explained by the production mechanism of labor reallocation and backlog accumulation; 37.6% remains in the residual fragmentation term.

These shares belong to the model decomposition. They do not mean that review causes 62.4% of all delays at a firm. Nor is the reported pass-through of 0.233 in logarithmic terms a simple division of the percentages 13.7 and 73.7.

Source: pp. 42–43.

10.4 The model fit test does not validate the model conclusively

The test of overidentifying restrictions yields a J statistic of 2.914 and a p-value of 0.233, with two degrees of freedom. This means that the tested restrictions are not rejected at conventional levels.

Failure to reject does not prove that the model is the only explanation of the data. The structural standard errors are also calculated assuming zero covariances between moments, as noted in Table 5.

These limitations are especially relevant when the parameters feed into scenarios far beyond the observation period.

11. Firm adjustment and future scenarios

11.1 What further internal reallocation alone changes

Holding total coding and review labor and available technology fixed, the authors calculate the labor allocation that would balance the two activities. The inferred allocation is already close to this combination: 50.8% in coding and 49.2% in review, compared with a balanced allocation of approximately 50.6% and 49.4%.

In this exercise, the increase in issues resolved would be 14.1%, slightly above the empirical estimate of 13.7%. Within the calibration, the additional scope for simple internal redistribution appears limited.

The authors also examine a counterfactual in which n had not increased. With the balanced allocation, output would be 33.8% above the preadoption reference point.

The contrast does not establish that a specific management intervention would yield 33.8%. The residual term may include fragmentation and other constraints not identified separately. The exercise shows the quantitative importance of assumptions about the conversion of code into final output.

Source: Section 6.3.1, pp. 43–44.

11.2 The flexible-labor scenario with technology held fixed

To assess decisions about scale and employment, the study uses demand elasticities from previous research on mobile applications, retail software, and console video games. The range is 1.50 to 3.73, with a mean of 2.27.

These parameters are not estimated at the Jellyfish firms. Transferring them to other products, especially enterprise software and internal development, is a consequential assumption.

At the mean elasticity, the long-run exercise produces:

• +16.1% in final output;
• −13.2% in total engineering labor represented in the model, comprising coding and review;
• −33.2% in coding labor;
• +24.9% in review labor.

These are model results for coding and review, not observed changes in firms’ complete workforces. In addition to allowing this labor to adjust, this exercise holds n at its preadoption level, while the internal reallocation exercise holds it at its postadoption value. The difference between 14.1% and 16.1% therefore should not be attributed exclusively to the freedom to change staffing levels.

Sources: pp. 44–45; Figure 12, p. 60; Table 6, p. 67; Appendix G.3.1, pp. 110–111.

11.3 How the technological trajectory is constructed

The study draws on the software task time horizons that frontier models can complete with 50% reliability, according to the METR series used by the authors. These are task durations measured in terms of the time required by human experts, not a guarantee of success in production.

In the fit presented in the manuscript, this time horizon doubles approximately every 129 days. To relate it to coding productivity, the authors use two inferred points: the assistant effect, placed at the median adoption month of April 2024, and the additional agent effect, placed in May 2025.

The productivity factors used are approximately 1.35 for assistants and an additional factor of 1.74 for agents, resulting in a cumulative factor of 2.34 relative to the pre-AI baseline. Stacking these estimates is part of the scenario’s construction.

The factors come from estimates recovered at the ends of the respective observation windows, but they are placed at the median adoption dates to fit the trajectory. April 2024 and May 2025 therefore function as chosen anchors for the simulation; they are not the dates when those end-of-window effects were directly measured. This placement is an additional extrapolation assumption.

The extrapolation assumes a stable exponential relationship. Under that relationship, each doubling of the technical time horizon corresponds to a 19.7% increase in coding productivity. The productivity parameter would reach 8.93 times its baseline in 2028 and 41 times its baseline in 2031.

These factors are projections of a model parameter. They are neither observed growth rates in code output nor a promise about the evolution of commercial models. The relationship is extended from a small number of points and may change with tasks, tools, and organizations.

Sources: Section 6.3.2, pp. 45–47; Figure 13, p. 61; Appendix G.3.2, pp. 111–112.

11.4 Two review scenarios through 2031

Simulated changes relative to the pre-AI baseline in Figure 13. The labor column covers the model’s two activities rather than all firm employment measured by Revelio. These scenarios do not necessarily use the same reference point and assumptions as the fixed-technology exercise in Figure 12.

The second scenario represents an extreme situation in which AI improves both stages included in the model. The authors treat it as an upper bound within the exercise, noting that deciding what to build, testing, and coordinating with clients may also create constraints.

The first scenario also incorporates substantive choices. Appendix G.3.3 sets a ceiling of 0.823 on review’s share of labor, holds total coding and review labor at its initial level through December 2026, and allows adjustment starting in January 2027. The adjustment speed closes half the gap to the desired level each year, with a smooth transition.

The residual term n follows a curve fitted to the results and then remains constant. In the fixed-review-productivity scenario, the authors additionally impose that output does not fall below its running maximum. The engineering labor represented in the model is recalculated to sustain that level.

This last procedure prevents a decline that would arise in the baseline adjustment path under linear demand. The output plateau therefore does not result solely from technology and the review ceiling: its shape also reflects an explicit simulation convention.

Even the portions of the graph referring to 2026 include modeled values, not just observations. These exercises do not provide a probability distribution that would justify calling the two results a statistical prediction interval. Their “bounds” are scenarios defined by assumptions, not established boundaries for every possible future.

Sources: pp. 46–47; Figure 13, p. 61; Appendix G.3.3, pp. 112–113.

12. What the study does not establish

12.1 Generalizability and selection

Customers of an engineering analytics platform may have recording, management, and technology adoption practices that differ from those of other firms. Research consent and the requirement for tool integrations also select the sample.

The profile of established firms limits extrapolation to small or new startups. There is no basis for treating the findings as representative estimates for Brazil, Portugal, or software engineering worldwide.

Firm averages may, in turn, conceal substantially different effects across teams, products, and individuals. The heterogeneity analyses help, but do not exhaust this diversity.

12.2 Observed adoption does not cover all usage

Identification through licenses, bots, and signatures is incomplete. The first detected use may occur after the first actual use; some tools may not be recognized.

The study argues that certain measurement errors would tend to attenuate the estimated aggregate effects. For the instrumental variables analysis, undercounting users may work in the opposite direction, increasing the calculated effect per detected user. The direction and magnitude of bias should not be assumed to be the same across all analyses.

Nor can the results be attributed to a single product or language model. The categories encompass technologies that evolve during the period.

12.3 Recorded tasks remain proxies

Issue resolution depends on management practices. Changes in how consistently records are updated may alter the relationship between records and delivered work. Epics offer an additional proxy, but remain heterogeneous organizational units.

The authors seek to assess size changes through two approaches: text classification initially using GPT-4o, and cycle-time prediction based on preadoption data. The first labels a 0.5% sample of tasks, stratified by firm, and extrapolates through supervised learning; the second uses issues resolved in 2022 as its reference.

Validation of the first method compares the supervised model with GPT-4o labels. The mean squared error of 0.4105 reported in Appendix E evaluates that replication, rather than agreement with a perfect human measure of actual difficulty.

Cycle time, in turn, includes waiting and coordination. Predicting it from text helps construct a proxy that is consistent over time, but does not fully isolate technical effort.

The tests therefore weaken the hypothesis of an evident change in the recorded composition of tasks. They do not eliminate every possible change in scope, complexity, or value.

Sources: Section 2.3, p. 13; pp. 33–34; Appendix D, Figures 7–8, pp. 78–79; Appendix E, Table 2, p. 98; Appendix F.2, p. 102.

12.4 Quality and speed are only partially measured

The data do not provide a comprehensive assessment of architecture, security, maintainability, technical debt, or product utility. Comments and reported bugs capture specific dimensions.

Opening-to-merge times are calendar intervals, not hours worked. PRs still pending or never merged do not have the same observable outcome as merged PRs, limiting the interpretation of average times.

Nor is there a complete measure of the time between identifying a business need and the customer’s use of the solution. The 56.1% increase in opening-to-merge time cannot be reported as an equivalent increase in the entire software delivery lead time.

12.5 Causality, statistical power, and model structure

Similar pretrends do not prove the absence of simultaneous unobserved factors. Similarity of results across estimators helps the assessment, but has a limited scope.

Imprecise estimates do not establish the absence of an effect. Nor does a large number of events ensure precision for every outcome: adoption occurs at the firm level, and useful information varies across measures and horizons.

The structural estimates depend on perfect complementarity, the comment proxy for bugs, the initial allocation, and other constraints. The residual term retains explanations that are not separately identified. Model fit does not eliminate these choices.

The simulations add assumptions about demand, technological progress, and the speed of labor adjustment. Their employment percentages refer to the model’s coding and review activities rather than all firm functions. They should not be used to calculate an inevitable number of layoffs in 2031.

13. Implications for technology management

The managerial implications formulated by the authors follow from the difference between tasks and the production process. Assessing returns on AI requires observing the full pipeline: code output, review capacity, and work actually completed. Intermediate measures considered in isolation may overstate organizational improvement.

The study also supports the relevance of complementary organizational investments. When one stage accelerates, demand for adjacent activities changes; the availability of workers with codebase knowledge conditions the adjustment. This helps explain why acquiring a tool and spreading its use do not exhaust the adaptation of production.

Spending data show another dimension of this assessment without resolving financial returns. For the subset of firms and workers with observable billing through Cursor and Claude Code, in July 2026, median spending per worker was $178 per month, and the mean was $808. The 99th percentile reached $9,007.

The skew shows that the mean does not represent the typical user. Coverage is partial, and these values do not constitute a complete accounting of adoption, review, training, or organizational change costs. The study does not estimate a return on investment applicable to each firm.

Nor does the identification of a bottleneck provide a universal reorganization policy. The calibrated results themselves suggest little additional gain from simple internal reallocation at that equilibrium and retain other constraints in the residual term.

Finally, the evidence does not support abandoning review, replacing technical criteria with code volume, or setting staffing cuts from simulated percentages. The contribution to management is to clarify where the conversion of technical capacity into output may fall short, while respecting what was actually measured.

Sources: p. 17; Sections 5–7, pp. 36–48; Figure 5E, p. 53.

14. Conclusion

Chen and Stratton document a substantial increase in intermediate code output after assistant and agent adoption. Merged code also increases, but estimates for completed tasks and projects are smaller and do not reach statistical significance at the 5% level in the final months analyzed.

Review helps explain this difference. With agents, waiting time until the first human comment increases, the subsequent interval until merge grows, and there are more comments per submission. Dependence on experience and codebase familiarity limits how quickly review capacity can keep pace with coding.

At the same time, no deterioration is detected in bug reports for final software, and no significant change is found in aggregate engineering employment over the observation window. These findings preclude both the conclusion that AI generated no gains at all and the conclusion that increased code output has already translated into a proportional improvement in organizational performance.

The models extend the investigation to the long run, but add assumptions that must accompany any presentation of their numbers. The evolution of review, demand for software, and labor adjustment produce different scenarios without determining an inevitable future.

The study’s scientific contribution is to connect stages that are often assessed separately. Faster coding changes the conditions of software production; the overall outcome depends on how complementary activities respond.

15. Bibliographic reference

CHEN, Fiona; STRATTON, James. Artificial Intelligence in the Firm: Bottlenecks in Software Production. Harvard University, Job Market Paper. October 31, 2026 version. First version indicated: January 7, 2026. 120 pp. Available at the author’s current URL: https://fion.ac/jellyfish.pdf. Initial consultation of the supplied copy: October 31, 2026. Synthesis revision: November 1, 2026. Numbers and page references remain tied to the October 31 copy, even if the current URL displays a later version.