AI Writes Code Fast, But Someone Still Has to Review It

General
1

Can we talk about the elephant in the room? Everyone’s celebrating how fast AI generates code. But nobody’s talking about the review bottleneck that’s crushing our senior engineers.

The 91% Problem

Recent data shows that teams with high AI adoption are experiencing a 91% increase in PR review time. Let me tell you why that number haunts me.

On my design systems team, we started using AI tools heavily about 8 months ago. At first, it felt amazing. Components that used to take a full day to design and prototype? Done in 2-3 hours with AI assistance.

But here’s what actually happened to our workflow:

  • Before AI: Designer creates component → peer review (30 min) → engineering handoff
  • After AI: Designer creates 3x components → peer review each (45 min each) → extensive rework → second review → engineering handoff

Net result: More components generated, but our review capacity became the constraint. And the quality bar actually dropped because reviewers were overwhelmed.

The Trust Gap

Only 33% of developers trust AI-generated code. Which means everything gets scrutinized carefully. And honestly? That’s the right call.

I’ve caught AI making subtle mistakes that would’ve been disasters:

  • Accessibility violations that looked fine visually
  • Components that worked in isolation but broke the design system patterns
  • Code that technically functioned but violated our naming conventions
  • Implementations that ignored responsive design requirements

But catching these issues takes time. Sometimes more time than writing it myself would’ve taken.

The Awkward Truth

Here’s something I don’t admit often: Sometimes it’s easier to write code myself than to review AI-generated code.

When I write something from scratch, I understand every decision. I know which edge cases I considered. I know why I chose this approach over alternatives.

When I review AI code, I’m reverse-engineering someone else’s (something else’s?) thought process. What did it assume? What did it miss? Is this approach sound or just the first thing that worked?

It’s cognitively exhausting in a different way.

The Speed-Quality Tradeoff

We’ve gotten really good at generating code quickly. We’ve gotten terrible at verifying it efficiently.

And I don’t think this is a solvable problem with just “better AI.” Even if AI got 10x better tomorrow, we’d still need human verification for:

  • Alignment with business requirements
  • Consistency with existing patterns
  • Strategic architectural decisions
  • Edge cases the AI training data didn’t cover

The verification burden is inherent, not incidental.

So What Do We Do?

I don’t have great answers yet. Some things we’re experimenting with:

  1. Tiered review processes - Light review for low-risk AI code, heavy review for critical paths
  2. AI-assisted review tools - Use AI to catch common AI mistakes (meta, I know)
  3. Better prompting - Investing in training so AI outputs are higher quality from the start
  4. Automated testing gates - Catch more issues before human review

But fundamentally, we’ve optimized one part of the workflow (generation) while creating a new bottleneck (verification).

How are others handling the review bottleneck? Have you found processes that actually scale?

2

Maya, this resonates deeply. I’''m seeing the exact same pattern across our entire engineering organization.

The Senior Engineer Burnout Problem

Our senior engineers—the ones with 8+ years of experience who do most of our code reviews—are now spending 60-70% of their time reviewing instead of building. They’''re exhausted.

And here’‘‘s the perverse outcome: they feel less productive even though objectively they’’'re processing more work than ever. Their job satisfaction scores have dropped noticeably.

Experimenting with Tiered Review

We’''ve started experimenting with what we call “AI-light” vs “AI-heavy” PR categorization:

AI-light PRs (mostly human-written code):

  • Standard review process
  • One senior reviewer approval
  • Normal merge timeline

AI-heavy PRs (>50% AI-generated):

  • Mandatory automated security scan
  • Two reviewer approval (one must be senior)
  • Additional testing requirements
  • Longer review SLA

It’‘‘s helping a bit, but honestly, we’’'re still figuring it out.

The Automated Testing Insight

Your point about automated testing gates is crucial. We’‘‘ve found that beefing up our pre-review automation catches maybe 30-40% of issues that would’’'ve required human review cycles.

We’''ve added:

  • Automated security scanning (Snyk, SonarQube)
  • Linting rules specifically for common AI patterns
  • Expanded integration test coverage
  • Accessibility testing automation

But that only works if the tests are comprehensive. And maintaining that test suite is its own time sink.

The Uncomfortable Question

Here’‘‘s what I’’'m wrestling with: If the review bottleneck negates the coding speedup, is AI providing net value?

Like, if we generate code 2x faster but review takes 2x longer… are we actually ahead?

I don’‘‘t have the answer yet. But I’’'m tracking end-to-end metrics carefully because I need to know if this is genuinely improving our delivery capability or just shifting where we spend time.

What’''s Actually Working

The one thing that’''s shown real promise: investing in prompt engineering training for our engineers.

Better prompts → higher quality initial AI output → less rework in review → faster overall cycle.

We’‘‘ve run several internal workshops on effective AI prompting, and engineers who’’'ve been through the training produce AI code that requires 40-50% less review iteration.

It’‘‘s not a silver bullet, but it’’'s measurably helping.

3

This thread is illuminating something I’‘‘ve been feeling but couldn’’'t quite articulate from the product side.

The Product Tension

From my perspective, here’‘‘s what I’’'m seeing:

Engineering says: “We’''re done with the coding part!”
Me: “Great, when does it ship?”
Engineering: “Well, it’''s in review…”
Two weeks later
Me: “Status update?”
Engineering: “Still addressing review feedback…”

This is creating a strange dynamic where engineering feels productive (they built it fast!) but from product’''s view, nothing has accelerated.

The End-to-End Metric Problem

I’‘‘ve started tracking what I call “concept-to-production” time for features. And it’’'s basically unchanged despite all the AI tooling.

