Ship It Conversations: Gareth Kersey on IaCConf 2026, AI, and Corey Quinn’s Terraform Keynote

For this Conversations episode, I wanted to stay anchored on something I think a lot of infrastructure teams are feeling right now.

AI is making software feel faster.

Not necessarily better.

Not necessarily safer.

But faster.

Faster drafts.
Faster pull requests.
Faster experiments.
Faster “hey, can we just ship this?” conversations.

And that sounds exciting until you are one of the people responsible for everything underneath that speed.

The infrastructure.
The permissions.
The deploy path.
The rollback plan.
The policies.
The cost.
The blast radius.

That is what I liked about Gareth’s framing for IaCConf 2026. “Keeping pace” sounds like a simple conference theme, but it is actually a pretty loaded phrase if you work in DevOps, SRE, platform engineering, or infrastructure.

Because keeping pace does not mean blindly moving faster.

It means figuring out how to absorb more change without losing control of the system.

That is a much harder problem.

A lot of the AI conversation around infrastructure still gets stuck at the novelty layer. Can AI write Terraform? Can it generate Kubernetes YAML? Can it open a pull request? Can it explain an error message?

Sure.

Sometimes.

But that is not the whole story.

The more interesting question is what happens after the AI-generated code exists.

Who reviews it?
Who owns it?
Who understands the tradeoffs?
Who decides whether the generated infrastructure actually matches the business need?
Who catches the IAM mistake?
Who notices the cost problem?
Who realizes the change technically works, but creates a terrible operational pattern?

That is where infrastructure as code still matters.

And honestly, that is where experienced infrastructure people matter even more.

Because if AI makes it easier to produce changes, then the review layer, the policy layer, and the platform layer become more important, not less.

That is the thread I kept hearing through this episode.

IaCConf is not just talking about Terraform in isolation. It is talking about the systems around infrastructure delivery. Platform engineering. Governance. Kubernetes. GitOps. Argo CD. AI agents. Internal developer platforms. Operational risk. How teams build safe paths instead of just giving everyone a faster shovel.

That is the part I think is worth paying attention to.

One of the phrases from the agenda that stood out to me was “10x code velocity could mean 10x operational risk.”

That is probably the cleanest summary of the current moment.

A lot of engineering organizations want the productivity story of AI. They want more output. They want faster roadmap execution. They want smaller teams doing more. They want developers unblocked.

But infrastructure teams know there is always another side of that equation.

More output means more change.
More change means more review.
More review means more pressure on systems that may already be stretched.
And if your delivery process, your IaC workflow, your environments, your policy checks, and your operational ownership model were already messy, AI does not magically fix that.

It can amplify it.

That is why I liked that this conversation did not treat AI as a magic replacement for infrastructure discipline.

It was more grounded than that.

The question was not “does AI replace IaC?”

The question was closer to, what should the infrastructure workflow look like now that AI is entering the system?

Do you still want Terraform?
Do you want OpenTofu?
Do you want Crossplane?
Do you want Pulumi?
Do you want Kubernetes-native infrastructure management?
Do you want agents proposing changes?
Do you want agents applying changes?
Where do policies live?
Where do approvals live?
Where does human judgment live?

There is no clean universal answer there.

And I actually appreciated Gareth saying that in different ways throughout the episode. People are still figuring this out. There is not one right answer. A lot of teams are experimenting.

That feels honest.

Because in real companies, the answer usually depends on the maturity of the platform, the skill set of the team, the risk profile of the business, how much standardization already exists, and how much chaos people are willing to tolerate before they decide they need guardrails.

A startup running fast in one AWS account and a regulated enterprise managing hundreds of teams are not solving the same problem.

They might use some of the same tools, but they are not living in the same risk model.

That is also why the community angle matters here.

IaCConf seems interesting because infrastructure as code is one of those areas where the best lessons usually come from people who have actually lived through the mess.

The clean reference architecture is useful.

But the better story is usually, “Here is what we tried, here is what failed, here is what worked, and here is what I would do differently if I had to rebuild it.”

That is what makes practitioner conferences valuable.

Not the booth.
Not the polished diagram.
Not the vendor tagline.

The real value is hearing how other teams are solving the same uncomfortable problems you are probably dealing with too.

