Here’s a stat that made me pause: GitHub Copilot suggests code constantly, but only about 30% of those suggestions get accepted by developers. Meanwhile, 84% of developers are using AI tools daily.
So what’s actually happening here? Are we getting value, or are we just clicking “dismiss” all day?
The Acceptance Rate Paradox
According to Index.dev’s 2026 developer productivity statistics, AI coding assistants are now ubiquitous — but acceptance rates remain stubbornly low. This seems like a contradiction, but I think it tells a more nuanced story.
My theory: AI tools aren’t valuable because of what we accept. They’re valuable because of what they show us.
How I Actually Use AI Suggestions
When I’m coding with AI assistance, here’s what really happens:
- Direct accept (~30%): The suggestion is exactly right, I tab and move on
- Partial accept (~25%): I take the structure but modify implementation details
- Inspiration accept (~20%): The suggestion is wrong, but it reminds me of what I should write
- Dismiss with learning (~15%): Seeing the wrong suggestion helps me understand the problem better
- Pure dismiss (~10%): Completely irrelevant, adds no value
If you only count category 1, you get 30% acceptance. But categories 2-4 are still providing value.
The METR Study Findings
What really concerns me is the METR study showing experienced developers are objectively 19% slower with AI tools while believing they’re 20% faster. That perception gap is alarming.
Possible explanations:
- Context switching cost of evaluating AI suggestions
- Time spent crafting prompts could exceed time saved
- AI suggestions pull you toward average solutions, away from optimal ones
- The “illusion of productivity” from more keystrokes
What I’ve Changed In My Workflow
Based on this research, I’ve modified how I use AI tools:
- Disable inline suggestions for complex logic — AI derails my thinking flow
- Use AI for boilerplate explicitly — “Write the Prisma schema for this model”
- Ask for alternatives, not solutions — “What are 3 ways to handle this error?”
- Review AI-generated code like I’d review a junior dev’s PR — don’t just accept
The Uncomfortable Question
Are we using AI tools because they help us, or because we’re afraid of falling behind if we don’t?
I’ve talked to developers who admit they keep Copilot on not because it helps, but because it feels weird to code without it now. That’s concerning.
What’s your experience? Are you actually more productive with AI tools, or have you just gotten used to them?
Alex, your category breakdown really resonates with me. Coming from a design systems background, I see a parallel to how we evaluate design tool suggestions.
The “inspiration accept” category is undervalued.
When Figma’s auto-layout suggests a pattern I wouldn’t have thought of, even if I modify it heavily, that’s valuable. The suggestion opened a door I wasn’t looking at.
My experience with AI code suggestions (from a non-expert coder):
I use AI tools for HTML/CSS and light React work. For someone at my skill level, the dynamics are different:
- I accept more suggestions (~45%) because I’m not as confident in my own patterns
- BUT I’m also less able to evaluate if the suggestion is good
- I’ve shipped code that “worked” but was architecturally weird
- Sometimes AI helps me punch above my weight; sometimes it teaches me bad habits
The fear of falling behind is real.
I remember when designers without Figma skills felt left behind. Now it’s developers without AI fluency. The FOMO is driving adoption as much as productivity gains.
The question I’d add:
How do we measure if AI tools are making us better engineers long-term, vs. just faster at producing code today?
If AI handles all my boilerplate, will I still understand the fundamentals in 5 years? Or am I trading deep knowledge for shallow velocity?
I want to add the security angle to this conversation.
The 23.7% increase in security vulnerabilities in AI-assisted code isn’t about acceptance rates.
It’s about which suggestions get accepted. The studies showing security issues aren’t claiming AI writes more insecure code than humans on average. They’re showing that developers accept AI suggestions without security review at higher rates than they’d accept their own code.
Why this happens:
- Authority bias — “The AI must know what it’s doing”
- Cognitive load — reviewing AI suggestions is tiring; after 50, you start auto-accepting
- Different mental mode — when you write code, you’re in problem-solving mode; when reviewing AI code, you’re in verification mode, which catches fewer issues
- Unfamiliarity — I might accept a suggestion using an API I don’t fully understand
The METR study’s 19% slowdown makes sense from this lens.
Experienced developers are slower because they’re correctly reviewing AI suggestions. The ones who accept faster (and feel more productive) are the ones shipping vulnerabilities.
What I recommend to teams:
- Treat AI-generated code like third-party code — security review it
- Set acceptance rate targets — if your team’s acceptance rate is above 50%, you’re not reviewing enough
- Track which categories of suggestions have bugs — AI is worse at some things
- Create “no AI zones” — for auth, crypto, and security-critical code, disable suggestions
The 30% acceptance rate might actually be the right number for security-conscious development.
This thread is touching on something I’ve been thinking about as a leader: how do we set organizational norms around AI tool usage?
The individual vs. organizational perspective:
For individual developers, the question is “does this help me?”
For organizations, the questions are different:
- Does this help us ship better products?
- Are we building durable skills or creating dependencies?
- What are the second-order effects on code quality, security, knowledge transfer?
What I’m seeing organizationally:
- Productivity metrics look good — cycle time down, deployment frequency up
- Quality metrics are mixed — some teams better, some worse
- Knowledge metrics are concerning — onboarding takes longer because new devs can’t read “AI-style” code written by their teammates
The policy question:
Should organizations have AI tool policies beyond “use what helps you”?
Some options I’ve considered:
- Mandatory code review for AI-generated changes
- AI-free zones for security-critical code (as Sam suggests)
- Training requirements before AI tool access
- Team-level acceptance rate dashboards
What I’ve actually implemented:
We require that all AI-generated code be attributed in commit messages. Not for blame, but for tracking. After 6 months, we can see patterns: which types of AI code have more bugs, which developers are using AI effectively, where the risks are.
It’s not perfect, but it’s a starting point for evidence-based policy.
The uncomfortable truth:
I don’t know if AI tools are net-positive for my engineering org yet. The data is genuinely mixed. But I do know that ignoring them isn’t an option — everyone expects them, and not using them feels like falling behind, even if the evidence for productivity gains is shaky.
That’s not a great reason to adopt technology, but it’s the reality we’re navigating.