AI coding tools can help a developer understand an unfamiliar repository, implement a change, repair a test, and prepare a pull request. While it can reduce the effort required to contribute, It does not guarantee that the resulting code is understood beyond the person who guided the tool.
This means code production can broaden faster than the ability to review, explain, and maintain the code.
So lets explore how engineering leaders can measure contributions and ownership separetely.
What the research shows
Fang et al. (2026) connected 13,360 AI chat sessions from 1,356 open-source repositories to subsequent development activity. After filtering, their repository analysis included 1,240 projects, 657,971 commits, 9,510 pull requests, and 120,489 CI checks.
The conversations usually led to repository changes. About 98.9% of sessions were followed by activity, and 96.1% were associated with a commit that changed at least one development file. Code writing was the dominant chat purpose in 53.9% of repositories.
The participation results were more qualified. In the main cohort of 608 generally young repositories, active contributors increased from an average of 1.4 to 1.7 after observed AI adoption, while contributor concentration declined. The same pattern did not hold in the validation cohort of 114 older and larger repositories. Communication and review also remained concentrated in both cohorts.
The paper therefore does not establish that AI consistently broadens collaboration. It suggests that AI may help more people produce changes while the work of discussing and reviewing those changes remains concentrated among a few maintainers.
The authors also found no broad decline in the code-quality and pull-request signals they measured. That finding is important, but limited. Commit labels, test-file changes, CI results, and merge rates are proxies for development activity. They do not directly measure correctness or long-term maintainability (Fang et al., 2026).
The author knows more than the reviewer
A developer using a coding agent sees the full interaction including the prompts, failed attempts, corrections, assumptions, and uncertain outputs. However, A reviewer usually sees only the final diff. This can potentially help us understand why AI-generated code may look clearer to its contributor than to everyone else. In the paper’s survey, respondents rated other people’s AI-generated code as more likely to require additional maintenance than their own. The result was statistically significant, but it came from only 25 survey responses and should be treated as an early warning rather than proof of a general maintenance problem (Fang et al., 2026).
The practical issue is missing engineering context. A pull request may show what changed without showing:
- why that approach was selected;
- which alternatives were rejected;
- which assumptions were made about the system;
- where the contributor remains uncertain;
- which failure conditions were tested.
Since the reasoning stays inside a private AI conversation, the repository receives the code but not all the knowledge needed to maintain it.
Maintenance cost may appear before defects
In my Opinion, Defect rates are a lagging signal. Review effort, rework, and ownership concentration may change first. Vella and Blincoe (2026) found that professional engineers reported spending less time writing code and more time directing, evaluating, and correcting AI output. They describe this as supervisory engineering work. Perceived productivity remained high, while reports of worsened developer experience increased in the matched longitudinal cohort.
Sawada et al. (2026) did not find that agent-generated files were maintained more frequently than human-authored files. They did find that human developers performed most of the subsequent maintenance.
Popescu et al. (2026), using a much larger pull-request dataset, found greater churn over time in agent-generated contributions than in human-authored code.
Taken together, these studies do not support a simple claim that AI-generated code is uniformly worse. They support a narrower concern: organizations may produce code faster while shifting more verification and later modification work onto human engineers.
Measure contribution and ownership separately
So what can we do instead?
Engineering leaders should not treat more commits or pull requests as proof of greater engineering capacity. A team can merge more code while becoming more dependent on a small group of reviewers and maintainers.
A useful measurement model separates four questions:
- Contribution: Are more people completing valuable changes?
- Review: How much human effort is required to validate those changes?
- Ownership: Can someone other than the contributor explain and safely modify the code?
- Lifecycle: What happens after merge—rework, churn, defects, rollback, and incident recovery?
Useful indicators include reviewer time, correction cycles, post-merge churn, reopened work, change-failure rate, and the percentage of critical components understood by more than one engineer.
One especially useful test is simple:
Can an engineer who did not guide the coding agent explain the change, identify its main risks, and modify it without reconstructing the original chat? Where is this recorded ?
If not, the contribution has been merged but not fully absorbed by the team and remains tribal knowledge.
Add an ownership contract to meaningful changes
From all of this, I do not recommend that teams now need to publish their entire AI transcripts. Not only will Full transcripts create privacy, intellectual-property, and reviewer-load concerns but it burdens the contributor.
Could a concise pull-request record be more useful ? for Instance, we could require the contributor to document:
- Intent: What problem does this solve?
- Constraints: Which architectural, security, data, and operational boundaries were preserved?
- Reasoning: What important alternatives or tradeoffs were considered?
- Verification: Which tests and failure scenarios were evaluated?
- Ownership: Which human engineer accepts responsibility for explaining and maintaining the change?
AI-origin metadata can provide context, but it should not become the main control. Review intensity should follow the risk of the change: scope, novelty, security sensitivity, state complexity, blast radius, test strength, and reversibility.
The relevant question is not whether a human typed every line. It is whether a responsible engineer can defend the change and maintain it after the AI conversation is gone.
Contribution is not capacity
Coding agents may lower the effort required to participate in software development. The evidence does not yet show that they consistently broaden collaboration or reduce the long-term burden on maintainers.
That distinction should shape engineering governance. Organizations should measure not only how quickly AI-assisted changes are produced, but how effectively those changes are reviewed, understood, and absorbed.
AI can broaden contribution. Engineering leaders must ensure that ownership broadens with it.
References
Fang, Z., Zhang, Y., Tang, N., McMillan, C., Li, T. J.-J., & Huang, Y. (2026). From conversation to contribution: Characterizing vibe coding in open-source software [Preprint]. arXiv. https://doi.org/10.48550/arXiv.2607.05677
Popescu, R. M., Gros, D., Botocan, A., Pandita, R., Devanbu, P., & Izadi, M. (2026). Investigating autonomous agent contributions in the wild: Activity patterns and code change over time [Preprint]. arXiv. https://doi.org/10.48550/arXiv.2604.00917
Sawada, S., Shirai, T., Kashiwa, Y., Yamaguchi, K., Iwata, H., & Iida, H. (2026). To what extent does agent-generated code require maintenance? An empirical study [Preprint]. arXiv. https://doi.org/10.48550/arXiv.2605.06464
Vella, A., & Blincoe, K. (2026). The impact of AI coding assistants on software engineering: A longitudinal study [Preprint]. arXiv. https://doi.org/10.48550/arXiv.2605.23135