LinkedIn is buzzing about vibe coding’s impact on organizations.

“It’s changing everything!” say the enthusiasts.

“It’s destroying software quality!” counter the traditionalists.

Both camps are missing something fundamental: vibe coding has existed for five months.

Five. Months.

That’s not enough time to change a coffee order habit, let alone organizational foundations. Yet here we are, debating whether it’s revolutionizing or ruining enterprise development.

I’ve watched companies spend longer than five months just deciding which project management tool to use. The idea that a coding approach could fundamentally reshape organizational values in the same timeframe is… well… optimistic.

Real organizational change operates on geological timescales. Culture shifts happen when people retire, not when new tools emerge. The companies celebrating vibe coding victories today are probably the same ones who adopted React faster than everyone else because they were already comfortable with experimentation.

The companies dismissing it as dangerous chaos? They were already risk-averse.

Vibe coding didn’t change these organizations. It reveals them.

Maybe the question isn’t whether vibe coding will transform how we work. Maybe it’s whether we’re ready to see what our organizations actually value when a faster option appears.

Five months is just enough time to show what was already there.

The first time I held an iPod, I understood something that watching Steve Jobs demo never could have taught me.

Weight. Texture. The satisfying click of the scroll wheel.

You can’t experience lag in a prototype. You can’t feel the awkward pause between tapping a button and seeing a response. Screenshots are beautiful liars.

We’ve gotten so good at making static designs look finished that we’ve forgotten they’re just educated guesses.

A perfectly polished Figma prototype sends the wrong signal: “This is ready. Don’t change it.” The more professional it looks, the more people hesitate to suggest improvements. Nobody wants to be the person asking for “small tweaks” to something that looks complete.

But show someone a working prototype where they can type in a text field and watch their words appear instantly? Different story.

“Can this button be bigger?”

“What if the text was clearer?”

“This feels slow - can we make it faster?”

Suddenly everyone becomes a user experience expert. Not because they know more, but because they’re experiencing rather than imagining.

The best feedback comes from touching, not looking.

Paper sketches invite edits because they look unfinished. Working prototypes invite interaction because they feel real. Polished mockups invite approval because they seem done.

Choose your invitation wisely.

Here is a service I desperately need. A book recommendation based on where I stopped reading a book.

”Ohh you stopped reading Lean Startup after 4 chapters. Then you probably should checkout The Every Store instead cause it has less jargon and is more narrative driven”.

Smart recommendations it could make:

“You stopped at the theory-heavy part, try this more practical version”

“Most people who stop here prefer memoirs over how-to books”

“You made it 60% through, here’s something that builds on those concepts”

I remember this piece of code.

Messy doesn’t even begin to describe it. At least once a year, someone would try to kill it. And fail.

On paper? Simple. It picked which market and language a user lived in. Geographic data plus browser settings, with some fallbacks thrown in. Easy, right?

Wrong.

The code was so woven into our system that touching it meant rewriting everything. We kept thinking “IT JUST PICKS MARKET AND LANGUAGE!!!1?” But that abstraction blinded us to the real complexity.

I see the same pattern now with AI-assisted coding.

You dip your toes in. You think everything’s simple. “Just build me an app that does X.” But you’re the complexity. You understand the full flow. You abstract away all the messy details that make starting from scratch so hard.

This is where Gall’s law hits you: “Complex systems that work have invariably evolved from simpler systems that worked.”

Start smaller. Start easier.

Don’t go all-in on “Create an app where everyone can chat with everyone in the world and it should be encrypted.”

Start with two people. Make that work first.

One interesting paradox of productivity social media: the most effective personal systems are deliberately non-scalable. They’re optimized for one person’s mental model.

It’s about what you want to do and how you want to do it.

But we always look at mentors trying to copy their results. We see their hindsight view of how they work and assume that’s the blueprint.

For years companies tried to copy the Spotify Model. Squads, tribes, chapters, guilds. The whole thing.

Just to realize that Spotify wasn’t even using it anymore.

It was a utopian vision of how work could happen at a specific moment in Spotify’s life. Not a universal framework.

By the time a system becomes famous enough to copy, it’s already been abandoned by the people who created it.

So when we look at how others do things, we need to understand their input. Their constraints. Their actual daily reality.

Not just the polished model they present at conferences.

Copy the thinking, not the system.

A few months ago I bought a close to broken old record player and speakers for $25.

Since then I’ve bought used and reissues of old classics on vinyl. There is something special to the feeling of dropping the needle on the LP’s first track and listening through to the end, not skipping a song because I don’t like it, but keeping at it because it’s what the artist aimed at. Delivering a story.

I’d never heard David Bowie’s Heroes album before this, just the hits. But those wonky odd tracks in between? They’re what make the whole story work.

Wouldn’t it be interesting if artists themselves could say: you cannot listen to any specific tune until you’ve listened to this complete album.

Think of the kind of stories that would then be able to be told again.

