Everyone's using AI to code, but productivity is still only up 10%. What are we missing?

maya_builds · March 14, 2026, 6:29pm

I learned more from my startup failure than from any success I’ve had. And right now, watching the AI coding revolution, I’m seeing the same pattern that killed my company: tools that promise transformation but miss the actual constraint.

David’s thread got me thinking hard about this productivity paradox. Let me share what I’m seeing from the design and builder perspective.

The disconnect in the data

Let’s lay out the numbers that don’t add up:

92% of developers use AI coding tools daily (near-universal adoption)
AI-driven onboarding: 30-40% faster than manual processes
Each DX improvement = 13 min/week saved per developer
Simple tasks (restructuring, tests): 90% speedup with AI
Yet real-world productivity: only 10% improvement

How do you get 92% adoption, massive time savings on specific tasks, and DX improvements… but barely move the needle on overall productivity?

What my failed startup taught me

Back in 2019, we built a visual programming platform. Beautiful interface. Drag-and-drop everything. “Build apps without code!”

We had users who loved it. Testimonials about how fast they could prototype. Metrics showing 5x faster time-to-first-screen compared to traditional dev.

And yet… adoption stalled. People prototyped fast, then got stuck. The tool was amazing at the easy part. But software isn’t just the easy part.

Sound familiar?

Where AI actually helps (my real experience)

I use Cursor and v0 every day for side projects. The 90% speedup number? That’s real, but only for specific tasks:

What’s genuinely 90% faster:

Scaffolding components (“create a card component with these props”)
Writing tests (especially boilerplate unit tests)
Restructuring code (refactoring, moving files)
Converting designs to code (v0 is shockingly good at this)

What’s maybe 10-20% faster:

Complex architecture decisions (AI gives starting points I rewrite)
Debugging production issues (AI suggests possibilities, I verify)
Performance optimization (requires deep understanding)
Integration work (connecting systems, handling edge cases)

What AI doesn’t help with:

Figuring out what users actually need
Deciding which features to prioritize
Making product strategy calls
Coordinating with other teams
Convincing stakeholders
Understanding business constraints

The actual software development breakdown

Here’s what I think we’re missing. Software isn’t mostly code generation.

When I think about a typical feature from idea to production:

Understanding the problem: 20%
Designing the solution: 15%
Writing code: 25% ← AI helps here
Code review and iteration: 10%
Testing and QA: 10%
Debugging and fixing: 10%
Deployment and monitoring: 5%
Documentation: 5%

AI absolutely crushes that 25% code-writing portion. Maybe gets it down to 5%. That’s an 80% reduction in one part.

But 80% reduction in 25% of the workflow = 20% overall improvement at absolute best.

And that’s assuming:

Requirements are crystal clear (they’re not)
No architectural debates (there are)
No integration complexity (there is)
Code works first try (it doesn’t)
No debugging needed (lol)

In reality? The 10% productivity gain sounds about right.

The Vercel moment vs. the vibe coding moment

Michelle mentioned zero-config platforms. There’s an important distinction:

Vercel’s zero-config deployment works because deployment is actually the bottleneck.

When deployment takes hours of AWS configuration, making it 1-click is genuinely transformative. You’ve eliminated the constraint.

Vibe coding is fast at code generation, but is code generation the bottleneck?

For most teams I talk to, the constraints are:

Clarity: What should we build?
Coordination: How do teams work together?
Quality: Does it actually work at scale?
Strategy: Are we building the right thing?

Writing the code? That’s often not the slow part.

Are we measuring the wrong thing?

Maybe the question isn’t “why only 10% productivity increase” but “what are we trying to be productive at?”

If we measure productivity as “lines of code per week,” AI wins massively.

But if we measure productivity as:

Customer problems solved
Revenue generated
User satisfaction improved
Technical debt reduced
Time to validated learning

Then suddenly the 10% makes more sense. Because most of that isn’t code generation.

The design parallel

This reminds me of design tools evolution:

