I Fired My Junior Dev for Cursor AI — Now I'm Questioning Everything About How We Build Software

Last Tuesday, I watched Cursor spit out 200 lines of working React code in 47 seconds. The same feature would've taken Marcus, my junior dev, about four hours — plus the inevitable PR back-and-forth where I'd explain why we use useCallback here but not there.

I felt physically ill. Not because the AI was good. I already knew that. But because I realized I hadn't spoken to Marcus in three days. He'd been quietly fixing linting errors and updating docs while I was pair-programming with a language model. Three days. I just... forgot about him.

This isn't another "AI is coming for your job" hot take. It's messier than that. I think we're watching the junior developer pipeline collapse in real-time, and nobody's talking about what replaces it. Or if anything does.

The Numbers Don't Lie (And Honestly, They Scare Me)

Let me share some actual data from my team. I run ReviewFlow solo now, but six months ago I had two part-time contractors: Marcus (junior, $3k/month) and Sarah (senior, $6k/month). Marcus found me through a Twitter thread where I was complaining about not finding good junior candidates. He was the only one who actually read my API docs before applying. That should've told me something.

Here's what happened to our development velocity:

Pre-AI (October 2024):

• Features shipped per week: 3-4
• Average PR review time: 4.2 hours
• Bugs caught in review: 67%
• Marcus's learning velocity: Steady improvement on React patterns, finally stopped using any everywhere (mostly)

Post-AI (March 2025 — Cursor 0.42 + Copilot):

• Features shipped per week: 7-9 (with just me + Sarah)
• Average PR review time: 1.8 hours
• Bugs caught in review: 43% ← This number keeps me up at night
• Marcus's status: Let go in January

The velocity doubled. The bug catch rate dropped by 24 percentage points. I traded a junior developer's growth for shipping speed, and I'm not sure I made the right call.

Actually, wait — I should clarify that Sarah's still catching things. She's incredible. But she's also started trusting the AI output more than she should. Last week she approved a PR where the AI had imported from @/lib/api-client but we'd renamed that to @/lib/api three months ago. The import looked right. The path was wrong. Took us 45 minutes of debugging a white screen to figure it out. She felt terrible. I felt worse because I'd reviewed her review and missed it too.

What Pieter Levels Got Right (And Where the Narrative Breaks Down)

Pieter famously said "you don't need a team, you need APIs." He built Nomad List and Remote OK as a solo developer, and I deeply respect that ethos. It's why I started bootstrapping in the first place. I've probably watched his "I shipped 12 startups in 12 months" talk four times. Maybe five.

But here's what the "solo dev with AI" narrative misses: Pieter built his products before AI coding assistants existed. He already had 10+ years of architectural knowledge when he went solo. He knew what good code looked like because he'd written bad code and suffered the consequences. He'd been the guy who pushed to production at 4:30 PM on a Friday and ruined his weekend. Multiple times, probably.

Marcus doesn't have that. And if nobody hires Marcus, he never will.

I ran an experiment last month that crystallized this for me. I gave the same feature spec to three "developers":

1. Cursor (Claude 3.5 Sonnet): Generated working code in 3 minutes. Missed edge case on empty states. No error handling. Code worked but was... soulless? Generic variable names like data and items, no comments, copied patterns from my codebase without understanding why we used them. It saw that I use useMemo a lot and just... sprinkled it everywhere. Even on things that didn't need it. Performance-wise, it actually made some components slower because memoizing cheap computations adds overhead. The AI doesn't know that. It just sees patterns.

1. Sarah (Senior, 8 years exp): Took 2 hours. Caught 4 architectural issues in the spec itself. Added monitoring hooks I hadn't considered. Wrote tests that actually tested behavior, not implementation. She also sent me a Slack message that just said "this spec assumes the webhook always returns 200 and you know that's not true lol." She was right. Of course she was right.

1. Hypothetical Marcus (Junior, 1 year exp): Would've taken 4-6 hours. Would've learned about state management patterns. Would've asked "why do we structure it this way?" And that question — that annoying, time-consuming, "can we just ship this please" question — is how seniors are made.

I miss those questions. Genuinely.

The Code Review Paradox Nobody's Talking About

This brings me to the second half of what I want to explore: Is AI reshaping code review culture, or just exposing that it was broken all along?

I built ReviewFlow because I believed code review was the highest-leverage activity in software development. Catch a bug in review, save hours of debugging. Teach a pattern in review, level up a developer for years. I still believe that. I think.

But AI-generated code is creating this bizarre new dynamic that I don't have a name for yet:

The AI PR looks perfect. Clean syntax, follows conventions, passes CI. It's like a student who memorized the style guide but doesn't understand the assignment. Reviewers get lulled into approving because there's nothing obviously wrong. Your brain just goes "yep, that's code" and you hit approve. It's muscle memory at this point.

I caught myself doing this three times last month. Approved a PR that looked great. Deployed to production. Discovered the AI had hallucinated an API endpoint that doesn't exist. The code was syntactically beautiful and functionally broken. The function was called fetchUserPreferences and it was hitting /api/v2/users/prefs which... we don't have. We have /api/v2/preferences. The AI just guessed. Confidently. With perfect indentation.

My bug catch rate dropped from 67% to 43% not because the code is better — it's because AI-generated code is harder to review. It bypasses our pattern-matching bullshit detectors. It's too clean. It's like the uncanny valley but for code.

What I'm Trying Now (Emphasis on Trying)

