Skip to main content

Command Palette

Search for a command to run...

Vibe Engineering {VE} #1 โ€” Origin Story

How 25 years of building teams, fighting fires, and one absurd AI moment led me to Vibe Engineering.

Published
โ€ข10 min read
Vibe Engineering {VE} #1 โ€” Origin Story

๐Ÿ”ฅ It started with something that felt completely absurd.

I asked AI to solve a simple calculation.

It wrote code.

My first reaction was pure confusion. Why would it do that? It's a simple calculation โ€” not a software problem. This is overkill. This makes no sense.

But then something shifted inside me.

I thought โ€” okay. If it does this for something this simple, what happens when I push it?

So I pushed it.


๐Ÿงช The experiment that changed everything

I started giving it complex problems. Data analysis tasks I would normally solve using macros and formulas in Google Sheets. Then I went further โ€” things I had previously built using Python, pandas, and Spark.

Tasks that used to take me weeks of thinking. Weeks of trial and error. Weeks of debugging, refining, marinating ideas until they finally worked the way I wanted them to.

It generated them in seconds.

Not perfectly. Not always correctly. But it did them โ€” seamlessly, connecting different pieces together in a way that stopped me completely cold.

That's when I said something out loud that I still believe today.

๐Ÿ’ก It wasn't just writing code. It was thinking in code.

And in that moment, I knew โ€” this is going to change the game of engineering forever.

Not just how we build things. How we think about building things.

But here's what nobody talks about when they tell these "AI moment" stories.

The tool wasn't the real breakthrough. The mindset shift was.

And that mindset shift only meant something to me because of two people who had already started shifting my thinking โ€” long before that absurd calculation moment arrived.


๐Ÿง  Two people who changed my direction

This didn't happen in isolation.

I had been following Patrick Debois closely on LinkedIn for years. Many call him the father of DevOps โ€” though he himself prefers not to be boxed into that title anymore. What fascinated me was never just what he said. It was how he kept evolving.

From DevOps. To DevSecOps. And then gradually, quietly, moving into something new โ€” talking about AI writing code, talking about what AI could mean for how we build, before most people even knew what to call it.

That was one spark.

The second came from Andrew Ng's Generative AI for Everyone course.

That experience was genuinely life-changing. Not because it taught me tools or techniques โ€” but because it rewired how I think. About building. About engineering. About what is possible for anyone, anywhere, with the right mindset and the right tools in their hands.

Between Patrick Debois' evolution and Andrew Ng's insights โ€” something started shifting inside me that I couldn't ignore.

I started asking a different question.

Not โ€” what can AI do?

But โ€” what does this mean for how engineering should actually work?


๐Ÿ—๏ธ What I had been watching for years

Long before ChatGPT. Long before AI-generated code. Long before Vibe Coding became a buzzword on every feed.

I started my technology journey in 1999.

By 2001 โ€” barely two years in โ€” I had already moved into leadership.

Leading teams. Building operations from scratch. Designing systems that had to hold under real pressure. And for over two decades after that โ€” I kept seeing the same pattern repeat itself. Across every team I led. Every company I worked with. Every industry I touched.

Engineers are smart. Engineers are capable. Engineers are passionate โ€” especially early in their careers, when the excitement of building something real is still fresh and alive.

But most of them are not engineering.

๐Ÿ” They are fixing what broke yesterday.

๐Ÿ” They are handling what is on fire today.

๐Ÿ” They are unknowingly setting themselves up to repeat it all tomorrow.

It became a loop. A trap. And most teams didn't even realize they were inside it.

Every time I tried to push something meaningful forward โ€” to build something that actually mattered, to move the needle instead of just keeping the lights on โ€” the answer was almost always the same.

"The team is tied up with something important right now."

"We'll get to it later."

"Just give us a few weeks to clear this backlog."

But later never came. The backlog never cleared. And the meaningful work kept getting pushed further and further away.

The passion that brought people into engineering in the first place? It was quietly disappearing. Buried under daily firefighting, urgent requests, and a present that consumed everything โ€” leaving nothing for the future.


๐Ÿ˜ณ The civil engineer problem

I started explaining this pattern with an analogy that I still use today.

Think about a civil engineer.

Their job โ€” their entire purpose โ€” is to design and architect. To think deeply before anything gets built. To make decisions at the drawing board that determine the quality, safety, and longevity of everything that follows.

Now imagine that same civil engineer spending their days mixing cement, laying pipes, and placing bricks one by one.

That's not engineering. That's labour.

And with full respect to everyone who has lived this โ€” that's what a lot of software engineering had quietly become.

Engineers spending the majority of their time on low-level execution. On tasks that a well-designed system should handle automatically. On work that kept the present alive but did nothing to build the future.

I saw this pattern for years. I talked about it constantly. I pushed back against it wherever I could.

But for most of that time โ€” I didn't have a clean, complete answer to it.