Sketch made designing UI faster (digital vs. paper prototypes)
Figma made collaboration better (multiplayer, real-time)
Design systems made consistency easier (tokens, components)

Each tool improved one dimension. None made “product design” 10x faster overall, because product design isn’t just pushing pixels. It’s:

Understanding users
Making strategic choices
Balancing constraints
Communicating with teams
Iterating based on feedback

Sound familiar?

What I think this means

We’ve automated the symptom, not the disease.

The disease: Building software is complex because:

Requirements are ambiguous
Systems are intricate
Users are unpredictable
Integration is hard
Quality takes time

Vibe coding addresses: “Writing code is tedious.”

Which… sure. But was that really the core problem?

My questions for this community

Are we measuring the wrong productivity metrics?

Should we track code velocity or customer value delivered?

Is the bottleneck thinking, not typing?

If AI writes code instantly but we still need 3 meetings to decide what to build, did we solve anything?

Do we need better AI, or better problems to solve?

Maybe 10% is the right number because we’ve optimized the part that was already pretty optimized.

Where I’m landing

I’m genuinely bullish on vibe coding for what it’s good at: eliminating boilerplate, speeding up prototyping, lowering barriers to creation.

But I think we oversold what it would transform.

Code generation was never the constraint for most teams. Knowing what to build, building it well, and shipping it reliably were the constraints.

AI helps with the first 25% of that. The other 75%? Still on us.

Maybe that’s why productivity is only up 10%. And maybe 10% is actually pretty good when you solve for the right problem.

What are others seeing? Am I being too cynical? Too optimistic? Are your teams hitting different bottlenecks than code generation?

product_david · March 14, 2026, 6:29pm

Maya, you just articulated what I’ve been struggling to explain to my leadership team. “We’ve automated the symptom, not the disease.” That line is gold.

From the product side: You’re exactly right

I’ve been tracking our team’s velocity since we started using AI tools heavily (about 8 months ago). Here’s what I’m seeing:

Code output: Up 40-50% (engineers write more code per sprint)
Features shipped: Up maybe 10-12% (barely moved)
Customer value delivered: Honestly unclear (maybe slight increase?)

Your breakdown of where time actually goes? Spot on from product POV.

Where product time actually goes

When I look at our product development cycle:

Customer discovery (interviews, research, data analysis): 25%
Prioritization (stakeholder alignment, roadmap debates): 15%
Requirements clarity (specs, designs, edge cases): 20%
Implementation (engineering, design, QA): 30% ← AI helps here
Launch and measurement (GTM, instrumentation, analysis): 10%

Even if AI makes implementation 50% faster (generous estimate), that’s:

30% of cycle × 50% faster = 15% overall improvement

And that assumes:

We had clear requirements (we don’t)
Eng didn’t come back with questions (they do)
First version worked (it doesn’t)
No iteration needed (always needed)

Your 10% productivity number tracks perfectly with my data.

“Implementation acceleration” not “product acceleration”

This distinction matters for how we think about investment.

What AI coding does: Makes implementing a well-specified feature faster

What it doesn’t do:

Figure out what users actually need
Decide between competing priorities
Validate assumptions cheaply
Navigate organizational complexity
Get stakeholder buy-in
Measure whether it worked

From product lens: Most of our time is spent on the “doesn’t do” list.

The framework gap

You mentioned your startup failure. Here’s the parallel I see:

Your visual programming tool: Made building screens fast, but couldn’t help with “what should the screen do?”

Vibe coding today: Makes writing code fast, but can’t help with “what should the code accomplish?”

Both solve implementation speed when the real challenge is strategic clarity.

Customer development can’t be AI-generated

I spend 10-15 hours per week on:

Customer interviews
Usage data analysis
Competitive research
Experimentation planning
Stakeholder communication

AI helps me with: Transcribing interviews? Sure. Summarizing data? Maybe.

But the actual insight work—connecting dots, identifying patterns, making strategic bets—that’s still 100% human.

