26% More Tasks Completed With AI, But Code Commits Up Only 13.5%—Where's the Other 12.5% Going?

[brian_opensource]

26% More Tasks Completed With AI, But Code Commits Up Only 13.5%—Where’s the Other 12.5% Going?

I’ve been using AI coding assistants heavily for the past 6 months, and something weird is happening. I feel dramatically more productive. My task list moves faster. I close more Jira tickets. My manager is happy.

But when I look at my git log? It tells a different story.

The Numbers Don’t Add Up

New research just dropped showing developers using AI complete 26% more tasks on average compared to control groups. That’s huge! But here’s the thing that’s been bothering me: code commits only increased 13.5%.

So where’s the other 12.5% going?

At first I thought maybe it was a measurement error. But the more I dig into my own work patterns, the more I realize this gap is real — and it’s actually kind of fascinating.

What Tasks Are We Completing That Don’t Show Up in Commits?

I started tracking my own time over the past two weeks to figure this out. Here’s what I found:

1. Code Review & Architecture Discussions
AI helps me prepare way better for PR reviews. I can quickly spin up alternative approaches, test edge cases, and understand context faster. This shows up as “completed task: review Sarah’s PR” but creates zero commits.

2. Learning & Research
When I need to understand a new library or pattern, AI compresses what used to take 3 hours of documentation reading into 45 minutes of conversation. I complete “research authentication patterns” but my git history is silent.

3. Refactoring & Cleanup
This is the big one. AI makes it so much easier to refactor code that I actually do it now instead of putting it off. But refactoring often doesn’t create new commits — it modifies existing code. Sometimes I spend 2 hours cleaning up technical debt and end up with 1 small commit.

4. Meetings & Collaboration
I prepare for standups faster, generate better documentation for design reviews, and create clearer technical specs. All of this shows up as “completed prep for sprint planning” but produces no code.

5. Documentation
I’m embarrassed to admit I used to skip writing docs. Now AI makes it easy enough that I actually do it. But we track docs separately from code in Notion, so again — completed task, no commit.

The Measurement Problem

Here’s what I think is happening: our task tracking systems measure work effort, but our version control systems measure code output. And increasingly, those aren’t the same thing.

When I complete a task called “investigate database performance issue,” that might involve:

• 30 min: Set up profiling (AI-assisted)
• 45 min: Analyze query patterns (AI-generated analysis)
• 60 min: Research optimization techniques (AI-accelerated learning)
• 15 min: Write recommendation doc (AI-drafted)
• 10 min: Create one 5-line code change

Total time: 2.5 hours. Commits created: 1 tiny change. Tasks completed: 1

Pre-AI, I might have skipped steps 2-4 and just tried a random optimization. Same 1 commit, but way less effective work.

So What Does This Mean?

I’m genuinely curious if this resonates with others. Are we measuring the wrong things? Or is the “missing” 12.5% actually valuable work that just doesn’t show up in traditional metrics?

The cynic in me worries we’re just getting better at looking productive without being productive. But the optimist thinks maybe we’re finally doing the important-but-invisible work we’ve always skipped — the research, the documentation, the thoughtful preparation.

What’s your experience? Where does the productivity gap show up in your work?

Are you seeing the same pattern — feeling more productive but not seeing it reflected in traditional output metrics? And if so, how do you talk about this with leadership when they ask “show me the ROI”?

I’d love to hear what others are experiencing. Especially curious if engineering managers are seeing this at team level, or if this is just an individual contributor phenomenon.

---

Context: I’m a design systems lead but spend ~40% of my time in code. Been using Cursor + Copilot + Claude Code for about 6 months. Team of ~25 engineers + designers.

[eng_director_luis]

This resonates hard. I’m seeing the exact same pattern at team level with my 40+ engineers, and the numbers are almost spooky similar.

Our Team Data Confirms Your Hypothesis

We deployed AI coding assistants across the team 9 months ago. Here’s what our metrics show:

• Tasks completed: ↑ 21% (measured via Jira)
• Sprint velocity: Unchanged (measured via story points)
• PR volume: ↑ 30% (more code being proposed)
• PR review time: ↑ 91% (yes, nearly doubled)