Then late 2022 happened.


โšก The Karthik experiments

After that absurd moment with the simple calculation โ€” I didn't just sit with the insight. I started acting on it.

I began discussing with Karthik โ€” a young SRE on my team, curious, sharp, and willing to go on a crazy journey with me โ€” that we should not just use AI to generate code.

We should go further.

  • AI should generate code.

  • Execute that code.

  • And then improve it continuously based on human feedback โ€” something like reinforcement learning from human feedback, but applied practically to our daily engineering work.

At that time, this thinking was far ahead of what tools could actually do.

Naturally, people around me โ€” including Karthik, and Noordeen and Aravindan on the team โ€” thought this was just another one of my wild ideas.

๐Ÿ˜„ And honestly? They were completely used to that.

But wild ideas backed by persistence have a way of eventually becoming real.

We moved step by step.

First โ€” AI for code generation. Just getting comfortable with what it could do.

Then โ€” figuring out execution. How do we go from generated code to running code?

Then โ€” thinking about feedback loops. How does the system improve over time based on what we learn?

Over time, we reached a point that actually went beyond what we had initially imagined when we started.

We experimented with several tools along the way โ€” some open-source, some still fragile and unreliable at that stage. The first real breakthrough came when we started using Aider.

That's when things became practical. That's when the loop started working. That's when this whole journey started feeling less like a crazy idea and more like something genuinely real.


๐ŸŽฏ The insight that tied everything together

Through all of those experiments, one question kept coming back to me.

Why are some engineers thriving with AI while others are drowning in it?

It wasn't skill. It wasn't experience. It wasn't even how much they knew about AI or how long they had been using it.

It was clarity.

The engineers who were thriving weren't the ones who knew the most. They were the ones who knew clearly what they wanted โ€” before they ever opened an AI tool. They had thought through their intent. They had designed before they executed.

And the ones who were struggling? They were jumping straight into generation. Asking AI to build without first deciding what to build. Moving fast without a direction.

AI didn't fix the firefighting loop.

For most people โ€” it made it faster.

Unless you started with design. Unless you started with clarity. Unless you treated engineering the way it was always meant to be treated โ€” architecture first, execution second.

๐Ÿ›ก๏ธ Fury didn't need more agents. He needed a better system. A platform where great people could finally operate at their full potential. The Helicarrier wasn't just a ship โ€” it was the infrastructure that made everything else possible.

That's what I started building.

Not a tool. Not a process. A way of thinking about building in the AI era.

I call it Vibe Engineering.


๐Ÿš€ What this all means

Vibe Engineering is my answer to the firefighting loop.

It starts with design โ€” with clarity of intent before execution begins. It combines human architecture with AI orchestration in a continuous loop that makes both better over time.

It's built on one belief I've held for 27 years and never once wavered from:

Spend more time on design and architecture. So that you spend less time on development, deployment, and operations.

What was hard to achieve consistently before AI is now becoming real. What I believed for years is finally becoming practical.

And that is exactly where Vibe Engineering comes alive.


๐Ÿ›ก๏ธ A word about how this series is written

You just read a story built from 27 years of living this โ€” and shaped by AI.

That's not a contradiction. That's the point.

This series is openly co-authored with AI โ€” and I want to be specific about how, because the how matters.

Think about the greatest biographies you've ever read. The ones that felt alive, vivid, deeply human. In most cases, those books weren't written entirely by the person whose name is on the cover.

The thoughts, the experiences, the voice โ€” entirely theirs. The craft of translating that voice onto the page โ€” shaped by a writer who worked closely alongside them.

That writer rarely got credited. ๐Ÿค

I'm doing this differently.

๐ŸŽ™๏ธ ChatGPT Voice captures my raw thinking as I speak โ€” unfiltered, unscripted, exactly as it comes out of my head in the moment.

โœ๏ธ Claude AI then takes that transcript and acts as writer and editor โ€” structuring the ideas, sharpening the language, and making sure what you read actually reflects what I meant to say.

๐ŸŽจ Google Gemini Nano Banana Pro crafts the cover image for each post โ€” bringing the visual identity of Vibe Engineering to life.

The thinking is mine. The voice is mine. The 27 years of experience are mine.

The craft of putting it on the page โ€” and the image on the cover โ€” is shaped by AI. And every AI that contributes gets credited.

That itself is Vibe Engineering in action.


โœ… The breakthrough isn't always the moment you find the answer. Sometimes it's the moment you finally understand the right question.

๐Ÿ’ฌ What was the moment that made you rethink how you build things?


Next โ€” VE #2.

The difference between Vibe Coding and Vibe Engineering. Why one is a trap and the other is a discipline. And why it matters more right now than ever before.

See you Wednesday, April 8th at 12:05 PM IST. ๐Ÿ›ก๏ธ


Humans architect. AI orchestrates. Everyone builds.

โ€” Swami K / @iswamik