And that’s where most of product value comes from.

Are we measuring wrong? Yes.

You asked if we’re tracking wrong metrics. From product side, absolutely yes.

What we measure (because easy):

Story points completed
Lines of code written
PRs merged
Features shipped

What actually matters (but harder to measure):

Customer problems solved
User satisfaction improved
Revenue impact
Strategic positioning strengthened
Technical foundation built

AI helps with the first list. Barely touches the second list.

We’re optimizing for what’s measurable, not what matters.

The real productivity opportunity

Here’s where I think we’re leaving gains on the table:

AI is great at generating code. We’re still bad at:

Knowing what to build (product discovery)
Building the right thing (strategy)
Building it the right way (architecture)
Knowing if it worked (measurement)

If we want more than 10% productivity gains, we need tools/process/culture for those four things.

Vibe coding won’t fix product-market fit. It won’t fix unclear requirements. It won’t fix poor prioritization.

Those are the real bottlenecks. And they’re human problems, not coding problems.

My take: 10% is actually impressive

Given that code generation was maybe 20-25% of the product development cycle, getting 10% overall improvement means we’re capturing most of the available gains.

To get to 30-50% productivity improvement, we’d need AI that:

Conducts customer research
Makes strategic product decisions
Prioritizes features based on business impact
Designs scalable architectures
Validates assumptions through experimentation

We’re not there. Maybe we never get there (some of this requires human judgment).

So yeah, 10% might actually be the right number.

What I’m doing differently

Based on this realization, I’m shifting how we think about AI:

Before: “AI will 10x our eng productivity”
Now: “AI will eliminate toil, freeing engineers for higher-value work”

Before: Measure code velocity
Now: Measure customer impact

Before: Invest in better AI coding tools
Now: Invest in better discovery, prioritization, and measurement

Bottom line

You nailed it: We solved the part that was already pretty optimized.

Code generation was tedious, but it wasn’t the constraint. The constraint is knowing what to build and building the right thing.

Until AI can do customer development, strategic thinking, and organizational navigation, productivity gains will be limited.

And honestly? I’m not sure I want AI doing those things. That’s where product craft lives.

Maybe 10% is exactly what we should expect. And maybe that’s perfectly fine.

cto_michelle · March 14, 2026, 6:30pm

Maya, this is the conversation engineering leadership needs to have. Your analysis is sharp, and the startup failure parallel is instructive. Let me add the organizational systems perspective.

“More code, fewer releases” - The 2026 blind spot

This isn’t just theory for me. I’m living it.

Our data over the past 6 months:

Engineers write 59% more code with AI (matches industry)
Pull requests created: +47%
Releases per sprint: +3% (basically unchanged)
Customer-facing features shipped: +8%

We automated code writing. The bottleneck moved.

The system constraint moved, we didn’t notice

This is classic Theory of Constraints (Goldratt). When you optimize one part of a system, throughput only improves if you optimized the constraint. Otherwise, you just create a different bottleneck.

Before AI:
Constraint was often “writing the code takes too long.”

With AI:
Constraint is now:

Code review (more code to review, same reviewer capacity)
Testing (more code means more test scenarios)
Integration (code written in isolation, integration complexity unchanged)
Deployment (our CD pipeline hasn’t gotten faster)
Monitoring and debugging (more code = more surface area)

We made one part of the system faster. The rest of the system didn’t speed up.

Result: Backlog builds up in review, testing, integration. Overall velocity barely changes.

The data that opened my eyes

I ran a detailed analysis of our eng cycle time (idea → production):

Phase	Time Before AI	Time With AI	Change
Requirements/Design	3.2 days	3.1 days	-3%
Implementation	4.5 days	2.1 days	-53%
Code Review	1.8 days	2.4 days	+33%
QA/Testing	2.2 days	2.3 days	+5%
Deploy/Monitor	0.8 days	0.9 days	+13%
Total	12.5 days	10.8 days	-14%