That last number is the kicker. The “missing productivity” isn’t missing — it’s stuck in code review.

The Junior vs Senior Split

Your point about different types of work is spot on, but there’s another dimension: experience level.

Our data shows:

• Junior engineers (0-3 years): 21-40% productivity gains
• Senior engineers (7+ years): 7-16% productivity gains

At first I thought “great, AI is democratizing experience!” But when I dug deeper, here’s what’s actually happening:

Juniors are using AI to:

• Compress their learning curve (6-8 weeks onboarding → 3-4 weeks)
• Generate boilerplate faster
• Complete well-defined tasks independently

Seniors are spending their “productivity gains” on:

• Reviewing AI-generated code more carefully (1.7x more issues per PR)
• Mentoring juniors who skip the struggle that builds understanding
• Architectural decisions and system design (no commit metrics)
• Refactoring to fix AI-introduced technical debt

So the productivity isn’t evenly distributed. Juniors go faster, seniors do more invisible work.

The Real Question: Individual Speed or Team Throughput?

Here’s where it gets uncomfortable. If I optimize for individual developer productivity, AI is a massive win. But if I optimize for team-level throughput, the picture is murkier.

Think about it:

• More code being written → More review burden → Review becomes bottleneck
• Faster task completion → More context switching → Less deep work time
• AI-assisted coding → Less learning-by-doing → Knowledge concentration in seniors

We’re essentially trading individual efficiency for organizational effectiveness.

What I’m Telling Leadership

When our CFO asks “show me the ROI,” I’ve started framing it differently:

Don’t measure commits. Measure capability unlocked.

• Can we take on more ambitious architecture work? Yes
• Can we respond to customer issues faster? Yes
• Can we onboard new engineers quicker? Yes
• Can we maintain quality while moving faster? Still figuring this out

The 12.5% gap you’re seeing? I think it represents coordination overhead and quality gates. We’re writing more code but spending proportionally more time making sure it’s good code.

Which, honestly, might be exactly what we should be doing.

---

Curious: Has anyone found a way to measure “AI-assisted work” separately from “human-authored work” in a way that actually helps with planning? We’re experimenting with PR templates that ask devs to self-report % AI-generated, but early results are… inconclusive.

[diana_data]

This is the conversation every CTO is having with their CFO right now. Let me add the executive strategic view.

The ROI Reality Check

We deployed AI coding assistants 9 months ago across our 120-person engineering org. The experimental phase is over. Now finance wants answers.

The data you’re both sharing matches what we’re seeing, but here’s what I’m telling the board:

The 12.5% gap isn’t “missing productivity” — it’s showing up in stuff that matters but doesn’t ship.

Let me break that down:

Better Architecture Decisions

We’re prototyping 3-4 different approaches before committing to one, instead of picking the first thing that works. This doesn’t create more commits — it creates better commits. But it takes time.

Last quarter we avoided what would have been a 6-month architectural dead end because an engineer spent 2 days AI-assisted exploration. Zero commits in those 2 days. Massive ROI long-term.

Reduced Technical Debt

AI makes refactoring less painful, so engineers actually do it. Our technical debt backlog is down 18% YoY — first time in 3 years it’s decreased.

But refactoring doesn’t increase commit count. It often reduces it (consolidating code, removing duplicates).

Knowledge Distribution

Senior engineers can share context faster. Documentation quality is up. Onboarding time is down. None of this shows up in git logs.

The Quality Tax

Here’s the uncomfortable truth though: We’re also seeing a 9% increase in bugs per developer according to research. That tracks with our incident metrics — we’ve had 3 production issues in the past quarter traced back to AI-generated code that looked correct but failed under load.

So some of that “12.5% gap” is also showing up in:

• More thorough code review
• Post-deployment monitoring
• Bug fixes and hotfixes
• Process improvements to catch AI errors

Is that productivity loss or necessary quality control? Depends on your time horizon.

The Metrics Trap

@eng_director_luis hit on something important: We’re optimizing for the wrong thing if we measure commits.

