AI Won't Replace Infrastructure Engineers—It Will Move Them Up a Layer
AI and Infrastructure Engineering
The push to make every repo agent-readable raises a familiar question: does AI make infrastructure engineers redundant? The author argues no, drawing a parallel to Kubernetes, which automated away server management but moved engineers up to workload orchestration. AI is now automating the lookup and syntax work—generating Helm charts and Terraform modules—while engineers still provide direction. The tradeoff is real: fundamentals get rustier, but the layer above remains human, for now.
Kubernetes didn't replace infrastructure engineers, it replaced a layer of their work and moved them up one.
- frio
> The honest tradeoff
> That’s not a hypothetical cost - it’s
> But that’s exactly the
These are strong tells for an AI authored article. I know we're all tired of people saying "this is AI" as it's harmful to discussing the content of an article, but articles about AI, (seemingly!) written by AI, extolling the virtues of AI -- don't really seem to drive the discussion forward to me either.
- cassianoleal
> Four years ago I hand-wrote a nested for loop - four levels deep, tagging subnets across regions and availability zones in another AWS account - and it took me about an hour to get the syntax right
I do believe this kind of engineer requires AI. I also hope I don't have to work in the same teams as them. Seasoning teaches you to make changes in other parts of the codebase rather than do this kind of data mangling on local variables, which is incredibly hard to troubleshoot and very brittle - not to mention it's a nightmare to read back and understand.
- anon7000
Matches my experience working with LLMs on Kubernetes. They are amazing at writing the boilerplate yaml, and fantastic at using kubectl to monitor and debug clusters (with guardrails and readonly permissions in place of course.) if you have a staging/test cluster, you can get an extremely fast feedback loop if you let it apply changes as well.
It’s a good example of how highly structured, well- documented, opinionated frameworks help LLMs do well. There’s just less room for subjective issues when there’s more structure around it.
- skinfaxi
> Did Kubernetes kill Ansible? Kind of. I haven’t written an Ansible playbook in years - if you handed me one right now I’d be squinting at the module syntax like I’d never seen it before - not because configuration management stopped mattering, but because Kubernetes made server management easy enough that we stopped building our own node images at all - we just use whatever the cloud provider hands us, an AWS AMI built for us, no questions asked. And when did I last SSH into a node to debug something?
K8s did not kill Ansible because of ease. Ansible is obsolete because we moved from creating a machine and changing it to instantiating it with the changes we wanted. Ansible makes sense when you are continuously updating a server-in-place and is decidedly less useful when you spin up a new unit with the new configuration when changes are made. Even in this instance the underlying skills remain the same.
- purpleidea
For most users, Kubernetes has added complexity and cost, but not value. The sooner we realize this, the sooner we start thinking about how things should be built. Whether or not you have LLMs has nothing to do with that. The LLM will happily help build your crap even faster!
Maybe people will finally realize they need to start rethinking infrastructure automation. I am.