How do you manage Terraform at scale?
How do you avoid module sprawl?
How do you keep developers moving without giving everyone production admin access?
How do you make platform workflows self-service without turning them into an ungoverned vending machine?
How do you make infrastructure easier without hiding so much detail that nobody understands the system anymore?

Those are real questions.

And with AI in the mix, they get sharper.

Another piece I liked was the way Gareth talked about the event not being only a Spacelift product vehicle.

That matters.

I have been around enough vendor-led events to know the difference between a community event funded by a vendor and a vendor pitch dressed up as a conference.

Practitioners can feel that difference almost immediately.

If every talk mysteriously ends with “and that is why you should buy our product,” people tune out.

But if the event is willing to host conversations around Crossplane, Kubernetes, Argo CD, Terraform, platform engineering, AI, governance, and broader infrastructure patterns, then it becomes more useful. Even if a vendor is helping fund it.

That kind of transparency is good.

Spacelift funds IaCConf. Gareth works at Spacelift. That is fine. The important question is whether the content is useful and whether the event makes room for ideas beyond the sponsor’s own product lane.

From this conversation, it sounds like they are at least trying to do that deliberately.

The Crossplane example was especially interesting.

Crossplane is not exactly the same thing as a Terraform orchestration platform, but it definitely represents a different philosophy. More Kubernetes-native. More control-plane oriented. More declarative resource management through the cluster model.

And instead of avoiding that because it does not map neatly to Spacelift’s product positioning, they had a Crossplane talk because the community was interested in it.

That is the right instinct.

Because the future of infrastructure is probably not one clean winner.

Some teams will keep using Terraform or OpenTofu.
Some will use Pulumi.
Some will go deeper into Kubernetes-native control planes.
Some will use Crossplane.
Some will build internal platforms that hide most of this from developers.
Some will let AI generate drafts but keep humans in review.
Some will eventually trust agents with limited, policy-bound actions.

The interesting part is not picking the one true religion.

The interesting part is understanding the tradeoffs.

I also liked the discussion around platform engineering, especially the idea that AI agents may become consumers of your platform.

That is a weird sentence, but it is probably where things are going.

Most platform teams have spent the last few years thinking about developers as the primary user.

How do we make the golden path easier for developers?
How do we reduce tickets?
How do we create self-service workflows?
How do we give teams paved roads instead of tribal knowledge?

Now you have to think about what happens when some of those “users” are not humans in the normal sense.

What happens when an AI agent is generating changes against your repo?
What happens when it is calling platform APIs?
What happens when it is requesting environments?
What happens when it is interpreting documentation and making decisions based on it?

That raises the bar for platform design.

Your platform needs to be legible.
Your APIs need to be constrained.
Your docs need to be accurate.
Your policies need to be enforceable.
Your defaults need to be safe.

Because agents do not remove ambiguity. They often charge straight into it with confidence.

That is not a reason to avoid them entirely.

But it is a reason to build better guardrails before wiring them into systems that matter.

That is where the “AI speaks Terraform like a tourist” idea is funny, but also pretty accurate.

A tourist can learn enough phrases to get around.

That does not mean they understand the culture, the consequences, the context, or the subtle ways something can go wrong.

AI can often produce something that looks like Terraform.

But experienced infrastructure engineers know the hard part is not just syntax.

The hard part is knowing why that resource should exist.
Whether the module boundary makes sense.
Whether the IAM policy is too broad.
Whether the networking pattern is going to hurt later.
Whether this should be shared infrastructure or service-owned.
Whether the state layout is going to become a nightmare.
Whether this pattern is going to scale beyond the first happy path.

That is the difference between generating infrastructure code and designing infrastructure.

And I think that distinction is going to matter a lot over the next few years.

Another useful thread in this episode was the conference growth story itself.

The fact that people wanted demos, panels, practitioner stories, and real examples makes sense. Infrastructure people do not usually want vague inspiration for very long. They want to know what worked, what broke, and what they can try on Monday.

That “Monday morning” usefulness is a good bar.

A talk does not have to be a step-by-step tutorial, but it should leave people with something more than a vibe.

A pattern.
A warning.
A decision framework.
A failure mode to watch for.
A way to think about their own environment differently.

That is what I would look for from a conference like this.

And I like that they are talking about future spotlights too. Security. AI. Kubernetes. Open source. Maybe regional meetups. Maybe more community spaces.

That makes sense because infrastructure as code is not really a single topic anymore. It touches almost everything.