Like going to the Louvre and only seeing the Mona Lisa before leaving. You miss all the context that makes it truly special.

I keep seeing memes about “AI Agents everywhere!” and people dismissing them as the next metaverse fad or NFT bubble. But I think they’re missing something important.

Look at the behavioral shift happening. Most people I know now go to ChatGPT instead of Google when they need answers, help figuring out strategic decisions or polish their slides.

We’re not just changing how we find information. We’re changing how we interact with services entirely. Instead of building our own AI agents, the smart move might be building for the AI agents people already use.

Then there’s the money. Big tech is pouring billions into AI infrastructure and development. This collective industry pivot is massive. The only comparable shift I can think of is when everything moved to “the cloud”.

The memes about AI agents being everywhere aren’t wrong. They’re just missing the point about what that actually means for how we’ll do business.

Most technical leaders didn’t become leaders to lead.

They became leaders because that’s where the influence was. The budget decisions. The architectural choices. The strategic direction.

But somewhere along the way, they stopped building things.

Meetings replaced coding sessions. Presentation replaced prototypes. They found themselves describing solutions instead of creating them.

AI development tools might change that equation entirely.

What if you could maintain strategic oversight while personally building the critical pieces? What if leading didn’t mean delegating everything?

The traditional model assumed you couldn’t do both. Leadership required full attention. Technical work required deep focus. Pick one.

But AI tools compress the time between idea and implementation. That strategy you’ve been explaining in slide decks? You could prototype it this afternoon.

The architectural vision you’ve been communicating through diagrams? You could build the foundational pieces yourself.

This isn’t about micromanaging or stepping on your team’s toes. It’s about leaders who understand systems deeply enough to know which problems to solve personally.

The CEO who builds the core algorithm. The CTO who prototypes the new platform architecture. The VP who writes the critical integration herself.

Not because the team can’t do it. Because they can do it better, faster, and with more context about where it fits in the bigger picture.

These leaders aren’t telling their teams what to build. They’re building alongside them. Sharing knowledge in real-time. Showing techniques and explaining trade-offs as they happen. It’s leadership through example rather than directive.

We might see a new type of leader emerging. The hands-on executive who combines strategic thinking with personal execution. Someone who doesn’t just direct the work but actively participates in creating it.

The best leaders were usually great individual contributors first.

Maybe AI tools will let them be both again.

Baby boomers occupied knowledge work positions longer than any generation before them. Unlike factory workers who retired from physical labor, knowledge workers just stayed. Programming doesn’t wear out your knees.

Now the last boomers are stepping down. Someone has to fill those positions.

That someone is probably in their late thirties. Two decades of experience. You’ve seen frameworks come and go. You remember when JavaScript was a toy language.

But you might not need to follow the traditional path.

The old model was predictable. Get experience. Move to management. Trade your keyboard for spreadsheets and slides.

AI development tools will change that equation.

Why manage a team of five junior developers when you can have the productivity of fifteen?

You know what good code looks like. You understand system architecture. You’ve debugged enough production fires to spot problems before they happen. Now you have tools that amplify that experience instead of bureaucratizing it.

Junior developers will learn AI-assisted coding as their baseline. But they lack the pattern recognition that comes from years of mistakes. They don’t know which shortcuts lead to technical debt disasters.

You do.

Combined with AI tools, that experience becomes a superpower. This creates a new archetype: the experienced individual contributor who skips management entirely and becomes a one-person product factory.

Here’s the thing though: they might not be in a hurry to leave either. Why retire when you can outproduce entire teams? Why step aside when you’re finally having fun building again?

Sound familiar?

Meet the new boomers.

LinkedIn is full of developers dunking on “vibe coding.”

“It doesn’t scale,” they say. “You can’t build enterprise systems this way.” “What happens when your team grows?”

They’re probably right.

And maybe that’s completely missing the point.

Scale is the wrong metric for personal productivity. It’s like judging a custom-tailored suit by whether it fits everyone in the company.

With AI development tools like Claude Code, personal optimization becomes effortless.

I no longer spend hours reading documentation just to remember how to set up a basic Express server. I don’t wade through boilerplate code to get started. I don’t compromise my vision because the existing tools almost-but-not-quite fit my needs.

I describe what I want. I get exactly what I want.

This isn’t about building Facebook. It’s about solving my problems, the way I think about them, with tools that bend to my mental model instead of forcing me to bend to theirs.

Team coordination? Code reviews? Maintainability? These remain important for large systems. But they’re separate problems from personal effectiveness.

The real challenge isn’t accommodating more developers. It’s amplifying the ones you have.

When I can generate a perfect Obsidian plugin in the time it takes to take a shower, the old rules about scalable development practices feel… quaint.

Maybe it’s about teams that scale through individual superpowers. The best engineering organizations won’t be the biggest. They’ll be small teams where everyone operates at peak personal effectiveness while still collaborating seamlessly.

That’s a different kind of scale entirely.