Posts

The discourse on platform engineering Twitter and Reddit has been pretty consistent for months now: Terraform is dead, HCL is dead, the entire Infrastructure as Code stack is about to get vaporized by autonomous agents that translate intent directly into cloud provider API calls. The 24-month clock is ticking. Pack up your .tfstate and go home. Another DEAD DEAD DEAD narrative emerges.

Open up the claude_desktop_config.json or mcp.json of the average AI tinkerer right now and tell me you don’t flinch. API keys sitting in plaintext. GitHub PATs with repo scope pasted next to a GitLab token that somebody will forget about in six months. A Slack bot token that absolutely should not be in a file backed up to iCloud. We collectively spent a decade teaching engineers not to do this - and then MCP showed up and everybody speed-ran the mistake all over again.

Here’s a question I got asked recently: If a skill can already call a REST API using Bash, why bother with MCP? The surface-level answer is “MCP is cleaner.” That’s not wrong, but it undersells what’s actually different - and I think it’s a genuinely useful distinction to understand if you’re serious about building reliable agent workflows. Also, common-sense needs a resurgence given the massive amount of all old things are DEAD when new thing comes out clickbait that is proliferating on LinkedIn.

Let me paint you a picture. It’s 2025. You’ve discovered that you can describe a feature in plain English and an LLM will just… build it. The dopamine hit rivals or even eclipses social media. You feel as if you’re shipping things in an afternoon that used to take a week. You’re not reading diffs. You’re not understanding the internals. You’re just vibing - and it feels amazing.

If you’ve spent any time building with MCP servers, you know the drill. You start with one server, maybe two. Then suddenly you’re juggling a dozen configurations across three different LLM clients, and your claude_desktop_config.json looks like it was written during a caffeine-fueled fever dream. That’s roughly where I was when I started building gridctl.

As AI dominates tech headlines and corporate strategies in 2024, an important distinction is being blurred - the difference between developing AI versus consuming AI services. This mischaracterization risks confusing the market and overselling capabilities, but that isn’t anything new right? Take zero-trust, cloud computing, or even take a look back at the early-2000s with the web revolution. Urs Baumann tossed out a great questions in the Network Automation Forum - Slack recently, and I thought it would make for a good blog (or maybe venting session depending on how you look at it). Remember, these are opinions.

The foundation of high-performance computing that powers artificial intelligence lies not just in powerful GPUs, but in the intricate web of connections between them. As models grow exponentially in size and complexity, the networking infrastructure that facilitates their training has become a critical bottleneck. This has sparked a fascinating race to develop networking solutions tailored for AI-centric workloads, with tech giants like NVIDIA who are on an infrastructure trailblazing marathon.

In my previous blog on Dilution of Ownership, I explored how startup funding rounds impact equity. Now, let’s dive into a hot-button, highly-debated, and dramatically misunderstood matter of policy - taxing unrealized capital gains (or the wealth tax). Could this policy drastically alter the startup landscape? Would there be a tangible impact on founders, investors, and the innovation ecosystem as a whole?

There is a lot of confusion surrounding the dilution of ownership, especially in the tech startup space. What does this mean in layman’s terms? Who does it impact? And most importantly, why you should care if you plan to work for a startup. This is a topic I have discussed with many new (and even some seasoned) engineers over the past few years. I recently had this very discussion with a senior engineer (and close friend) who is leaving big enterprise for startup land. He suggested I write a blog in the plain speak that I used with him. Little does he know (until now) that this is as deep as I go on this topic!

Sometimes, especially if you aren’t a developer by trade, you can get stuck on something small that will find you banging your forehead on your desk (figuratively, of course). Most of the time, it is easy enough to find an answer online or even from ChatGPT. Other times, you may not be so lucky. The other day, I fell victim to a TWE or time wasting event that I thought was worth writing about. Fasten your seatbelt!

For many moons, importing existing infrastructure (that is to say, infrastructure running outside of Terraform state), has not been a trivial task. Historically, Terraform did not generate any configuration. You would have to write the infrastructure-as-code in a manner that reflects how it was deployed. Then, to make matters not easier, you would fetch the ‘ol shovel and dig out the unique resource identifiers to feed through the command line. Handling a single resource in this manner is pretty simple. Wrangling 20+ resources like this is not. Last month, Terraform v1.5.0 was released, offering the ability to use import blocks. Let’s test this new feature on my favorite infrastructure provider, Alkira.

What fits somewhere in between re:Invent and Community Day events? That would be the AWS Summits! This year, I got to experience a double dose of fun by representing Alkira at our booth and presenting at the AWS Community Developer Lounge. I may be biased, but I believe the Alkira team is the best in the world.