The bottleneck shifted, but the total cycle time didn’‘‘t improve. Which means from a business perspective, we’’'re paying for AI tools but not seeing faster time-to-market.

A Question About Tradeoffs

Maya, you said sometimes it’‘‘s easier to write it yourself than review AI code. That’’'s fascinating and concerning.

If the senior engineers who are supposed to be doing high-value architecture and complex problem-solving are instead spending 60-70% of their time reviewing AI-generated code from juniors… are we actually optimizing for the right outcome?

Maybe the answer is that AI is great for juniors to learn and contribute more, but we need to factor in the senior time cost.

Measuring What Matters

I’''m pushing our eng leadership to track:

  • End-to-end cycle time (not just coding time)
  • Review bottleneck as a percentage of total dev time
  • Senior engineer time allocation (building vs reviewing)

Because from a product ROI perspective, I don’‘‘t care if coding is 2x faster if we’’'re still shipping at the same pace.

4

This discussion is hitting on the critical bottleneck that most organizations haven’''t systematically addressed: we need to redesign review processes for the AI era.

Review Process as a System Engineering Problem

Let’''s step back and think about this systematically. The traditional code review process was designed assuming:

  1. Code generation is expensive (lots of human thought)
  2. Review is cheaper than generation
  3. One reviewer can keep pace with 3-5 developers

AI breaks all three assumptions.

Now we have:

  1. Code generation is cheap (AI assistance)
  2. Review is expensive (human verification required)
  3. One senior reviewer is overwhelmed by 8-10 AI-assisted developers

Of course it doesn’‘‘t work. We’’'re using a process designed for different constraints.

The Security Dimension

Here’‘‘s what keeps me up at night: AI-assisted code shows a 23.7% increase in security vulnerabilities. In a regulated financial services environment, that’’'s not acceptable.

But I don’''t think the answer is “stop using AI.” The answer is systematic defense in depth:

  1. Automated security scanning as a gate before human review
  2. AI-assisted security review - use AI to check AI (with human oversight)
  3. Expanded test coverage requirements for AI-heavy code
  4. Security-focused prompt templates that include security considerations
  5. Post-merge security audits with higher sampling rates

We’''re treating this as an engineering systems problem, not just a tools problem.

The Cultural Shift Required

Luis mentioned prompt engineering training. This is crucial. But there’''s a deeper cultural shift needed:

AI is not magic. It’''s a powerful tool that requires expertise to use well.

Just like we don’‘‘t let junior engineers deploy to production without training, we shouldn’’'t let anyone use AI code generation without understanding:

  • How to write effective prompts
  • How to verify AI output
  • When AI is appropriate vs when to write manually
  • How to integrate AI code with existing systems

We’''ve started treating “AI-assisted development” as a skill to develop, not a tool to adopt.

The Organizational Design Question

Maya and Luis both highlighted that senior engineers are drowning in review. This is an organizational design failure.

Maybe the answer isn’''t “review faster” but “restructure teams” - perhaps we need dedicated review specialists or different team ratios in an AI-augmented world.

Or maybe we need to invest heavily in automated verification so humans only review what automation can’''t catch.

What We’''re Doing

We’''re taking a multi-pronged approach:

  1. Automation first - Catch everything we can before human review
  2. Tiered review processes - Risk-based review depth
  3. AI-assisted review tools - Use AI to help review AI
  4. Training investment - Better prompts = less review burden
  5. Metrics tracking - Measure review bottleneck explicitly
  6. Process iteration - Monthly retros on what’''s working

We’‘‘re 6 months into this and seeing some improvement, but it’’'s still a work in progress.

The key insight: this requires systematic organizational change, not just tool adoption.

5

I want to add a dimension that’''s been missing from this discussion: the human cost of review fatigue.

Burnout is Real

Maya mentioned senior engineers spending 60-70% of their time reviewing. Let me tell you what that looks like from a people management perspective:

  • Increased sick days among senior engineers
  • Lower engagement scores in our quarterly surveys
  • Three senior engineers have mentioned feeling “stuck in review hell” in 1-on-1s
  • One senior engineer actually left citing review burden as a factor

This isn’''t sustainable.

The Psychological Safety Dimension

Here’''s something subtle but important: we need to maintain psychological safety around rejecting AI suggestions.

I’‘‘ve seen junior engineers feel pressured to use AI because “everyone else is.” And I’’‘ve seen them submit AI code they don’‘‘t fully understand because they’’'re afraid to look slow or incompetent.

That’''s dangerous.

We’''re explicitly telling our teams: It’‘‘s okay to write code manually. It’’‘s okay to reject AI suggestions. It’‘‘s okay to say "I don’’'t understand this AI output."

Training as Investment, Not Cost

Luis’‘’ point about prompt engineering training is spot-on. We’''ve made this a formal part of our onboarding and continuing education.

New engineers get:

  • 4-hour workshop on effective AI prompting
  • Guidelines on when to use AI vs write manually
  • Training on how to verify AI output
  • Mentoring on reviewing AI-generated code

This is paying dividends. Engineers who’''ve been through the training:

  • Produce higher quality AI-assisted code
  • Submit fewer PRs that require major rework
  • Are better at self-reviewing before submission

The Junior Engineer Development Question

Here’‘‘s what worries me: if junior engineers are using AI to generate code they don’’'t fully understand, are they actually learning?

When I was coming up, I learned by writing boilerplate. By making mistakes and getting feedback. By struggling with problems.

If AI does all that for you… how do you develop the intuition and experience that makes you a senior engineer someday?

I don’‘‘t have the answer, but it’’‘s something I’''m actively thinking about in how we structure learning and development.