Implementation time cut in half! But code review increased (more volume), testing slightly up, deployment unchanged.

Net result: 14% improvement. Close to your 10% industry number.

Why code review is now the bottleneck

This surprised me: Code review taking longer despite faster implementation.

Reasons:

Volume: More code to review per week
Complexity: AI-generated code often needs deeper scrutiny (Luis’s security concern)
Understanding: Reviewers asking “why did you do this?” → Engineer: “AI suggested it” → Deeper investigation needed
Quality variance: Sometimes AI code is great, sometimes concerning, hard to predict

We haven’t scaled our review process for AI-speed development.

The delivery infrastructure gap

Your question: “Is the bottleneck thinking, not typing?”

From organizational view: The bottleneck is delivery systems, not development speed.

We’ve made development faster. But:

CI/CD pipelines: Same speed as before
Test infrastructure: Same capacity
Deployment processes: Same manual steps
Monitoring/observability: Same tooling
Incident response: Same processes

It’s like adding a faster engine to a car but keeping the same transmission, brakes, and tires. You won’t go much faster overall.

The question I’m asking my team

Should we redesign our delivery systems for AI-speed development?

What if we:

Invested in automated code review (AI reviewing AI-generated code)
Rebuilt test infrastructure for 2x volume
Implemented progressive delivery (feature flags, canary deploys)
Enhanced observability (better debugging for code we didn’t write)
Streamlined deployment (fully automated, no manual gates)

Could we actually capture the 50% implementation speedup as 30-40% overall improvement?

I don’t know. But I think the answer is “probably not without systemic change.”

Different bottlenecks for different teams

Maya, your breakdown was individual developer productivity. Let me add team dynamics:

For small teams (5-10 engineers):

Bottleneck: Often still requirements clarity or architectural decisions
AI helps: Some, but doesn’t solve core constraint
Expected productivity gain: 10-15%

For medium teams (20-50 engineers):

Bottleneck: Coordination, code review, integration, testing
AI helps: Minimal (might make coordination harder with more code)
Expected productivity gain: 5-10%

For large teams (100+ engineers):

Bottleneck: Organizational complexity, dependencies, process overhead
AI helps: Could actually hurt if process doesn’t adapt
Expected productivity gain: 0-5% (possibly negative!)

The larger your organization, the less code generation speed matters.

What if productivity IS up 90% but only for the right problems?

Here’s an alternative framing:

For well-specified, isolated problems with clear requirements:

AI-generated code works great
Minimal review needed
Testing straightforward
Deployment clean
Productivity: Maybe actually 50-90% improvement

For complex, ambiguous, integrated problems with evolving requirements:

AI-generated code needs heavy revision
Extensive review required
Integration testing complex
Deployment risky
Productivity: Maybe 0-10% improvement (possibly negative)

Most enterprise work is the second category. Most demos show the first category.

We’re averaging 90% gains on 20% of work with 5% gains on 80% of work = 12% overall.

Your math checks out.

What I’m changing organizationally

Based on this analysis, here’s what I’m doing:

Resetting expectations: AI will give us 10-20% productivity gains, not 10x
Investing in delivery infrastructure: CI/CD, testing, observability, deployment automation
Training reviewers: How to review AI-generated code effectively
Process adaptation: New workflows for AI-speed development
Measuring differently: Customer value shipped, not code written

The insight that matters

You said: “Maybe 10% is the right number when you solve for the right problem.”

From CTO perspective: 10% sustained productivity improvement is actually massive.

If we can deliver 10% more customer value per year, compound that over 5 years, that’s significant competitive advantage.

The mistake is thinking we’d get 10x overnight. The reality is 10-20% gains if we adapt our systems to capture them.

And honestly? I’ll take it.

Your question: “Are we measuring wrong?”

Yes. Absolutely yes.

We should measure:

Customer outcomes: Problems solved, value delivered
Business impact: Revenue, retention, NPS
System health: Reliability, security, performance
Team sustainability: Burnout, turnover, satisfaction