I’ve started shifting our conversation with the board from “output per engineer” to “capability unlocked per quarter.”

Questions I’m asking now:

• Can we execute a more ambitious roadmap with the same headcount? Yes — we’re handling 40% more complex work without new hires
• Can we respond to market opportunities faster? Yes — prototype-to-production time down 35%
• Are we building sustainable velocity or burning it down? TBD — watching technical debt metrics closely

That third one is the key. Year 1 AI gains might become Year 2 maintenance costs if we’re not careful.

What I’m Not Saying in Board Meetings (But Probably Should)

The real answer? We’re in a transition period where old metrics don’t capture new workflows.

It’s like measuring factory productivity in 1920 using metrics from 1900. The assembly line changed what productivity meant, not just how much of it you got.

AI is doing the same thing. The question isn’t “did commits go up 26%?” It’s “are we building the right things faster, with sustainable quality?”

And honestly? I don’t think we have good metrics for that yet.

---

Has anyone successfully reframed this conversation with finance/board in a way that doesn’t sound like “trust me bro, it’s working”? Because right now I’m showing them lagging indicators (incidents down, uptime up, NPS stable) and hoping that’s enough to justify the AI spend.

[customer_dev]

Product perspective here — and I think the 12.5% gap tells a different story than you might want to hear.

Engineering Velocity ≠ Product Velocity

Here’s what I’m seeing from the product side:

Engineering says: “We’re completing 26% more tasks!”
Product reality: Feature delivery timeline hasn’t changed.

Last quarter we shipped 3 features ahead of schedule. Sounds great, right? Except 2 of them completely missed the mark — usage was 30% of what we projected.

The Real Bottleneck Shifted

Pre-AI workflow:

1. Product spec (1 week)
2. Engineering build (3 weeks) ← bottleneck
3. Beta test (2 weeks)
4. Customer validation (3 weeks)
5. Iterate (2 weeks)

Post-AI workflow:

1. Product spec (1 week)
2. Engineering build (2 weeks) ← 33% faster!
3. Beta test (2 weeks) ← new bottleneck
4. Customer validation (3 weeks) ← new bottleneck
5. Iterate (2 weeks) ← new bottleneck

We optimized engineering but the total cycle time barely changed. The constraint moved from “can we build it?” to “should we build it?”

Where I Think the 12.5% Is Going

Three hypotheses:

1. Fake Productivity — Building the Wrong Things Faster

When engineering velocity is no longer the constraint, we’re shipping features before we’ve validated demand. That’s not productivity — that’s waste.

I have engineers asking “what should I build next?” when we’re still waiting on customer feedback from the last sprint. The faster we build, the more we outpace our ability to validate.

2. The Discovery Gap

AI helps with “how do I implement X” but not “should we build X or Y?”

We still need:

• 3-4 weeks for customer interviews
• 2-3 weeks for beta testing
• Multiple iterations to find product-market fit

Those timelines didn’t compress. So engineering’s 26% productivity gain hits a wall when it reaches product discovery.

3. The Coordination Tax

More PRs = more deploys = more coordination overhead = more product-engineering sync meetings.

My calendar went from 40% meetings to 55% meetings because engineering is moving faster and needs more frequent product guidance.

Is that productivity? Or are we just churning faster?

The Question I’m Wrestling With

Should we be using AI to help with discovery, not just delivery?

What if instead of using AI to write code faster, we used it to:

• Analyze user research faster
• Generate customer interview questions
• Identify usage patterns in analytics
• Prototype concepts for user testing

Because right now, we have a Formula 1 engine attached to a horse cart. Engineering is flying, but we’re still doing product discovery the same way we did in 2020.

What I’m Measuring Now

I stopped celebrating “shipped early.” Started measuring:

• Learning velocity: How fast do we validate/invalidate hypotheses?
• Feature success rate: What % of shipped features hit usage targets?
• Iteration speed: How fast do we go from “shipped” to “validated”?

On those metrics? We’re actually slower than before, because we’re shipping more features that need more iteration.

The 12.5% gap might be showing up in rework, iteration, and backtracking.

