GitClear’s research and the broader data on AI-assisted code quality describe what’s happening on average. Averages are useful context, but they don’t tell you much about what separates the teams above the quality curve from the teams below it.
The patterns that distinguish teams getting good results from AI adoption from those accumulating quality problems are fairly consistent.
Pattern one: they have a baseline
Teams that can demonstrate AI is working for them have something to compare it against. Either they established a pre-AI baseline before rolling out the tools, or they reconstructed one from their git history after the fact.
The baseline is what makes every subsequent measurement meaningful. A churn rate of 1.6 is just a number. A churn rate of 1.6, compared to a pre-AI baseline of 0.9, is a finding. Teams collecting data without a reference point can describe what’s happening now but can’t say whether the tools are making things better or worse.
The practical implication: git history is retrospective. Teams that didn’t establish a baseline before adopting AI tools can still reconstruct one from commits made before adoption.
Pattern two: they treat AI assistance as a variable to optimise, not a binary switch
Teams with good outcomes are not using AI assistance uniformly. They’ve developed a sense of which tasks benefit from it and which don’t, and they’ve adjusted their use accordingly.
This calibration is rarely explicit policy. It tends to develop through developers comparing notes: “I found AI assistance worked well on the test suite but produced high-churn code on the auth refactor” is a data point that spreads informally through a team. Teams that monitor churn and duplication metrics accelerate this calibration because they have something concrete to compare notes about.
Pattern three: code review has adapted
Teams getting good results have changed what reviewers look for in AI-assisted code. The most common shift: for AI-assisted diffs specifically, review is less about “is this code correct” (which can usually be established quickly) and more about “is this code necessary, does it duplicate something that already exists, and is it scoped to this problem rather than a generalised solution the model produced because it fit the training data.”
This doesn’t require a formal process change. It requires reviewers who know which commits are AI-assisted and who’ve developed a different set of questions for those commits. Teams with that visibility are better positioned to catch structural quality issues before they compound into something harder to fix.
Scryable surfaces churn, duplication, and before/after AI comparisons from your git history. Get early access.