Not:

Lines of code
PRs merged
Story points

AI helps with code output. Doesn’t directly improve the things that actually matter.

So we need to measure and optimize for what actually matters.

And if we do that? 10% might actually be underselling the value. Or it might reveal we’re optimizing the wrong things entirely.

Great discussion, Maya. This is the strategic thinking we need.

eng_director_luis · March 14, 2026, 6:30pm

Maya, your honest take on startup failure teaching you more than success—that resonates. And your productivity analysis aligns with what I’m seeing on the ground with 40+ engineers.

The team effectiveness lens

I want to add the dimension of individual productivity vs. team productivity because I think that’s where the 10% number gets even more interesting.

What I’m observing with my teams

Individual contributor perspective:

Junior engineers: Code output up 60-70% with AI
Senior engineers: Code output up 20-30% with AI (they were already fast, AI helps with boilerplate)

But here’s the thing: Individual output ≠ team delivery.

The hidden costs nobody’s measuring

When juniors use AI heavily, I’m seeing:

Downstream cost increases:

Code review time up 40% - AI-generated code needs deeper scrutiny (security, performance, edge cases)
Bug tickets up 25% - Code works for happy path, fails on edge cases AI didn’t consider
Refactoring work up - AI optimizes locally, doesn’t see global architecture patterns
Mentorship time up - Juniors can generate code but can’t debug it, need more senior help
Integration friction up - Code written in isolation doesn’t compose well

Net effect on team velocity: Minimal. Maybe 10-15% improvement overall.

Your breakdown of where time goes? Matches what I see, except I’d add:

Fixing bugs from AI-generated code: 8%
Architectural rework: 7%
Cross-team coordination: 10%

All things AI doesn’t help with. Some things AI might make worse.

The “AI generates, humans cleanup” pattern

Here’s a pattern I’m seeing repeatedly:

Junior engineer: “I’ll use AI to build this feature” (2 days)
Code review: “This has security issues, performance problems, edge case bugs” (1 day review, 1.5 days rework)
QA: “Found these 8 bugs” (1 day to fix)
Senior engineer: “We need to refactor this to fit our architecture” (1 day)
Total: 6.5 days for what junior thought would be 2 days

Compare to senior engineer without AI:

Senior builds feature with architecture in mind (3.5 days)
Code review: Minor issues (0.5 days)
QA: 2-3 bugs (0.5 days)
Total: 4.5 days

AI made junior faster in isolation, but team slower overall.

This isn’t an argument against AI. It’s an argument that productivity is systemic, not individual.

The skills gap is real

You mentioned “knowing what to build.” From engineering leadership:

The skills that matter haven’t changed:

System thinking and architecture
Understanding tradeoffs and constraints
Debugging complex issues
Code review and quality judgment
Mentorship and knowledge transfer
Cross-team communication

AI helps with:

Syntax and boilerplate
Code generation for well-specified problems
Suggesting patterns (sometimes correctly)

But juniors learning via AI aren’t developing the first list. They’re getting good at prompting, not at the foundational skills.

Medium-term concern: Who becomes senior engineers if juniors skip the learning curve?

Where productivity actually is up (real examples)

To balance my skepticism, here’s where we DO see genuine gains:

Test generation: 70% faster

AI writes unit tests from function signatures
Catches edge cases humans might miss
Quality is good enough after review

Documentation: 50% faster

AI generates API docs, README files
Still needs human editing but solid starting point

Refactoring: 40% faster

Renaming, restructuring, moving code
Less risky than feature development

Prototyping: 60% faster

Throwaway code to test ideas
Quality doesn’t matter as much

So the pattern: Where quality bar is lower or task is well-defined, AI crushes it. Where quality and architecture matter, gains are minimal.

Maya’s question: “Is the bottleneck thinking, not typing?”

From engineering director view: Yes, and also coordination.

Our bottlenecks:

