AI
14 minutes reading time
AI coding assistants have moved from novelty to default tooling in most engineering orgs. Copilot, Cursor, Claude Code, and a dozen others now sit in nearly every IDE, and for teams that use them well, the results are real: faster boilerplate, quicker first drafts, less time lost to rote syntax, and more energy left for the hard problems. The question worth asking isn't whether to use AI. It's how the best teams are getting so much more out of it than everyone else.
That gap is the interesting part. Two teams can adopt the same tools on the same day and end up in very different places six months later: one compounding real gains, the other treading water. The difference isn't the model. It's what the team already had in place before AI arrived, and what they choose to build around it.
In this article, we'll look at what the research says about AI as an amplifier, the four habits that separate the teams pulling ahead, and how to see what's actually working on your own team.
Let's get started!
AI Doesn't Replace a Strong Team. It Amplifies One.
DORA's 2025 State of AI-Assisted Software Development report, based on survey responses from nearly 5,000 technology professionals, put a number on something most engineering leaders already sensed: 90% of respondents now use AI at work, and more than 80% believe it has increased their productivity. And unlike the year before, the report found a positive relationship between AI adoption and both software delivery throughput and product performance, a real shift as teams learn where AI helps most.
The same report is just as clear about the other side: AI adoption still has a negative relationship with delivery stability. More change volume, without strong automated testing, mature version control, and fast feedback loops, turns into instability downstream. That isn't a reason to slow down. It tells you exactly where to invest.
The report's central idea is worth sitting with: AI is an amplifier, not a fix. Teams with strong automated testing, fast feedback loops, and loosely coupled architecture see their advantage widen with AI. Teams still building those foundations see smaller returns, not because AI failed them, but because there was less for it to amplify yet. That's good news: it means the path forward is concrete. Investing in the fundamentals (quality internal platforms, clear workflows, team alignment) isn't a prerequisite you have to clear before AI pays off. It's the lever that decides how much it pays off. Every team can pull it.
Pro tip: If you're weighing faster delivery against stability, our guide to speed vs. quality in software development shows which metrics keep both in view.
Keep the Craft Habits That Make AI-Generated Code Great
GitClear's 2025 AI Copilot Code Quality research, based on 211 million changed lines of code from 2020 to 2024, offers a useful diagnostic. Across the industry, refactoring (the habit of cleaning up and consolidating code as you go) fell from 25% of changed lines in 2021 to less than 10% in 2024, while copy/pasted code rose from 8.3% to 12.3%. Read one way, that's a warning. Read the more useful way, it's a map of exactly what to protect.
AI is extraordinary at producing a first draft fast. It's not yet great at deciding when three similar-looking functions should become one, or when a shortcut today is a maintenance cost next quarter. That's still a craft judgment call, and it's one your best engineers are already good at. Teams that keep dedicated time for refactoring and treat AI output as a strong first draft rather than a finished one are the ones compounding AI's speed into lasting quality, instead of trading one for the other. The habit didn't stop mattering. If anything, it matters more now that there's more code moving through it.
Pro tip: For a closer look at hidden rework in AI-assisted delivery, read our guide to code churn.
Turn Review Into Your Multiplier, Not Your Bottleneck
A study by Uplevel tracking nearly 800 developers found that GitHub Copilot access brought no significant change in cycle time or PR throughput, while the Copilot group introduced 41% more bugs. Uplevel's own hypothesis: developers with Copilot may submit larger changes per PR, which makes bugs easier to miss in review. That's a useful signal, not a discouraging one. It tells you exactly where the unclaimed upside is sitting.
The teams turning AI's speed into real throughput gains are the ones who treat review as part of the workflow to redesign, not a fixed cost to work around: tighter PR sizes suited to AI-generated diffs, checklists tuned to the kind of edge cases models miss, and pairing junior and senior engineers on AI-assisted work. None of that is exotic. It's the same review discipline good teams already had, pointed at a faster input. Do that well, and the productivity gain you were promised shows up where you can actually see it: in cycle time, not just in how fast the first draft appeared.
Make Trust a Design Choice, Not an Afterthought
The same DORA report found that 30% of respondents report little or no trust in AI-generated code, and one of its recommended starting points for engineering leaders is to clarify and socialize your AI policies. That's an encouraging finding: trust turns out to be buildable, on purpose, faster than most teams expect.
A short, clear policy (what AI is great for, what still needs a second look, how proprietary code gets handled) does more than manage risk. It gives every engineer permission to move fast with a tool they don't have to second-guess line by line. The teams with the least friction around AI usually aren't the ones with the least oversight. They're the ones who made the ground rules explicit early, so nobody's guessing.
Use AI to Teach, Not Just to Produce
It's tempting to hand a junior engineer a hard problem and let the assistant do the thinking. The more durable version of that move is pairing AI-assisted work with an explicit "explain it back" habit: reviewing why a suggestion works, not just accepting that it does. Teams that build this in are turning AI into one of the fastest onboarding tools they've ever had. Junior engineers see idiomatic patterns immediately, ask better questions sooner, and build the debugging instincts that come from understanding, not just from output. The teams that skip this step aren't wrong to move fast. They're just leaving one of AI's best side benefits on the table.
See What's Working, So You Can Do More of It
None of the above requires guesswork. This is where we think Axify earns its keep: not by policing AI usage, but by giving teams the visibility to see what's actually paying off, so they can double down with confidence instead of hoping the math works out.
A few concrete examples:
- Adoption vs. impact, not adoption vs. licenses. Axify tracks real usage, an AI adoption score, and suggestion acceptance rates alongside delivery metrics, so a team can see the difference between "everyone has Copilot" and "Copilot is measurably making delivery faster," and make the case to expand what's working.
- Cycle time broken into phases. Value Stream Mapping and PR cycle time (coding, pick-up, and review time) show exactly where speed gained upstream is showing up downstream: proof for the teams who've redesigned review well, and a clear next step for the teams who haven't yet.
- DORA metrics next to AI adoption. Change failure rate and time to restore service, tracked by team alongside AI adoption trends, let a team confirm what's working before scaling it further, and catch a rough patch early enough to tune the approach rather than pull back.
- Answers when a metric moves. When a number shifts, Axify Intelligence helps a team lead dig into the likely contributing factors, so they can act on a real signal instead of a guess.
The craft habits, the review redesign, the trust-building, the teaching moments: none of it replaces good engineering judgment, and it isn't meant to. What visibility adds is confirmation: proof of what's working, early enough to invest further, and a clear read on what to adjust when something isn't.
For a practical measurement framework, see our guide to AI coding tools' impact, which shows how to connect adoption and cost data with delivery and quality evidence.
The Takeaway
The teams pulling ahead with AI aren't the ones with access to a better model. Everyone has roughly the same models. They're the ones who treated AI adoption the way they'd treat any other high-leverage change: invest in the fundamentals, adapt the process around it deliberately, and watch the data closely enough to know what's actually working. That combination is available to every team, starting now.
Curious what that looks like with your own team's data? Start your 14-day free trial of Axify.
FAQs
Does AI make engineering teams more productive?
Mostly yes, but unevenly. In the 2025 DORA report, more than 80% of respondents believe AI has increased their productivity, and AI adoption now shows a positive relationship with delivery throughput. The size of the gain depends on the foundations a team already has, like automated testing and fast feedback loops.
Why do some teams get more out of AI than others?
Because AI amplifies what's already there. Teams with strong testing, review discipline, and clear workflows turn faster code generation into faster delivery. Teams without them see the extra speed absorbed downstream, in review queues or in instability.
How can you tell if AI is actually improving delivery?
Compare AI adoption with delivery metrics for the same team over time: cycle time and its phases, PR review time, deployment frequency, and change failure rate. If adoption rises but cycle time and stability don't move, the gain is getting lost somewhere in the workflow.