What 554 developers and engineering leaders told us about AI, agents, and the measurement gap nobody’s closing.

Ask a developer if AI made them faster this year, and 84% will say yes. Ask their VP to put a number on it for the board, and 39% will have nothing to show. That gap, not adoption, is the real story in engineering right now.

We surveyed 554 developers and engineering leaders across small teams, mid-size companies, and enterprises to find out how AI is actually used day to day, not just whether it’s used. The adoption question is settled. The proof question is wide open, and it’s the one that determines whether AI spend shows up as a line item leadership trusts or a story nobody can back up.

Read the full report.

Is AI adoption in software engineering actually settled?

Yes. 96.4% of teams have adopted AI coding tools, and only 3.6% report nobody on the team using them. Adoption is no longer a differentiator between engineering orgs. It’s the baseline.

84% of developers say AI made them more productive, and 43% say much more productive. Fewer than 5% report feeling slower. When a tool is this widely adopted and this well-liked, “we’ve adopted AI” stops being a story worth telling a board. Nearly everyone has. The real question is what the gains are actually worth, and whether anyone can show it.

What is the agentic shift, and why does it matter more than adoption?

AI in engineering isn’t one thing. It runs from autocomplete, to asking a model when you’re stuck, to assigning whole tasks to an agent, to running several agents in parallel. Where a team sits on that spectrum predicts almost everything else about how they experience AI.

In September 2025, just 7.6% of developers said delegating tasks to an agent was their primary way of working. By June 2026, that’s 28%, close to a 4x jump in nine months. Two in three developers now run agents at least sometimes.

The payoff climbs with autonomy. The share who feel “much more productive” more than doubles across the maturity spectrum: 28% for assistive users (no parallel agents), 44% for emerging users (experimenting with agents), and 62% for agent-native teams (running parallel agents regularly). If a team is still living in autocomplete, that’s the low end of a gap that’s widening fast, and their peers are already climbing out of it.

Are AI agents actually running all day, or just for quick tasks?

More than a third of developers (34%) keep agents running the entire workday, and another 42% run them for part of it. That’s more than three in four developers running agents during the day, and only 22% who don’t run them at all. A small but real 2% already run agents around the clock.

Agents running all day aren’t an experiment anymore. They’re production infrastructure generating work continuously, which raises the stakes on a harder question: if agents are shipping code while a developer sleeps, who’s measuring what they produce, and what it costs?

Do enterprises or small teams use AI agents more aggressively?

The data says the opposite of what most people would guess. Enterprises run agents the hardest, and govern them the most tightly as they scale. 47% of enterprise developers run agents the entire workday, versus 32% at small shops and 32% at mid-size companies.

Structure follows scale. As organizations grow, the share with no way to measure AI’s impact drops from 47% to 19%, use of DORA or engineering metrics climbs from 6% to 21%, reliance on an approved tool list rises from 25% to 42%, and the share of developers choosing tools entirely on their own falls from 34% to 14%. If a large org isn’t running autonomous agents yet, the data doesn’t read as playing it safe. It reads as falling behind, because the most mature peers are already there, governing and measuring as they go.

Which AI coding tool do developers actually use, and does it signal anything?

Tool choice turns out to be a free, observable signal of how agentic a team really is. Codex and Cursor users behave like power users: roughly 45% run parallel agents regularly, and about half keep agents running the entire workday. Copilot and ChatGPT users skew assistive, sitting lowest on both measures. Claude Code lands in between.

Company size changes the picture too. Claude Code leads on penetration at small (63%) and mid-size (57%) organizations. In the enterprise, GitHub Copilot pulls ahead at 74% of developers, versus 56% for Claude Code, but that’s a procurement story, not an agentic one. Copilot is the broadly sanctioned, org-wide default; the autonomous work still rides on tools like Claude Code, Cursor, and Codex used alongside it. The tool an enterprise standardizes on and the tools actually driving its agentic work are diverging, which is exactly why comparing tools and models on real output matters more than which one is on the approved list.

Why can’t companies measure AI’s real impact on engineering?

This is the gap that ties every other finding together. 84% of developers feel more productive with AI. Only 20% of organizations actually measure productivity in any specific way. 39% have no way to measure AI’s impact at all, and another 33% lean entirely on developers self-reporting that it helped. That’s 72% of organizations running on belief instead of a number.

Developers can feel the speed. What most leaders can’t yet do is prove it to the people who fund the work. With agents writing, reviewing, and shipping all day, “trust me, it’s faster” doesn’t answer what a CFO is already asking: what did this return, and which tools are actually worth the spend?

How can engineering leaders close the measurement gap?

Based on what the most mature teams in the survey are doing, four moves matter most:

• Set a baseline before you scale. Capture delivery and quality metrics now, like DORA-style throughput and stability plus code-quality signals, so change is visible instead of argued about.
• Adopt a maturity model for AI use. Treat autonomy as a ladder: assistive, emerging, agent-native, and the next frontier, agent-optimized. Make moving up a rung, and proving the result, an explicit goal.
• Compare tools and models, not just adopt them. The most mature orgs don’t let everyone pick in isolation. They compare tools and the models behind them on output quality and cost.
• Instrument the agents, not just the people. As agents take on more work, measure their output the way you’d measure a team’s: cost, cycle time, review burden, and whether what they ship holds up.

Where does GitKraken fit into this?

This report points at two separate problems, and GitKraken built a product for each. GitKraken Kepler is where developers plan, launch, and review parallel AI agents from one surface, working with Claude Code, Codex, Open Code, and more. GitKraken Insights is where that work becomes measurable: productivity change, hours returned, and the dollar value of AI-assisted capacity, the ROI number a CFO is actually asking for.

Adoption was the easy part. The teams that win the next phase are the ones that can measure what AI is actually changing, and act on it. Get the full report.