Clarity: What are we actually building? Why?
Architecture: How does this fit our systems?
Integration: How does this work with other teams’ code?
Quality: How do we ensure this is production-ready?
Knowledge: How do we preserve team understanding?

AI doesn’t help with any of those. Maybe makes some worse (less understanding, more volume).

The financial services constraint

In my context (Fortune 500 banking), our constraint is often risk management:

Security reviews
Compliance checks
Audit trails
Regulatory approval
Change management boards

Code generation speed is largely irrelevant when you spend 2 weeks in approval process.

We could write code 10x faster and ship features at the same rate because compliance process is the constraint.

Michelle’s system thinking is right

Her Theory of Constraints analysis is exactly what I’m seeing. We optimized the wrong part of the system.

If code review, testing, and deployment are bottlenecks, making code generation faster just builds up WIP (work in progress) in the pipeline.

We need to optimize the whole system, not one part.

What I’m doing differently

Based on this reality:

Setting realistic expectations: 10-15% team productivity gains, not 10x
Training on AI usage: When to use it, when not to, how to review AI code
Establishing quality gates: AI-generated code needs specific review checklist
Preserving learning: Juniors must explain code, not just generate it
Measuring team delivery: Not individual code output

My answer to “what are we missing?”

We’re not missing anything. 10% is the right number because:

Code generation was 20-30% of the work (you nailed this)
AI makes that part 50% faster
But adds overhead elsewhere (review, debugging, rework)
Net effect: 10-15% improvement

To get more, we’d need to:

Redesign delivery systems (Michelle’s point)
Solve requirements clarity (David’s point)
Fix coordination overhead (my point)
Address quality and review processes (Luis’s point)

All organizational and process challenges, not technology challenges.

The bottom line

10% sustained productivity improvement is actually impressive when you account for:

The hidden costs
The systemic constraints
The learning curve
The quality tradeoffs

Your startup failed because you solved the wrong problem. We’re in danger of declaring AI coding a failure for the same reason.

It’s not failing. It’s working exactly as it should—making code generation faster.

We just overestimated how much of our time was spent on code generation.

vp_eng_keisha · March 14, 2026, 6:30pm

Maya, I love how you framed this with your startup experience. Learning from failure is where real insight comes from. From my VP Eng seat scaling 25→80 engineers, let me add the organizational maturity and talent development angle.

10% isn’t the ceiling—it’s the floor

Here’s where I might be more optimistic than others in this thread.

I think 10% is what you get with zero organizational adaptation. Just drop AI tools into existing processes, workflows, and culture, you get 10%.

But what if we actually redesigned our organizations for AI-augmented development?

The maturity model I’m seeing

Based on watching teams adopt AI over the past year:

Phase 1: Tool Adoption (0-6 months)

Engineers start using AI coding tools
No process changes
Lots of experimentation
Productivity: ~5-10%
This is where most organizations are

Phase 2: Process Adaptation (6-18 months)

Redesign code review for AI-generated code
Update testing strategies
Modify onboarding and training
Clarify when to use AI vs. not
Productivity: ~15-25%
Early adopters entering this phase

Phase 3: Cultural Shift (18+ months)

Different hiring criteria (less syntax, more judgment)
Different skill development (architecture, review, orchestration)
Different workflows (AI-first vs. AI-augmented)
Different expectations (speed, quality, learning)
Productivity: ~30-40%?
Nobody here yet, but I’m betting this is possible

Why I think we can get beyond 10%

Michelle’s data showed implementation down 53% but code review up 33%, resulting in only 14% overall.

What if we adapted the review process?

AI-assisted code review (AI reviewing AI code for common issues)
Review checklists specific to AI-generated code
Pair review for AI-heavy PRs
Async review tools optimized for higher volume

Could we cut review time back down even with more volume?

Luis mentioned test generation is 70% faster. What if we applied similar gains to other phases?

Where gains compound

Your breakdown had code writing at 25% of the cycle. AI makes it 80% faster → 20% overall gain.

But what if AI also helps with:

