Everyone Said AI Would Replace Coders. The Best Founders Just Started Coding Again.

This isn't a nostalgia story. It's a strategy one.

May 18, 2026

New here? I write about what's actually happening in the tech industry — the untold angles and lifestyle, honestly. Subscribe below.

Mark Zuckerberg is spending real time inside Meta’s AI codebase.

Sergey Brin came back to Google. Not as a figurehead — as an engineer, embedded in a focused technical group working directly on AI systems.

Sridhar Vembu stepped away from the CEO role at Zoho entirely to go back to engineering.

The first read on this is obvious: successful founders getting nostalgic, missing the days when it was just them and a terminal. Wanting to feel useful again.

That reading is too simple. And it misses the actual story.

What’s really happening

AI didn’t make code easier to understand. It made code faster to produce.

Those are two very different things.

When a senior engineer used to write a thousand lines of code, a technical leader could review it, ask questions, spot the assumptions baked into the architecture. The pace of production created natural checkpoints.

Now AI produces that thousand lines in an afternoon. It looks clean. It’s well-commented. It passes the linter. And it may still contain brittle logic, hidden security gaps, or architectural decisions that will cost you six months to unwind later.

The bottleneck shifted. It moved away from production and toward judgment.

Who decides what to build? Who can tell the difference between impressive-looking output and a system that will actually hold up? Who spots the hallucinated function that almost works but fails in production under load?

That person needs to be close to the code. Not writing every line — but close enough to ask the right questions and recognise a wrong answer.

That’s why the founders are going back.

The factory floor principle

There’s an old idea in manufacturing: the best plant managers spend time on the factory floor. Not because they’re going to operate the machines themselves, but because physical proximity to the work surfaces problems that spreadsheets hide.

You see the bottleneck that isn’t in the report. You hear the machine that sounds wrong before it breaks. You notice that the process everyone documented isn’t the process anyone actually uses.

The same principle applies to software in the AI era.

When code can be generated at speed, the surface area of potential problems expands faster than any review process can catch — unless someone in leadership understands the terrain well enough to know where to look.

Zuckerberg isn’t at Meta’s AI team because he wants to feel like a developer again. He’s there because the decisions being made in that codebase are the most consequential decisions Meta will make in the next decade. And you cannot make good decisions about things you don’t understand.

What this means if you’re not a billion-dollar founder

The trend isn’t just about famous names going back to terminals.

It’s about what AI has done to the entire stack of technical leadership.

A few years ago, a non-technical founder could hire great engineers, trust their judgment, and stay one layer removed from the details. That worked when the pace of production was human-paced. When a feature took three weeks, there was time to understand it through conversation.

Now a solo developer with Claude Code or Cursor can ship in a week what used to take a team a month. The pace of execution has outrun the pace of understanding — for anyone who isn’t staying close to the work.

If you’re a founder, a product lead, or a senior manager in a company building with AI: the gap between what your engineers are shipping and what you actually understand about what they’re shipping is probably wider than you think.

That gap is where strategy breaks down.

The risk nobody’s naming clearly

AI-generated code has a specific failure mode that’s different from human-written code.

Human engineers make mistakes that are usually traceable — a wrong assumption, a missed edge case, a library misused. You can follow the logic even when it’s wrong.

AI-generated code can fail in ways that look correct. The structure is clean. The naming is sensible. The tests pass. And underneath there’s an assumption baked into a model response six prompts ago that nobody checked because the output looked fine.

Google CEO Sundar Pichai said in April 2026 that 75% of all new code at Google is now AI-generated. Stripe’s internal AI agents are merging over 1,300 pull requests per week. 95% of Mercari’s employees are actively using AI tools internally. The volume of AI-produced code in production systems is growing faster than most organisations’ ability to evaluate it.

The leaders who will navigate this well are the ones who understand what they’re reviewing. Not because they’ll catch everything — but because they’ll know which questions to ask and which answers to trust.

When founder-coding doesn’t help

This isn’t a universal prescription.

In large regulated companies — financial services, healthcare, government — deep technical involvement from the CEO can slow execution if it pulls attention away from compliance, hiring, or stakeholder management. The factory floor principle only works if the leader’s time on the floor is spent understanding, not micromanaging.

The point isn’t that every executive should start committing code. The point is that technical fluency — the ability to read, question, and evaluate what AI is producing — is becoming a leadership skill in the same way financial literacy became a leadership skill a generation ago.

You don’t need to be a CFO to understand a P&L. You need to understand it well enough to know when something’s wrong.

Same thing now with code.

What I see from my desk

I’ve been a senior Laravel engineer for eight years. I build AI products in production. I use Claude Code as a daily driver.

Here’s what I notice: the gap between what AI can produce and what most leaders can evaluate is growing fast. And the engineers closest to that gap — the ones who understand both how to direct AI and how to verify its output — are becoming the most valuable people in any technical organisation right now.

This isn’t about job security for developers. The role is changing regardless.

It’s about what kind of judgment becomes irreplaceable when production is no longer the constraint.

The founders going back to terminals already know the answer.

The closing thought

AI may write more of the code. But it hasn’t removed the need for people who can recognise good code, question weak code, and steer the system behind it.

The founders aren’t returning to the terminal because AI failed.

They’re returning because AI succeeded — and that success made technical judgment more valuable than ever.

The question for everyone else is whether they’ll close the gap before it closes them.

What’s your honest read on this — are you staying close to the technical work or finding yourself more removed as AI speeds things up? Drop it in the comments.

— Alex, MBM

If this gave you something useful — subscribe below, leave a comment, Every Monday, honest takes from someone actually building in this.

Discussion about this post

Ready for more?