Security teams care because IaC defines the blast radius.
Finance teams care because IaC creates spend.
Developers care because IaC affects how quickly they can ship.
SRE teams care because IaC becomes the shape of the system they have to operate.
Platform teams care because IaC is often the foundation of the golden path.
Leadership cares because all of this affects speed, risk, and reliability.

That is why the topic still has legs.

Some people talk like infrastructure as code is “solved” because Terraform has been around for years.

I do not think that is true.

The syntax may be familiar now. The category may be mature. But the organizational problems are absolutely not solved.

Module ownership is still hard.
Policy is still hard.
State management is still hard.
Multi-account and multi-cloud patterns are still hard.
Developer self-service is still hard.
Drift is still hard.
Secrets are still hard.
Reviewing infrastructure changes is still hard.
Knowing when to standardize and when to let teams move is still hard.

AI does not remove those problems.

It mostly changes the speed and volume at which they show up.

So if I had to boil this episode down to one takeaway, it would be this:

AI may change how infrastructure changes get created, but it does not remove the need for infrastructure judgment.

If anything, it makes that judgment more important.

The teams that do well here will probably not be the teams that let AI do everything, or the teams that reject AI completely.

They will be the teams that build clear patterns, strong guardrails, good review loops, useful platforms, and enough visibility to know when the system is drifting away from them.

That is the useful middle ground.

Faster delivery, without pretending speed is the only thing that matters.

More automation, without giving up accountability.

Better self-service, without turning production into a free-for-all.

That is the part worth paying attention to.

This is a guest conversation episode of Ship It Weekly, separate from the weekly news recaps.

This episode is not sponsored. I wanted to cover IaCConf because the theme lines up closely with what Ship It Weekly focuses on: infrastructure, platform engineering, DevOps, SRE, and how teams are adapting to AI-driven change.

In this Ship It: Conversations episode, I talk with Gareth Kersey about IaCConf 2026, a free virtual conference focused on infrastructure as code, platform engineering, DevOps, SRE, and infrastructure operations. The conference is May 14th 2026.

The main theme is “keeping pace.” Not just keeping pace with new tools, but keeping pace with the speed of software delivery now that AI is changing how quickly application teams can write, ship, and change code.

We talk about what that means for the infrastructure teams underneath it all: the people responsible for Terraform, Kubernetes, GitOps, policies, secrets, cost, security, rollback paths, and making sure faster delivery does not turn into faster chaos.

Gareth walks through the IaCConf 2026 agenda, including Corey Quinn’s keynote, AI and Terraform sessions, platform engineering panels, Kubernetes and Argo CD talks, AI agents managing infrastructure as code, governance challenges, and the risk of 10x code velocity becoming 10x operational risk.

The bigger theme here is that AI is not just changing how code gets written. It is changing the pressure on the systems around delivery. Infrastructure as code, platform engineering, policy, and operational guardrails matter even more when the pace of change goes up.

Highlights

• What “keeping pace” means for infrastructure, DevOps, SRE, and platform teams

• Why faster application development can create more downstream operational pressure

• Corey Quinn’s keynote, “AI Speaks Terraform Like a Tourist”

• How AI-generated infrastructure changes create new governance and review challenges

• Why infrastructure as code still matters as AI agents and automation become more common

• Sessions covering Terraform, Kubernetes, Argo CD, GitOps, platform engineering, and AI-driven workflows

• The risk of 10x code velocity turning into 10x operational risk

• How platform teams can support faster developers without giving up safety or governance

• Why IaCConf includes panels, demos, technical talks, and practitioner stories instead of only tool-specific content

• How IaCConf has grown from its first event in 2025 into a broader infrastructure community

• Why the event is trying to stay community-focused instead of becoming just another vendor marketing conference

• The role of feedback, future spotlight events, in-person meetups, and possible community spaces around IaCConf

• Why registering still makes sense even if you cannot attend live, since sessions are available afterward

IaCConf links

• IaCConf 2026 registration page - https://www.iacconf.com/iacconf-2026

• IaCConf LinkedIn page - https://www.linkedin.com/showcase/iac-conf/

• IaCConf: https://www.iacconf.com/

• IaCConf is supported by Spacelift: https://spacelift.com

Our links

More episodes + show notes + links: https://shipitweekly.fm

On Call Brief: https://oncallbrief.com