I'm not going back to pre-AI development. The productivity gains are real, and as a bootstrapped founder, shipping speed directly correlates to survival. My $10k MRR doesn't leave room for philosophical purity. But I'm experimenting with some things:

1. The "Why" Comment Rule

Every AI-generated function needs a comment explaining why it exists, not what it does. If I can't explain the why, I don't merge it. This forces me to actually understand the code I'm about to ship. Sometimes I'll write the comment, realize I don't understand the function at all, and have to go read the implementation line by line. That's... probably good? It feels like studying for a test I didn't know I was taking. Uncomfortable but necessary.

2. Pair Reviewing with Juniors (Even If I Don't Hire Them)

I started a small Discord community where junior developers review my AI-generated PRs. It's like 15 people now. They get real-world code exposure. I get fresh eyes that aren't pattern-blind to AI output. It's not employment, but it's something. Three of them have found bugs Sarah and I both missed. One guy, Alex, found a race condition that would've taken down our payment processing. He's 22. He's never had a dev job. He just... saw it. I Venmo'd him $200 on the spot. Best money I've spent this year.

3. Deliberate Practice Days

One day a week, I close Cursor and write code from scratch. It's slower. It's frustrating. I spent 20 minutes last Wednesday trying to remember the exact syntax for useReducer because I've been letting the AI handle it for months. Embarrassing. But it keeps my architectural thinking sharp. I'm terrified of becoming a "prompt engineer" who can't actually engineer. You know the type — they're already showing up in my Twitter replies, confidently explaining things that are just... wrong.

4. Measuring What AI Breaks

I now track "AI-introduced bugs" as a separate metric. Last month: 14 bugs traced back to AI-generated code that passed review. Average time-to-detect: 3.2 days. These are the bugs that would've been caught if Marcus was still asking "but what happens when the API is down?" or "what if the user has no items in their cart?"

Well... that's complicated. Because some of those bugs were mine too. I approved them. The AI wrote the code, but I shipped it.

The Uncomfortable Truth I Keep Avoiding

AI isn't killing junior developers. I am. We are. The indie hacker community that preaches "build in public" and "ship fast" is accidentally creating a world where there's no on-ramp for the next generation.

I don't have a solution. I can't afford to hire Marcus back — my $10k MRR supports exactly one person (me) with enough margin to not panic every month. Sarah's still contracting but I can see her hours decreasing as I get better at prompting. She hasn't said anything. I haven't either. We both know what's happening.

Dan Shipper from Every wrote about this recently — the idea that AI tools make experts more expert and leave beginners behind. I'm living that reality. My output as a solo dev has never been higher. My contribution to the developer ecosystem has never been lower.

I shipped 9 features last month. I taught zero people anything.

What I'd Do Differently (If I Could Go Back)

If I could rewind to October 2024:

1. Keep Marcus, change his role. Instead of writing features, he'd be my "AI output validator." His job: break everything the AI generates, write the tests the AI forgets, document the patterns the AI copies blindly. He'd learn faster by critiquing than by creating. I think. I don't actually know if that's true — I've never tried it. But it feels right. It feels less... extractive.

1. Charge more, sooner. I kept ReviewFlow at $29/month for too long because I was scared of churn. At $49/month, I could've afforded both Sarah and Marcus. Bootstrapper scarcity mindset cost me a team. I see this everywhere on Indie Hackers — people underpricing because they're afraid nobody will pay, then wondering why they can't afford help. It's a self-fulfilling prophecy.

1. Build review tools for AI code specifically. The market needs tools that can detect "looks right but is wrong" patterns. I'm pivoting ReviewFlow to focus on this. The problem I'm living is the problem I should be solving. Already shipped a prototype that flags hallucinated API endpoints. It's caught 3 in the last week. Two of them were mine. Plot twist: I'm my own first customer.

I don't know where Marcus is now. Last I heard, he's doing QA work for a fintech company. It's not what he wanted. He wanted to build things. He used to send me side project ideas at 2 AM — half-baked but genuinely interesting. A social network for plant owners. A tool that turns git histories into comic books. Weird, creative stuff. I haven't gotten one of those messages since January.

If you're an indie hacker using AI tools (and you should be, the productivity gains are undeniable), ask yourself: Who's going to review your AI's code in 2030? Who's going to have the architectural wisdom to know when the AI is confidently wrong?

Because right now, we're not training them. We're replacing them.

And I'm part of it.

TL;DR / Key Takeaways:

• AI doubled my shipping speed but dropped my bug catch rate from 67% to 43%
• AI-generated code is harder to review because it looks too clean — it bypasses our bullshit detectors
• The junior developer pipeline is collapsing, and indie hackers are accidentally causing it
• I'm experimenting with "junior as validator" roles, deliberate practice days, and community code review
• If I could go back, I'd keep my junior dev and change his role instead of firing him

Product: ReviewFlow — AI-powered code review that catches what other tools miss. Currently pivoting to detect AI-generated code patterns. Early access for indie hackers: code INDIE2025 for 50% off first 3 months.

Revenue: $10,432 MRR | Customers: 187 | Churn: 2.1%

How are you handling AI code review on your team? Have you found ways to bring juniors into the AI workflow? I'm genuinely looking for answers here — drop your approach in the comments. I'll share what's working and what's not in a follow-up post. Especially interested if you've tried the "junior as validator" model — does it actually work or am I just being nostalgic?

buildinpublic #ai #codereview #bootstrapping #juniordevelopers #cursor