Requirements (AI helps generate specs from conversations): 10% faster
Design (AI suggests architectural patterns): 15% faster
Testing (AI generates test cases): 50% faster
Documentation (AI writes docs): 40% faster
Debugging (AI suggests root causes): 20% faster

Suddenly you’re not optimizing one 25% chunk. You’re optimizing multiple parts of the cycle.

Compound those gains: 10% + 15% + 20% + … = Maybe 25-30% overall?

The teams seeing bigger gains

I’ve talked to a few teams (startups mostly) claiming 30-40% productivity improvements. Common patterns:

What they did differently:

Greenfield projects - No legacy code, AI can architect from scratch
Clear problem domains - Well-defined requirements, less ambiguity
Strong senior presence - Seniors guide AI, juniors learn
Tight feedback loops - Ship fast, iterate, AI helps with both
Modern infrastructure - CI/CD, testing, observability already in place

What they avoided:

Legacy codebases with complex architecture
Unclear requirements and evolving scope
Junior-heavy teams without strong review
Slow deployment and testing cycles
Regulated industries with compliance overhead

So the 30-40% gains are real, but context-dependent.

The talent development shift

Here’s where I’m experimenting: What if we train differently for AI era?

Traditional bootcamp/onboarding:

Weeks 1-4: Syntax, language fundamentals
Weeks 5-8: Frameworks, libraries
Weeks 9-12: Build projects, apply concepts
Result: Can implement features with guidance

AI-era onboarding I’m testing:

Weeks 1-4: Architecture, system design, tradeoffs
Weeks 5-8: Code review, quality judgment, testing
Weeks 9-12: AI orchestration, debugging, integration
Result: Can architect and review features, use AI for implementation

Early results: Unclear. Too soon to tell. But I’m hopeful.

Why EdTech lens makes me optimistic

From my company’s domain: AI-driven onboarding showed 30-40% reduction in time-to-productivity.

That’s not code generation—that’s learning acceleration.

What if the same applies to:

New team members getting up to speed
Engineers learning new domains or codebases
Cross-training team members
Scaling knowledge across growing org

Those are organizational productivity gains beyond code generation.

The measurement question

David and Michelle both said we’re measuring wrong. I agree, but let me add:

What if we measured:

Time to validated learning: How fast can we test hypotheses?
Deployment frequency: How often do we ship?
Change fail rate: How often do deployments break?
MTTR (mean time to recovery): How fast do we fix issues?

These are DORA metrics (DevOps Research and Assessment). Teams with strong DORA scores deliver better business outcomes.

If AI improves these metrics, that’s the productivity that matters.

Early data from our team:

Deployment frequency: Up 18% (faster to implement → faster to ship)
Change fail rate: Up 12% (more code, slightly more bugs)
MTTR: Down 15% (AI helps diagnose issues)

Mixed results but trending positive.

My bet on the future

I think 10% is what you get by default. 25-30% is achievable with organizational adaptation.

To get there:

Redesign processes for AI-speed development
Train teams for AI-augmented work
Measure business outcomes, not code output
Build culture of quality and learning
Invest in delivery infrastructure

Not every org will do this. Many will stay at 10%.

But the ones that adapt? Competitive advantage.

Where I agree with everyone

Maya: Code generation was never the main constraint → Yes

David: Strategic clarity and customer understanding matter more → Yes

Michelle: Delivery systems and review processes are bottlenecks → Yes

Luis: Team productivity and quality matter more than individual output → Yes

And yet I still think we can do better than 10%.

Not through better AI. Through better organizational adaptation to AI.

The inclusion opportunity

One last point: AI could genuinely democratize software creation.

If natural language becomes the interface:

Non-CS backgrounds can contribute
Diverse perspectives can build for diverse needs
Career switchers can enter tech
Global talent can participate

That’s productivity at ecosystem level, not just org level.

More people building software → More innovation → Better outcomes.

10% productivity per team might unlock 100x more builders overall.

That’s the future I’m working toward.