Terraform vs. Pulumi in 2026: Which Should You Learn First?

Muskan Bandta — Mon, 06 Jul 2026 10:17:33 +0000

If you're getting into infrastructure as code, you hit the same fork in the road I did: Terraform or Pulumi? Both let you define cloud infrastructure in files instead of clicking around a console. Both are widely used. So which one do you actually learn first?

Short answer: learn Terraform first, then try Pulumi once you understand the core ideas. I'll explain why, and when the opposite makes sense.

What they actually are

Terraform came out in 2014 and became the default way teams manage cloud infrastructure. You write config in a language called HCL (HashiCorp Configuration Language), run a plan, and apply it. It's declarative, which means you describe the end state and Terraform figures out the steps to get there.

Pulumi arrived in 2018 with a different bet. Instead of a custom language, you write infrastructure in a language you probably already know: Python, TypeScript, Go, C#, or Java. Six languages in total. Same goal, real code.

The 2026 license situation you can't ignore

This is the part that changed everything, and it's why the "which should I learn" question is more loaded than it used to be.

In August 2023, HashiCorp changed Terraform's license from open source to the Business Source License. You can still use Terraform for free to manage your own infrastructure, but the change upset a lot of the community. So they forked it and created OpenTofu, which is true open source under the Linux Foundation. Then in February 2025, IBM closed a $6.4 billion deal to acquire HashiCorp.

Here's the good news for a learner: OpenTofu is a drop-in replacement for Terraform. Same HCL, same commands. As of mid-2026 it lists more than 3,900 providers. So learning "Terraform" today really means learning HCL, and that skill works across both Terraform and OpenTofu. You're not betting your time on one company.

Pulumi stayed permissively open source (Apache 2.0) the whole time, which is a fair point in its favor.

HCL vs real code

This is the biggest day-to-day difference.

With Terraform you learn HCL. It's easy to read and hard to misuse, but it's a limited language. When you need loops or conditionals, it can get awkward.

With Pulumi you use a real programming language. If you already write Python or TypeScript, that's a head start. You get loops, functions, tests, and your normal editor tools. The tradeoff is that you can also write overly clever infrastructure code that the next person struggles to follow.

What the job market looks like

I scanned job boards while writing this, and it isn't close: Terraform shows up in far more infrastructure and DevOps listings than Pulumi. If your goal is getting hired in the next year or two, that matters. Most teams already running cloud infrastructure are on Terraform or moving to OpenTofu, not switching to Pulumi.

So which do you learn first?

Learn Terraform, or OpenTofu, first. Three reasons:

It's what most jobs ask for, so it pays off faster.
HCL forces you to think in terms of desired state, which is the core idea behind all of these tools. Once that clicks, any IaC tool makes sense.
The community, examples, and Stack Overflow answers are much bigger, so you get unstuck faster as a beginner.

Learn Pulumi second, or even first, if one of these is true: you already write Python or TypeScript every day and want to reuse that skill, or your team has already chosen Pulumi. In those cases the real-language advantage is worth a lot, and there's no reason to fight it.

Vibe Coding with AI: What It Actually Feels Like to Build with an AI Agent

Muskan Bandta — Mon, 06 Jul 2026 08:47:03 +0000

I spent one weekend, about six hours, building a small project almost entirely by talking to an AI agent. Barely any typing. No tutorials open. By Sunday night I had something that worked, and I honestly wasn't sure how I felt about it.

People call this "vibe coding." You describe what you want, the AI writes and runs the code, and you steer instead of type. I wanted to know if it was real or just hype, so I tried it on actual work instead of a toy demo.

Here is what it was like.

What vibe coding actually means

The idea is simple. You stop writing every line yourself. You tell an AI agent the outcome you want, and it writes the code, runs it, reads the errors, and fixes its own mistakes while you watch.

My old process for a small script looked like this: open the editor, half-remember the syntax, open four Stack Overflow tabs, forget which library I used last time. A task like that used to eat about two hours of my evening.

With an agent, I described the same script in two sentences and had a working version in under ten minutes. That gap is the whole reason people are excited.

The first hour feels unreal

I'll be honest, it's a little addictive. You ask for something and it exists a few seconds later. No boilerplate. No setup rabbit holes.

The loop is so fast that it changes what you're willing to try. I tested three different approaches to one problem in the time it usually takes me to set up one. When trying an idea is cheap, you try more ideas. That part genuinely changed how I work.

Then reality shows up

The hype posts skip this part, so I won't.

The AI is only as clear as you are. When I was vague, I got vague code. "Make it better" got me nothing useful. "Add a retry that backs off and stops after 30 seconds" got me exactly that. Lazy thinking produced lazy results, and that was on me.

It's also confidently wrong sometimes. Once it handed me clean, professional-looking code that ran fine and did the wrong thing. I only caught it because I read all 40 or so lines before saving. If I couldn't read the code, I would have shipped a bug and felt good about it.

You can also lose the plot. In one session the agent made about a dozen changes in a few minutes. I caught myself nodding along without understanding my own project. I had to stop and actually read what changed.

What made it click

The shift for me was thinking of myself as the director, not the typist.

I decide what to build and why. The AI handles a lot of the how. I still own the review and the judgment call when something looks off. As someone who works in cloud and automation, this felt familiar. It's close to writing a CI pipeline or a Terraform file: you declare what you want, and something else does the repetitive work.

Does it make you a worse engineer?

I was worried it would. After a week of using it, my honest answer is: only if you let it think for you.

Used well, it took the boring parts off my plate and left me more energy for the decisions that actually matter. Used lazily, it's a fast way to ship code you don't understand. That's a choice, not a side effect.

My take

Vibe coding isn't magic, and it isn't the end of programming. It's a power tool. In careful hands it's great. In careless hands it will cost you later. Same as most tools we've picked up over the years.

I'm keeping it in my workflow. I'm just staying the one making the calls.

Have you tried building something this way yet? I'd like to hear whether it felt like a superpower or a headache, so tell me in the comments. I'm new here and writing about everything I learn in cloud, AI, and automation, so a follow means a lot.

DEV Community: Muskan Bandta