Infrastructure in 2035: Anton Babenko on Moving Beyond 'As-Code'

Josh Pollara • August 27, 2025

Anton Babenko

Creator of terraform-aws-modules

AWS Hero & Infrastructure Architect

About Anton

Anton Babenko has been deeply immersed in DevOps, Terraform, and AWS for many years, coming from a software engineering background where doing things "as-code" feels natural. He's best known as the creator of terraform-aws-modules, one of the most widely used collections of Terraform modules with over 1 billion downloads. Throughout his career, Anton has focused on understanding complex technologies and simplifying outcomes, making infrastructure accessible to teams worldwide.

Current Focus: compliance.tf

Anton is currently building compliance.tf, a solution designed to help companies bring compliance-ready infrastructure with significantly less effort. This work builds on years of developing and implementing Terraform AWS modules. Beyond this, Anton frequently speaks at conferences worldwide, publishes the Terraform Weekly newsletter, and has regular Terraform coding live streams on YouTube.

The 'infrastructure-as-code' term coined by current tools will be phased out in a few years.

Q1: Where has Terraform stood the test of time, and where have you hit limitations?

Terraform taught us that "infrastructure-as-code" is a very good idea compared to not having it in any scriptable and reproducible format. I personally like that HCL is limited by design, so that it's very hard to do things you normally shouldn't be doing with infrastructure, compared to generic programming languages. I often see how developers try to jump over these limitations and, using CDK, come up with overengineered and messy solutions. I like that if Terraform is used properly, the final solution will be easier to manage and work on later. Terraform is more restricted – it's a good thing when you want to manage infrastructure reliably, not "vibeform"-ing your way to production.

Terraform being more restricted is a good thing when you want to manage infrastructure reliably.

Q2: Is Kubernetes' continuous reconciliation model the right approach for infrastructure?

Part of the reconciliation process is already doable and highly recommended if you run "terraform plan" regularly and automatically. Applying such changes is a significantly harder part, but using policies and guardrails, it should be possible. I have not met companies that apply the step automatically. The deliberate nature of infrastructure changes is important – most infrastructure changes are high-stakes and require careful consideration. While automation can help with detection and planning, the application of changes still needs human oversight in most organizations.

Q3: Are visual tools replacing code for infrastructure management?

Absolutely, I believe that the "infrastructure-as-code" term coined by current set of tools will be phased out in a few years. There will still be a long tail of companies using current tools and established "as-code" approaches. Currently, some new set of tools are more revolutionary and harder to comprehend than their potential customers expect them to be. I think that the winner in the next generation of infrastructure management tools will have a more responsive interface, and it's not necessarily going to be "as-code."

The winner in the next generation of infrastructure management tools will have a more responsive interface.

Q4: What does daily infrastructure work look like in 2035?

Most progressive users (it's hard to predict 10 years) will not write HCL or manage configurations as complex code – bye-bye CDK. In the coming few years, the demand will be coming more from higher-level stakeholders, and the implementation will happen mostly with the help of a variety of canned solutions (e.g., Terraform modules) governed by policies, controls, and guardrails. The shift isn't just about tools – it's about who's making infrastructure decisions. As infrastructure becomes more abstracted, business stakeholders will have more direct input, with implementation happening through pre-built, policy-governed components rather than hand-written code.

Implementation will happen mostly with canned solutions governed by policies, controls, and guardrails.

Josh's Note

Anton's vision of infrastructure management evolving beyond traditional "as-code" approaches is provocative and aligns with what we're seeing at Stategraph. The future isn't about abandoning code entirely, but about finding the right abstractions and interfaces that balance power with usability. His emphasis on policies and guardrails resonates with our approach to making infrastructure changes safe and collaborative.

Follow Anton's work:

GitHub - Home of terraform-aws-modules and other projects
LinkedIn - Connect for infrastructure insights and updates
Terraform Weekly - Curated newsletter for the Terraform community
YouTube - Live coding sessions and tutorials
compliance.tf - Compliance-ready infrastructure solutions

More in the Series

Matt Gowie on Why We'll Stop Writing HCL →

Steve Wade on Making Infrastructure Boring Again →

Get Started Read the Docs