Mark Zuckerberg said he's replacing mid-level engineers with AI. That sent shockwaves through the industry. Every CTO is now under pressure to "adopt AI" yesterday. But here's the thing about blanket statements like that — they ignore the details that actually matter.

A Stanford research group just released a massive study. Over 100,000 developers. More than 600 companies. Billions of lines of code from private repositories. And the results are way more nuanced than the headlines suggest.

I've been managing a portfolio of 800+ mobile apps and building with AI daily. The Stanford data lines up with what I'm seeing in the trenches. AI absolutely boosts productivity — but only if you get the inputs right. Your language. Your architecture. Your prompting strategy. Get those wrong and you're just generating bugs faster.

On average, AI boosts developer productivity by 15-20%. That's the headline number. But averages lie.

The real story is in the breakdown. On greenfield projects with low complexity tasks, AI delivers 30-40% gains. That's massive. But on brownfield projects with high complexity? You're looking at 0-10%. Sometimes AI actually decreases productivity on complex legacy code.

Here's what matters most: the programming language. High-popularity languages like Python, JavaScript, and Ruby see around 20% gains on low-complexity tasks. Low-popularity languages? AI can make things worse. The models are trained on what's out there, and if your language doesn't have a massive corpus, the AI is guessing.

And there's a hidden cost the study calls the "rework tax." AI-generated code introduces new bugs. Developers then spend time fixing those bugs. That rework eats into the initial productivity gains. This is why raw commit counts and lines of code are terrible metrics. More output doesn't mean more value.

This is the part nobody wants to talk about.

AI doesn't replace engineering judgment. It amplifies it. If you're a senior engineer who understands architecture, patterns, and the codebase — AI makes you incredibly dangerous. You're not a 10x engineer anymore. You're closer to a 30x engineer.

But if you're a junior engineer who can't evaluate what the AI just generated? You're shipping bugs with confidence. The AI lies. It lies confidently. And if you don't have the experience to catch it, those lies go straight into production.

The role has fundamentally shifted. You're a manager now. A manager of AI agents. You need to know when to trust them, when to override them, and how to structure their work. That's a senior skill set.

So what happens to junior engineers? I don't have a clean answer. They need to use AI to learn faster, absolutely. But they also need mentors more than ever. Someone who can look at AI-generated code and say "that's wrong, here's why." Without that feedback loop, juniors are going to develop blind spots they don't even know they have.

Here's what I've found actually works. You don't just hand AI a big task and hope for the best. That's how you get mediocre output riddled with hallucinations.

You stack your prompts. High-level to low-level.

The first prompt talks to an agent about the overall spec. What are we building? What are the requirements? That agent helps you think through the architecture. The next prompt takes that output and breaks it down further. You're working with different agents at different levels of abstraction — specs, then detailed specs, then implementation plans.

By the time you get to the coding agent, the task is so specific there's no room for creativity. And that's exactly what you want. You're not asking AI to make architectural decisions. You're telling it to implement this exact feature with these exact constraints. Micromanage the crap out of it. Make sure it does one thing and one thing only.

This is the opposite of how most people use AI. They throw a vague prompt at ChatGPT and wonder why the output is garbage. The magic is in the stack. Each layer constrains the next until the final task is just implementation.

The Stanford study found that codebase size has an inverse relationship with AI effectiveness. Bigger codebases, smaller gains. Context window limitations, signal-to-noise problems, complex dependencies.

But they missed the bigger point. It's not just size. It's abstraction depth.

Take React Native. At the top you've got TypeScript, which compiles to JavaScript, which runs on the React Native runtime, which bridges to the native platform, which finally renders on Android or iOS. That's five layers of abstraction before you hit the device. Now add a microservices API backend spread across a dozen services. Your prompt context is completely blown out. The AI can't hold all of that in its head.

You're basically stuck needing several senior engineers to wrangle that stack. AI can't save you from architectural complexity.

Now compare that to the majestic monolith. Ruby on Rails. One codebase. One language close to the platform. We're also building with Swift and Kotlin for native mobile — languages that sit right on top of the platform with minimal abstraction.

The difference is night and day. With Ruby, Swift, Kotlin, and JavaScript, we're building tremendous things. Fast. The AI understands the codebase because there's less noise between the prompt and the platform.

This is why I keep saying abstraction layers are the enemy. AI didn't create that problem — it exposed it. Every layer of abstraction between your code and the platform is a layer the AI has to reason through. Fewer layers, better results.

The Stanford data confirms what practitioners already know: AI is a force multiplier, not a replacement. But the multiplier varies wildly.

If you're working in a popular language on a monolithic architecture with experienced engineers who know how to stack prompts and micromanage AI agents — you're going to ship at speeds that were unimaginable two years ago.

If you're working in a niche language on a microservices spaghetti mess and expecting junior developers to "just use AI" — you're going to generate bugs faster and call it productivity.

The era of tiny teams is here. Sam Altman's betting on the first one-person billion-dollar company. Harvard professor Jeffrey Bussgang calls it "botscaling" — scaling without growing headcount. The companies that will pull this off aren't the ones with the most AI tools. They're the ones with the right architecture, the right languages, and senior engineers who know how to orchestrate AI agents like a well-run team.

How much time are you losing to AI-generated code that doesn't actually work? If your stack is fighting against AI instead of working with it, email me at jonathan@rubygrowthlabs.com with the subject "AI productivity" and tell me what you're building on.