73% of Developers Use AI Every Day. 97% Don't Fully Trust It. Here's the Data.

TLDR

• • 73% of engineering teams use AI coding tools daily — up from 18% in 2024, a 4× increase in under two years
• • Only 3% of those developers report "highly trusting" AI-generated code; 46% actively distrust it
• • METR's independent study (246 real tasks, 16 experienced developers) found developers estimated a 20% speed boost from AI — but measured outcomes told a different story
• • The market has bifurcated: one tool for thinking (Claude Code, 44% for complex tasks), another for typing (Copilot, 51% for autocomplete)
• • This isn't a quality problem. It's a verification problem — and git history is currently blind to it

The Number That Should Unsettle You

In February 2026, a survey of 15,000 developers across 80 countries asked two simple questions: Do you use AI coding tools daily? And do you trust what they produce?

73% said yes to the first. Only 3% said yes to the second.

The adoption number isn't surprising — it's been climbing steadily. In early 2024, daily AI tool use across engineering teams sat at 18%. By mid-2025 it crossed 50%. Today, nearly three in four developers open an AI coding assistant before they write a single line. The trajectory is clear.

What's jarring is the trust number. 46% of respondents said they' actively distrust AI-generated code — meaning they accept it, use it to move faster, and then immediately plan to come back and verify it. Only 3% said they'd ship AI code without additional review under time pressure. The rest live in a middle ground: using tools they don't quite believe in, at scale, in production.

| Trust Level | Developer Share | Behavior Pattern | | --- | --- | --- | | {row.level} | {row.share} | {row.behavior} |

METR Measured What Developers Only Estimated

Self-reported surveys have obvious limits. Developers say they trust or distrust AI code — but do their actual behaviors match? METR, an independent AI research organization, tried to answer this with something rarer in this space: a controlled experiment.

The study took 16 experienced open-source developers and gave them 246 real tasks across repositories averaging 22,000+ GitHub stars — production-grade codebases, not toy problems. Half used AI tools freely. Half worked without them. METR tracked actual completion times, not estimates.

The developers without AI? They estimated that having AI would make them roughly 20% faster. The developers with AI? They also estimated they were about 20% faster. The subjective experience of productivity — the feeling of moving quickly — was consistent across both groups.

Measured wall-clock time told a more complicated story. The study found that on complex, unfamiliar tasks, AI-assisted developers spent significantly more time on verification loops — accepting output, testing it, finding failures, prompting again — than developers who wrote the code incrementally themselves. The speed boost was real for well-defined, bounded tasks. For open-ended architectural work, the picture was murkier.

KEY FINDING

The productivity gap between AI-assisted and non-AI development correlates strongly with task specificity. Clear spec + bounded scope = AI wins. Ambiguous requirements + multi-system scope = verification overhead erases the gain. The 46% who "actively distrust" AI code may have simply encountered this boundary more often.

The Market Split: One Tool for Thinking, One for Typing

The trust gap may explain a market dynamic that's emerged clearly in 2026: developers don't use one AI tool. They use two — and the split is intentional.

When asked which tool they rely on for complex tasks — multi-file refactoring, architecture design, debugging deep failures — Claude Code led at 44%, followed by ChatGPT at 19% and GitHub Copilot at 28%. But for routine autocomplete, the rankings flipped: Copilot dominates at 51%, with Claude Code dropping to 27%.

Experienced developers now use an average of 2.3 AI tools simultaneously. The mental model they've developed looks something like this:

How developers actually use AI tools in 2026

Autocomplete / boilerplate → GitHub Copilot (51%) "Figure this out for me" → Claude Code (44%) Quick question / explanation → ChatGPT (19%)

Average tools per developer → 2.3 Fully single-tool shops → 8%

This bifurcation is rational given the trust data. For autocomplete, the verification cost is low — you see the suggestion inline and accept or reject it in under a second. For complex reasoning tasks, the verification cost is high — you need to actually read, understand, and test the output. Developers have unconsciously matched tool trust to task risk. The 46% who distrust AI code aren't abandoning the tools; they're using them more carefully.

The Verification Problem Nobody's Solved

Here's what the trust paradox actually reveals: the bottleneck in AI-assisted development is not generation. Generation is fast, cheap, and getting better every quarter. The bottleneck is verification.

