Vibe coding and code health: what six studies say, and what 3,126 repos show

Vibe coding does not make individual commits buggier, but repos that move fast score lower on code health at the same size. In our data, public repos that commit five or more times a day have a median health of 6.25, against 8.19 for repos that commit less than once a day (both at 100 to 999 files). Separately, our study of 112,382 commits found reviewed agent-written commits were no more likely to introduce a bug than human ones.

That sounds contradictory until you look at what each study measures. We read the six studies people quote most, checked what each one actually counted, then compared pace and health across 3,126 scored open-source repos in the repowise index (more in benchmarks).

What do the studies say about AI and code quality?

Six studies come up in almost every discussion, and they measure different things: task time, changed lines, delivery metrics, review issues and model output. That is why the threads go in circles. As of October 2026:

METR measured how long tasks took, and its own follow-up says the first number probably does not hold today. The 2026 update reports that selection effects (developers refusing to work without AI) make its new data an unreliable signal, so neither the 19% slowdown nor the later speedup should be quoted as settled.

GitClear and CodeRabbit measured the code itself, and both found more of what reviewers dislike: duplication, logic slips and less refactoring. Veracode measured raw model output with no human in the loop, a useful worst case that is far from what a merged commit looks like.

DORA is the finding to keep. Teams ship more with AI, and teams that were already shaky get shakier. Quality depends on the practices around the tool.

Are AI-written commits buggier than human commits?

No. In our study, commits from developers driving an agent such as Claude Code were less likely to introduce a bug than human commits in the same repo, with an odds ratio of 0.57, and the lines they wrote survived longer. We traced bugs back through 112,382 commits across 28 repos to find which commits introduced them. The full write-up has the method and charts.

The caveat we take most seriously is review. These are merged commits, and agent PRs may get read more carefully than a trusted teammate's. The fair reading is narrow: agent commits that got through review were no buggier than human ones, and the review may be part of why.

That leaves a puzzle. If individual AI commits are not buggier, something else has to explain why GitClear and DORA see quality and stability slipping.

Do faster-moving repos have lower code health?

Yes. In both size bands, the faster a repo commits, the lower its median health. Our index cannot tell who or what wrote a commit, but it knows how fast a repo moves and how healthy its code is. We compared the two on public repos with a health score, at least 100 files, and a commit count covering the full history. Pace is total commits divided by the repo's age in days. The health score runs from 1 to 10 and rates how likely a file is to cause bugs and how hard it is to change, using static checks plus git history. The repo score is the average across files, weighted by lines of code.

In the smaller band the gap is about two points, from 8.19 down to 6.25, and the fast repos there are overwhelmingly young: 95% of them started in 2025 or later, so they were born in the coding-agent era.

Two cautions go with the table. The index holds no authorship data, so it cannot say whether AI wrote the fast repos. And size is not fully controlled: inside each band the fast repos are still a bit bigger (median 414 files against 178 in the small band), and size alone pulls health down. Across all 3,126 scored repos, median health drops from 9.87 for repos under 20 files to 7.28 at 100 to 999 files, then holds between about 7.1 and 7.5 past a thousand files. Every score counts code files only, so config and docs files do not lift the big repos.

What the table does fit is the DORA picture. Each commit can be fine on its own while the codebase drifts, because nobody had time to fold the third copy of a function into the first two. That is GitClear's finding that copy-paste overtook refactoring, seen from a different angle.

What should a team do about it?

Keep reviewing, watch the whole repo over time, and schedule the refactor. The data argues against both camps' favorite move: banning agents does not follow from per-commit evidence that reviewed agent commits are fine, and accepting every diff on vibes does not follow from pace data showing that speed costs something unless someone pays it back.

1. Keep reviewing. The protective effect in our study may well be the review.
2. Watch the whole repo over time. Duplication and drift build up slowly and never show in a single PR, but a health score tracked over months does. See declining code health trends for how to read the trend.
3. Schedule the refactor. If you commit five times a day, set aside time to delete things, the way mature projects do: requests deletes about 82 lines for every 100 it adds (lines deleted per 100 added).

The second habit needs a view of the repo as a whole. Paste any public GitHub URL into repowise.dev and you get its health score, hotspots and dead code without signing up. Locally, repowise init indexes your own repo and repowise health lists the lowest-scoring files. The code health feature page covers what the score measures.

How we measured

• Population: repos on repowise.dev whose latest finished index has a health score, 3,793 in total and 3,126 of them public. The pace table uses the 795 public repos with at least 100 files and a full commit count.
• Health: the repo score as defined above.
• Pace: total commits on the default branch divided by the days between the first commit and the index date, with a 30-day minimum. We dropped repos whose commit count only covers a shallow clone window.
• Limits: the data cannot say who wrote the code, whether the fast repos would be healthier if they slowed down, or anything about private code. These are medians across very different projects, so no single repo should be judged by them, and this post names none on purpose.
• Checked against the live index on 2026-10-06.