Vibe Ops

July 9, 2025

It's one thing to vibe code a simple app. But have you tried yet to vibe-code the process of moving code from development to test into production? Have you tried to vibe-code your own environment strategy? Have you vibed operations?

Well, I have. And I'm here to tell you that it's awesome.

It's also maddening at times. But still awesome.

The good news: You don't have to be limited by someone else's platform or have to conform to someone else's patterns. You can build infrastructure that matches your own way of thinking, and if you're careful, it works!

You want to use GitHub Actions, sure, that's fine, probably a good idea. Especially if you work on a team. But it's no longer necessary.

Back in the day (about eight months ago) I was waist-deep in DevOps trying to implement a complicated layering strategy, and my ex(-platform) couldn't handle it.

Now, I have something way better: DevOps that thinks like I do. Because that's how I vibe-coded it.

I did it my way.

(Regrets? I had a few. But then again, too few to mention.)

Listen, I spent months learning stuff like GitHub Actions and writing Bicep scripts by hand. I know exactly what I want. And if it's just as easy for an AI chatbot to build it without the extra dependency of an external framework, fine with me -- if it works.

And guess what? It works.

As an example, I set up dev-test-prod environments for code (which is standard) and then parallel dev-test-prod environments for data (which is not standard). This means I can try out test code with production data; or visualize new data using production code -- all through a simple command-line interface.

The result: I can design, iterate, test, and launch faster.

The big problem is that it's non-standard, which means that if I ever need to let someone else work on my code, they're going to have to be on my vibration frequency.

But that's true for any paired programmer situation. Every software developer has a favorite IDE that they set up just the way they like it to match the way they think. I'm just doing it with the operations layer.

That's how it works inside of our respective skulls, and I see no reason why that model shouldn't also define how we build systems.

With VibeOps, our systems will undergo a flowering of individuality -- and that's exactly what we need in this world.