I Spend More Time Reviewing AI Code Than Writing My Own

[alex_dev]

I need to share something that’s been bothering me for months. When my company rolled out GitHub Copilot last summer, I was genuinely excited. I was one of the early adopters on the team, and the initial productivity boost felt amazing. I could implement features in hours that would have taken days before.

Fast forward to today: I estimate I spend about 60% of my time reviewing pull requests, 25% writing my own code, and 15% in meetings. I’ve essentially become a full-time code reviewer who occasionally writes code on the side.

This isn’t what I signed up for when I became a senior engineer.

How We Got Here

The pattern started subtly. Our junior developers adopted AI tools enthusiastically. Suddenly, they were writing complex features that would have been beyond their skill level six months ago. Database migrations with intricate rollback logic. Sophisticated caching strategies. Complex async workflows.

The code often looks impressive. Proper error handling, good variable names, following patterns correctly. But here’s the problem: they frequently don’t deeply understand what the AI generated.

I started noticing this in code reviews when I’d ask “why did you choose this approach?” and the answer was some variation of “Copilot suggested it and it seemed to work.” Not “I evaluated three approaches and chose this one because…” Just “the AI suggested it.”

The Review Burden

Reviewing AI-generated code is fundamentally different from reviewing human-written code. When a developer writes code from scratch, there’s usually a thought process you can follow. You can see the logic progression. The commit history tells a story.

AI-generated code appears in larger chunks. The progression isn’t always logical - it’s pattern-matched from training data. Sometimes the approach is clever in ways that are actually counterproductive for our codebase. Other times it’s unnecessarily complex because the AI optimized for generality rather than our specific use case.

This means each review takes longer. I can’t trust my heuristics. I have to:

• Carefully verify the logic is actually correct (not just looks correct)
• Check if this approach fits our architecture
• Consider if the author can maintain this code
• Evaluate if a simpler approach would be better
• Often explain why the AI’s approach, while functional, isn’t ideal for us

The Mentorship Crisis

Here’s what really concerns me: I used to spend significant time mentoring junior developers. Pair programming sessions, architecture discussions, explaining trade-offs. That’s how I learned as a junior - from seniors investing time in my growth.

Now there’s no time. The review queue is 30-40 PRs deep constantly. When I do review, it’s often async comments rather than synchronous mentorship. Junior developers are getting feedback like “this logic is incorrect” without the deeper context of “here’s how to think about this type of problem.”

I worry we’re creating a generation of developers who can prompt AI to generate code but can’t architect systems, make trade-off decisions, or deeply understand what they’re building.

The Personal Cost

I’m tired. Code review is cognitively draining, especially when you’re trying to deeply understand AI-generated logic. By the end of the day, I’m exhausted from reviewing rather than energized from building.

Worse, I feel like my skills are atrophying. I’m not designing systems anymore - I’m auditing AI output. I’m not solving interesting problems - I’m verifying AI solutions. My GitHub contribution graph is mostly review comments, not commits.

Several other senior engineers on my team have expressed similar frustration. One told me bluntly: “I’m being paid a senior engineer salary to be a code inspector. That’s not what I want to do with my career.”

Is This Sustainable?

I keep asking myself: is this sustainable? Can senior engineers continue to be the bottleneck that validates all AI-generated code? What happens when we burn out or leave for roles where we actually get to engineer rather than just review?

And from a company perspective: are we actually better off? We’re generating code faster, but review is slower, bug fixes take longer, and senior engineers are less satisfied. The total cycle time from feature idea to production hasn’t meaningfully improved.

Looking for Perspectives

For other senior engineers experiencing this:

• How are you managing the review load without burning out?
• Have you found ways to make reviewing AI code less draining?
• How do you balance review responsibilities with your own technical growth?
• What are you doing to ensure junior developers are actually learning, not just prompting?

I love the craft of software engineering. I love solving hard problems and building systems. I don’t love spending 60% of my day verifying AI output. Something needs to change, but I’m not sure what.

