{"slug": "ai-and-infrastructure-engineering", "title": "AI and Infrastructure Engineering", "summary": "AI tools like Claude are automating the lookup and boilerplate work of infrastructure engineering, moving engineers up the stack from hand-writing Helm charts and Terraform modules to directing AI-generated versions, according to an engineer's account. The author argues this mirrors how Kubernetes and serverless platforms replaced manual server management without eliminating the need for engineers, who still must judge quality and handle rare deep debugging. The tradeoff is that engineers trade away some hands-on skills for speed, but the core decision-making role remains.", "body_md": "# AI and Infrastructure Engineering\n\n## Introduction\n\nThere’s a push right now for whole companies to adopt AI wholesale - dump\nevery bit of context into it, write an `AGENTS.md`\n\nor `INSTRUCTIONS.md`\n\nin\nevery repo so any project is discoverable and contributable by an agent, not\njust a human. Slightly funny, if you think about it: I’ve never once gotten\na human teammate to actually read the README, and now we’re all writing\nbetter docs than we ever did, just aimed at a robot instead. The question\nthat comes with it is the obvious one: does this make engineering redundant? Once all the context about a stack and its\ninfrastructure is written down somewhere an agent can read it, are we next?\n\nI don’t think that’s quite the right question, because we’ve already lived through a version of it.\n\n## We’ve Been Here Before\n\nDid 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? Mostly never. If a node’s acting up, I kill it and hope the replacement doesn’t have the same problem. The next layer up went the same way: run a container on ECS Fargate, in a Lambda, or on Cloudflare Containers, and I genuinely don’t know or care what node it landed on - but that doesn’t mean nobody’s orchestrating it, it means I still decided that workload should be a container in the first place, what image it runs, what it’s allowed to talk to, how it scales, what happens when it fails. Kubernetes and serverless containers didn’t remove that layer of decisions, they moved the unit of work up from “the machine” to “the workload,” and everything below that layer got quietly automated away.\n\nNobody would say Kubernetes, or Fargate, or Cloudflare’s container platform, replaced infrastructure engineers. Each one replaced a specific layer of manual work - hand-building images, hand-patching boxes, knowing which node a workload landed on - and the engineers moved up to the layer above it every time. I think AI is doing the same thing again, one layer higher.\n\n## What Changed Day to Day\n\nI use Claude daily to generate Helm charts and write Terraform modules. The\npart it actually removed from my day isn’t the thinking - it’s the\nlookup work. I don’t read through the AWS provider’s changelog to figure out\nwhat changed between v5 and v6 anymore; I describe what I want, in whatever\nshape I want the module or chart to end up, and Claude produces a version of\nit. It takes iteration to get it into the shape I’d actually ship, but once\nit’s there, it becomes the example for next time - especially with an\n`AGENTS.md`\n\nin the repo pointing at it.\n\nThe same thing happened one level down a while ago: I don’t hand-write raw Kubernetes YAML any more than I hand-write Ansible modules - that’s what Helm charts are for. Increasingly, I don’t hand-write the Helm chart either. I direct what it should do, and Claude writes it.\n\n## What Hasn’t Changed\n\nI still need to know what a good Terraform module or a well-structured Helm chart looks like. I still need to be able to SSH into a node when something genuinely goes wrong and killing the pod isn’t an option - the layer above doesn’t remove the layer below, it just moves how often you have to touch it. And I’m still the one deciding the actual shape of things: what the final version of a module looks like, what’s maintainable a year from now, how a chart should be deployed and versioned. AI does the time-consuming part. I still give the direction.\n\n## The Skill You Trade Away\n\nThe honest tradeoff: I’m faster at building and debugging things than I was\ntwo years ago, and I’m also visibly rustier at the fundamentals underneath\nthat speed. My HCL syntax recall isn’t what it used to be. Four years ago I\nhand-wrote a nested `for`\n\nloop - four levels deep, tagging subnets across\nregions and availability zones in another AWS account - and it took me\nabout an hour to get the syntax right:\n\n```\nhcl\n\nlocals {\n  subnet_tags = merge([\n    for account, regions in var.accounts : merge([\n      for region, azs in regions : merge([\n        for az, subnets in azs : {\n          for subnet_id, tags in subnets :\n          \"${account}/${region}/${az}/${subnet_id}\" => tags\n        }\n      ]...)\n    ]...)\n  ]...)\n}\n```\n\nFour `merge([...]...)`\n\ncalls stacked on top of each other just to flatten a\nmap of a map of a map of subnets. Claude writes the equivalent in seconds now,\nand if you asked me to produce that from scratch today, I’d genuinely have\nto sit and think about it. My reflexes for\ndebugging a broken node over SSH are a little slower than when that was the\nonly way I knew how to do it. That’s not a hypothetical cost - it’s one I\ncan feel happening in real time, the same way plenty of engineers who came\nup after Kubernetes never really learned to hand-roll a server image, and\nwere fine, because they never needed to.\n\n## Where This Goes Next\n\nThe part I’m less sure about is how long “I still give the direction” holds.\nRight now I’m the one who decides the long-term shape of a stack, because I\nhave the context and the agent doesn’t - not really, not beyond what’s\nwritten down in a repo’s `AGENTS.md`\n\n. But that’s exactly the gap those\ncompany-wide AI pushes are trying to close: give the agent the *whole*\ncontext, not just one repo’s. If that actually works, an agent with a\ngenuine long-term view of the entire infrastructure - not just this\nTerraform module, but every decision made across every repo for years -\nmight end up planning better than I do, the same way I can’t out-debug a\ntool that’s read every changelog for every provider I use.\n\nKubernetes didn’t replace infrastructure engineers, it replaced a layer of their work and moved them up one. I don’t think AI replaces engineering either. I think it’s still busy eating the layer just below “give direction” - and I’m not fully convinced that’s the last layer it eats.", "url": "https://wpnews.pro/news/ai-and-infrastructure-engineering", "canonical_source": "https://omegion.dev/2026/08/ai-and-infrastructure-engineering/", "published_at": "2026-08-23 18:09:01+00:00", "updated_at": "2026-08-24 01:12:43.643034+00:00", "lang": "en", "topics": ["artificial-intelligence", "developer-tools", "ai-tools"], "entities": ["Claude", "Kubernetes", "Ansible", "AWS", "ECS Fargate", "Lambda", "Cloudflare Containers", "Terraform"], "alternates": {"html": "https://wpnews.pro/news/ai-and-infrastructure-engineering", "markdown": "https://wpnews.pro/news/ai-and-infrastructure-engineering.md", "text": "https://wpnews.pro/news/ai-and-infrastructure-engineering.txt", "jsonld": "https://wpnews.pro/news/ai-and-infrastructure-engineering.jsonld"}}