A developer who accepts 50 AI suggestions per day and reviews each one carefully isn't 50× faster than before — they've added a review queue to their workflow. How much of the measured productivity gain evaporates into that queue depends on the task, the developer, and the codebase. METR's study suggests the answer is: more than most people assume.

The tooling to support that verification barely exists. Code review tools were built for human-authored code, which is generally intentional — the author meant to do what they wrote. AI-generated code is probabilistic — the tool produced the statistically likely next token, not necessarily what the developer needed. Reviewing these two categories of code requires different mental models, and most existing tools don't distinguish between them.

More critically: your git history doesn't record which commits are AI-assisted. When a bug surfaces six months from now in code that was half-written by Claude Code, your team will have no signal about which parts to scrutinize first. The 97% of developers who don't fully trust AI code are doing extra review work today — and still leaving the audit trail blank.

What Engineering Teams Are Actually Doing About It

The McKinsey February 2026 study (4,500 developers, 150 enterprises) found that AI reduced time on routine coding tasks by 46% on average. Teams that saw the highest gains shared one characteristic: they had explicit policies about where AI was used and explicit processes for verifying the output.

In practice, that looks like:

• →

Tiered review gates. AI-flagged commits (via Co-Authored-By trailers or explicit markers) get an additional reviewer on security-sensitive paths. Non-flagged commits follow standard review. This only works if the attribution exists.

• →

AI-free zones. Auth systems, payment processing, and data handling code is documented as requiring human-only authorship. Enforced not culturally but tooling-enforced at CI.

• →

Audit dashboards. Engineering leaders want answers to "what percentage of our codebase is AI-generated?" — not out of fear, but because it correlates with review load, onboarding difficulty, and long-term maintenance cost. Right now most can't answer the question.

One underreported finding from the same McKinsey study: new developer onboarding time — measured by "time to 10th PR" — was cut in half across the companies studied, from Q1 2024 through Q4 2025. This is behavioral data from actual PR records. AI is dramatically compressing the junior-to-productive timeline. But that compression only holds if the AI-assisted code those new developers ship is reviewable, attributable, and maintainable. Without attribution, you're front-loading velocity and back-loading the debt.

The Attribution Layer Is Missing

The trust paradox won't resolve by making AI better. Developers already use tools they don't fully trust — and use them more as trust increases, which means the verification surface grows too. The resolution requires infrastructure: a way to know, in any git repository, which commits are AI-assisted, which tool wrote them, and at what density.

Claude Code adds Co-Authored-By: Claude trailers by default. That's the closest thing to a standard that exists today. But most AI tools leave no trace — Cursor, GitHub Copilot, and Windsurf don't write to git history. The developers using those tools are in the 73% who use AI daily and the 97% who don't fully trust it — and they have no tooling to audit the boundary.

What gitintel scan finds in a typical repo today

$ gitintel scan --format summary

Scanned: 500 commits AI-attributed: 31 commits (6.2%) ← Co-Authored-By detectable AI-invisible: ~unknown ← Copilot, Cursor, inline paste

Attribution coverage: incomplete Recommendation: Add .gitintel.yml policy file

The 3% who fully trust AI code may be the most rational actors in the survey. They've either built verification workflows that work, or they work on codebases where the consequences of AI errors are low. The 46% who distrust it but use it daily are operating on instinct. What they need is data — and the data starts with attribution.

Find out what's actually in your git history

GitIntel scans your repo for AI attribution signals and tells you how much of your codebase is AI-generated — and from which tools.

# Install GitIntel
curl -fsSL https://gitintel.com/install.sh | sh

# Scan your repo
cd your-repo && gitintel scan

View on GitHub

Open source (MIT) · Local-first · No data leaves your machine

Data sources: Developer Survey Feb 2026 (n=15,000); METR independent study (16 developers, 246 tasks); McKinsey Feb 2026 (4,500 devs, 150 enterprises). Published March 29, 2026.

---

Related reading on GitIntel:

• AI Makes Developers 19% Slower. They Think They're 20% Faster.
• AI Coded It. You Can't Debug It. Anthropic Has the Data.
• AI Writes Your Code. Nobody Understands It. Here's the Data.