[eng_director_luis]

Alex, reading your post hit hard because I’m the person putting you and other senior engineers in this position. As a director, I’m supposed to solve these problems, but I’ve been struggling with how.

Acknowledging the Burden

You’re right that this isn’t sustainable. The data from my team shows similar patterns - senior engineers spending 55-65% of their time on code review, up from about 30-35% before AI tools. That’s a massive shift in how we’re using our most expensive and valuable engineering talent.

The mentorship point you raised is what keeps me up at night. Our senior engineers used to have structured time for:

• Weekly 1-on-1 technical mentoring sessions with juniors
• Architecture design discussions
• Lunch-and-learn presentations
• Pair programming on complex problems

All of that has been crowded out by the review queue. We’re still doing it, but it’s rushed, squeezed in, or cancelled when review pressure builds. That’s not sustainable for building the next generation of senior engineers.

The Career Development Crisis

I’ve had two senior engineers in the last quarter tell me they’re concerned about their career trajectory. They’re not learning new skills or working on challenging problems - they’re reviewing routine implementations generated by AI.

One put it bluntly: “My resume used to show systems I designed and built. Now it would show code I reviewed. That’s not a compelling career story.”

That’s a retention risk I take seriously. Senior engineers have options. If their work becomes less satisfying and their career development stalls, they’ll leave. Then we’re in an even worse position - junior and mid-level engineers using AI tools heavily with insufficient senior oversight.

Experiments We’re Trying

I don’t have solutions yet, but here are experiments we’re running:

1. Specialized Review Rotations: Instead of all seniors reviewing constantly, we’re creating focused review weeks where specific seniors are “on review duty” while others get uninterrupted time for design and implementation work. It’s not perfect, but it prevents everyone from being constantly fragmented.

2. “AI Code Reviewer” as a Defined Role: We’re piloting a role that’s specifically about reviewing AI-assisted code with a focus on mentoring developers on effective AI tool use. This is controversial - some see it as creating second-class senior engineers. But it might be necessary.

3. Review Capacity as a Planning Constraint: We’re starting to include “available review capacity” in sprint planning, explicitly limiting the amount of AI-generated code the team can take on based on available senior review time.

4. Mandatory Pairing for Complex AI Code: Junior developers using AI for complex features must pair with a senior during implementation, not just at review. This is slower than solo AI-assisted work, but faster than multiple review iterations and provides real-time mentorship.

The Trade-Offs Are Real

These experiments slow down our apparent velocity. PR count will likely drop. Some executives are pushing back. But I’m increasingly convinced that optimizing for PR count while burning out senior engineers and compromising quality is a losing strategy.

Your question “is this sustainable?” - the honest answer is no. Something has to change. Either we significantly limit AI tool usage, or we fundamentally restructure how senior engineering time is allocated, or we accept much higher turnover of senior engineers.

None of those options are great, but I think option two is the most viable. We need to treat “review capacity” as seriously as we treat “implementation capacity” and design our processes accordingly.

[maya_builds]

Alex, this resonates from a completely different angle. I’m seeing the same pattern in design, and I think the underlying issue is about craft development vs. tool-assisted output.

The Parallel in Design

Junior designers on my team are using AI tools like Midjourney, Adobe Firefly, and AI-powered Figma plugins. They can generate sophisticated-looking designs incredibly quickly. But when I review their work, I often have to ask deep questions about the choices that reveal they haven’t developed the underlying design thinking.

“Why did you choose this color palette?”
“The AI suggested it and it looked good.”

“How does this layout support the user’s goal?”
“I tried several AI variations and this one seemed most polished.”

It’s beautiful work generated quickly, but without the foundational thinking that makes design effective.

The Learning Problem

When I was a junior designer, I learned by struggling. Trying layouts that didn’t work. Color combinations that clashed. Typography that was hard to read. That struggle built intuition about what works and why.

AI tools short-circuit that learning. Junior designers get to “good enough” without understanding the principles that make it good. Then when they need to make a creative decision the AI can’t help with, they’re stuck.