---

Honest question for the engineers: Would it be more valuable if I gave you fewer features to build, but we spent more time upfront validating them? Or is fast iteration still the right model even if it means more throwaway work?

[alex_dev]

Coming at this from an org effectiveness lens, and I think we’re all dancing around the real issue:

The 12.5% gap is showing up in people work, not code work.

Let me explain what I’m seeing at our EdTech startup.

The Hidden Labor Redistribution

When we rolled out AI coding assistants 8 months ago, I started tracking not just what got done, but who was doing the invisible work.

Here’s what happened:

Senior Engineers Became Full-Time Reviewers

Pre-AI:

• Senior eng: 60% coding, 20% review, 20% architecture/mentoring

Post-AI:

• Senior eng: 40% coding, 45% review, 15% architecture/mentoring

The 91% increase in review time that @eng_director_luis mentioned? That’s not evenly distributed. It’s falling disproportionately on senior engineers.

We went from 2-3 PRs per day to 5-7 PRs per day. Guess who’s reviewing all of them?

Junior Engineers Are Compressing Learning

Yes, onboarding time went from 6-8 weeks to 3-4 weeks. But here’s what we’re not measuring: What are they not learning by skipping the struggle?

I had a junior engineer ship a feature in 2 days that would have taken them 5 days pre-AI. Amazing, right?

Then the feature broke in production because they didn’t understand the edge case the AI code didn’t handle. A senior eng spent 6 hours debugging and explaining the underlying system design.

Net productivity gain: Negative.

The Mentorship Tax

I’m spending 4-6 hours per week having conversations that didn’t used to be necessary:

• “Why did the AI suggest this pattern?”
• “How do I know when the AI-generated code is wrong?”
• “What should I learn vs what can I let AI handle?”

This is valuable work! But it doesn’t show up in task completion metrics. It shows up as me closing fewer tickets.

The Organizational Debt Problem

This is the part that keeps me up at night. We’re creating three types of organizational debt:

1. Knowledge Concentration

• Seniors understand AI-generated code patterns
• Juniors can use AI but can’t evaluate its output
• Knowledge gap widening, not narrowing

2. Review Bottleneck

• Can’t scale code review at the same rate we scale code generation
• Senior eng review capacity is the new constraint
• Hiring more seniors doesn’t help (they need context/trust)

3. Cultural Shift

• Used to value “deep understanding”
• Now incentivizing “fast shipping”
• Losing engineers who care about craft over velocity

Where the 12.5% Is Really Going

I think it’s going to:

• Coordination overhead: More PRs = more context switching
• Quality assurance: Reviewing AI code takes different (more?) energy than reviewing human code
• Knowledge transfer: Seniors teaching juniors what AI didn’t teach them
• Process evolution: Figuring out how to work in this new world

None of that shows up in commits. All of it is essential work.

The Framework I’m Using: Two-Track Development

We’re experimenting with explicitly splitting work:

Track 1: Human-Led (40% of features)

• Complex architecture decisions
• Customer-facing critical paths
• Learning opportunities for juniors
• AI assistance allowed, but human-first

Track 2: AI-Assisted (60% of features)

• Well-defined patterns
• Refactoring and cleanup
• Tooling and internal systems
• AI-first, human review required

Early results: Track 1 velocity down 10%, Track 2 velocity up 40%, overall quality up 15%.

We’re optimizing for long-term organizational health, not just short-term output.

The Equity Question Nobody’s Asking

Who benefits from AI productivity gains?

• Juniors get faster (but shallower learning)
• Seniors get busier (more review, more mentoring)

Who pays the cost?

• Seniors (burnout risk from review load)
• Juniors (skill development gaps)
• The organization (knowledge concentration)

We’re redistributing work in ways that aren’t sustainable. The 12.5% gap is a symptom of that redistribution.

---

@maya_builds Your point about doing “important-but-invisible work” resonates. But I’d add: Some of that invisible work is organizational debt accumulation that we’re not tracking yet.

Anyone else rethinking their entire engineering onboarding and career ladder because of this shift? Because I am, and I have no idea what the right answer is.