Your mentorship concern really hits home. I used to do weekly critiques where we’d tear apart designs together - not just “what’s wrong” but “how do you think about this type of problem?” Now I’m doing rapid-fire reviews of AI-generated work, focusing on catching errors rather than building understanding.

A Potential Approach: Pairing Sessions

One thing that’s worked better than async review: live pairing sessions where I watch the junior designer work with AI tools in real-time.

Instead of reviewing the output, I’m reviewing the process:

• How they prompt the AI
• What alternatives they consider
• How they evaluate the AI’s suggestions
• When they override the AI vs. accept its output
• How they adapt AI output to our specific needs

This is slower than async review, but it’s actual teaching. The junior designer is learning judgment and critical thinking, not just acceptance of AI output.

The Context Building

Your point about code appearing in large chunks resonates. In design, AI generates complete compositions. There’s no progressive refinement where I can see the thinking evolve. It’s like reviewing a finished painting instead of watching someone sketch.

We’ve started requiring “design progression” documentation for AI-heavy work. Show me 3-4 iterations, explain what changed and why. This forces the designer to think critically about the AI’s output rather than just accepting the first good-enough result.

Building Context, Not Just Shipping

I think the broader lesson - for both design and engineering - is that we need to value the context-building process, not just the output. AI can generate output efficiently, but it can’t build the human understanding that makes future work better.

Maybe the answer isn’t to fight the review burden, but to transform review from quality-checking into active mentorship. Slower, yes. But potentially more sustainable if it actually develops capabilities in junior team members.

[vp_eng_keisha]

Alex, your post articulates something I’ve been seeing across my entire engineering organization, and it’s forcing me to rethink how we structure our teams in the AI era.

This is a Team Design Problem

Your experience isn’t a personal failing or a review process problem - it’s a fundamental mismatch between how we’ve structured engineering teams and how AI tools change the work distribution.

Traditional team composition assumes a pyramid:

• Juniors: lots of implementation, heavy mentorship
• Mid-level: balanced implementation and review, some mentoring
• Seniors: system design, code review, mentorship, some implementation
• Staff+: architecture, cross-team coordination, strategic technical decisions

AI tools have disrupted this pyramid. Junior engineers can now generate implementation at mid-level volume. But the review, mentorship, and judgment requirements haven’t decreased - they’ve increased.

The Math Doesn’t Work Anymore

Let me share some napkin math from our organization:

Before AI (25 engineers):

• 8 junior (primarily implementing)
• 10 mid-level (implementing + reviewing)
• 5 senior (reviewing + designing + mentoring)
• 2 staff+ (architecture + coordination)

Review load was distributed. Mid-levels did most initial review, seniors did architectural review and complex PRs.

After AI (80 engineers, same ratio):

• 26 junior (implementing at 2x previous rate with AI)
• 32 mid-level (implementing faster, but review queue overwhelmed)
• 16 senior (spending 60%+ time reviewing)
• 6 staff+ (pulled into review because queue is so backed up)

The review requirement grew faster than the review capacity. Our senior engineers are underwater.

Rethinking Team Composition

I’m experimenting with different team structures for our AI-assisted era:

Option 1: Review-Heavy Teams
Higher ratio of senior engineers to juniors. Expensive, but ensures adequate review capacity. Team of 8 might be: 3 junior, 2 mid, 3 senior.

Option 2: Paired Development
Junior engineers work in pairs with seniors during implementation, not just at review. AI generates code, but senior is present for real-time mentorship and course correction. Slower but higher quality.

Option 3: Capability Tracks
Create distinct career paths: “Implementation Specialists” who excel at AI-assisted feature development, and “Architecture Engineers” who focus on system design and review. Controversial, but acknowledges that AI has split engineering work.

Option 4: Review Infrastructure Investment
Treat review as a first-class infrastructure problem. Build better review tools, AI-assisted review capabilities, automated pre-review checks. Make the review process itself more efficient.

The Career Path Implications

Your concern about career development is something I’m taking seriously at the VP level. If senior engineer work becomes primarily review, we need to either:

1. Make review work more valuable and career-enhancing (not just “code inspector”)
2. Ensure seniors have dedicated time for system design and complex implementation
3. Create new roles and career paths that match the actual work distribution

I’m leaning toward option 2. We’re implementing “design weeks” where senior engineers are explicitly off review rotation to work on architecture, complex technical problems, and strategic initiatives. It’s recognition that review can’t be 60% of senior engineering time without burning people out.

Investment in Review Infrastructure

We’re also investing in making review itself less draining:

• Better diff tools for large AI-generated PRs
• Automated context gathering (what changed, why, how it relates to other systems)
• AI-assisted review for common issues (freeing humans for architectural review)
• Review pairing tools for synchronous review sessions

The goal: make review more efficient so it doesn’t consume all senior engineering time.

The Broader Question

Ultimately, I think we’re experiencing the early days of figuring out what engineering teams look like when implementation becomes cheap and review becomes expensive. The industry hasn’t solved this yet. We’re all experimenting.

What I know for certain: expecting senior engineers to absorb unlimited review burden while maintaining the same team structures is not sustainable. Something has to change - team composition, processes, tooling, or some combination.

[security_sam]

Alex, the security dimension of what you’re describing is critical, and I don’t think it’s getting enough attention in this discussion.

Security Review Burden Has Tripled

I track security review workload across the teams I consult with. Before widespread AI tool adoption, security-sensitive PRs (authentication, authorization, data handling, crypto) averaged about 8-10 per month per team.

Now? 25-30 per month. Not because teams are building more security features, but because AI tools are generating security-critical code more frequently as part of regular features.

AI Code Looks Sophisticated But Has Basic Flaws

The cognitive load you described - verifying AI logic rather than trusting your heuristics - is even more acute for security review.

Example from last week: reviewing a Nest.js authentication middleware generated by Copilot. The code had:

• Proper async/await patterns
• Correct JWT verification
• Good error handling
• Type safety

But it also had:

• Timing attack vulnerability in token comparison
• Missing rate limiting on auth attempts
• Information leakage in error messages
• Improper session handling on edge cases

These aren’t issues you catch with a quick review. They require deep security analysis, which takes time. When you’re already overwhelmed with 40 PRs in queue, it’s easy to miss.

Junior Developers and Security

Your point about juniors not understanding code they generate is especially concerning for security. A junior developer using AI might generate cryptographically correct code without understanding:

• Why this specific algorithm was chosen
• What threat model it defends against
• How it can fail under attack
• How to use it correctly in different contexts

When that developer needs to modify the code later or apply the pattern elsewhere, they don’t have the underlying security knowledge to do so safely.

The Training Gap

Most developers haven’t been trained on reviewing AI-generated security code. The vulnerability patterns are different from typical human security mistakes.

I’ve started developing a checklist specifically for AI-generated security code:

• Authentication/authorization: verify all edge cases manually
• Input validation: test with actual attack payloads, not just type checking
• Cryptography: verify algorithm choice against current standards
• Error handling: check for information leakage under all error conditions
• Race conditions: especially common in AI-generated async code
• Dependency security: AI often uses outdated package versions from training data

Proposal: Specialized Security Review

For teams using AI tools heavily, I recommend:

1. Security-focused review checklist required before general code review
2. Junior developers must complete security self-review before requesting review
3. Automated security scanning blocks PRs before human review time is spent
4. Senior security review required for any AI-generated auth/crypto/data-handling code

This adds process, but it prevents security vulnerabilities from consuming review time through multiple iterations or worse - making it to production.

The Sustainability Question

Your question about sustainability applies doubly to security review. Security engineers are already in short supply. If AI tools triple the security review burden, where do we find the capacity?

Short term: better automation and developer security training.
Long term: we may need to rethink which security patterns we allow in codebases and restrict junior developers from AI-generating security-critical code without senior pairing.