AI and Infrastructure Engineering

0megion1 pts0 comments

AI and Infrastructure Engineering · Omegion<br>Omegion<br>I run infrastructure at high-traffic, high-responsibility scale, and small mistakes get expensive.<br>Most days that's Kubernetes and AWS, other days a small Go tool or a side project shipped for fun, most of which didn't work out.

Search

Home

GitHub

LinkedIn

RSS

Tags

Theme<br>&copy; 2026 Omegion

Introduction<br>There&rsquo;s a push right now for whole companies to adopt AI wholesale - dump<br>every bit of context into it, write an AGENTS.md or INSTRUCTIONS.md in<br>every repo so any project is discoverable and contributable by an agent, not<br>just a human. The question that comes with it is the obvious one: does this<br>make engineering redundant? Once all the context about a stack and its<br>infrastructure is written down somewhere an agent can read it, are we next?<br>I don&rsquo;t think that&rsquo;s quite the right question, because we&rsquo;ve already lived<br>through a version of it.<br>We&rsquo;ve Been Here Before<br>Did Kubernetes kill Ansible? Kind of. I haven&rsquo;t written an Ansible playbook<br>in years, not because configuration management stopped mattering, but<br>because Kubernetes made server management easy enough that we stopped<br>building our own node images at all - we just use whatever the cloud<br>provider hands us, an AWS AMI built for us, no questions asked. And when did<br>I last SSH into a node to debug something? Mostly never. If a node&rsquo;s acting<br>up, I kill it and hope the replacement doesn&rsquo;t have the same problem. The<br>next layer up went the same way: run a container on ECS Fargate, in a<br>Lambda, or on Cloudflare Containers, and I genuinely don&rsquo;t know or care what<br>node it landed on - but that doesn&rsquo;t mean nobody&rsquo;s orchestrating it, it<br>means I still decided that workload should be a container in the first<br>place, what image it runs, what it&rsquo;s allowed to talk to, how it scales, what<br>happens when it fails. Kubernetes and serverless containers didn&rsquo;t remove<br>that layer of decisions, they moved the unit of work up from &ldquo;the machine&rdquo;<br>to &ldquo;the workload,&rdquo; and everything below that layer got quietly automated<br>away.<br>Nobody would say Kubernetes, or Fargate, or Cloudflare&rsquo;s container platform,<br>replaced infrastructure engineers. Each one replaced a specific layer of<br>manual work - hand-building images, hand-patching boxes, knowing which node<br>a workload landed on - and the engineers moved up to the layer above it<br>every time. I think AI is doing the same thing again, one layer higher.<br>What Changed Day to Day<br>I use Claude daily to generate Helm charts and write Terraform modules. The<br>part it actually removed from my day isn&rsquo;t the thinking - it&rsquo;s the<br>lookup work. I don&rsquo;t read through the AWS provider&rsquo;s changelog to figure out<br>what changed between v5 and v6 anymore; I describe what I want, in whatever<br>shape I want the module or chart to end up, and Claude produces a version of<br>it. It takes iteration to get it into the shape I&rsquo;d actually ship, but once<br>it&rsquo;s there, it becomes the example for next time - especially with an<br>AGENTS.md in the repo pointing at it.<br>The same thing happened one level down a while ago: I don&rsquo;t hand-write raw<br>Kubernetes YAML any more than I hand-write Ansible modules - that&rsquo;s what<br>Helm charts are for. Increasingly, I don&rsquo;t hand-write the Helm chart either.<br>I direct what it should do, and Claude writes it.<br>What Hasn&rsquo;t Changed<br>I still need to know what a good Terraform module or a well-structured Helm<br>chart looks like. I still need to be able to SSH into a node when something<br>genuinely goes wrong and killing the pod isn&rsquo;t an option - the layer above<br>doesn&rsquo;t remove the layer below, it just moves how often you have to touch<br>it. And I&rsquo;m still the one deciding the actual shape of things: what the<br>final version of a module looks like, what&rsquo;s maintainable a year from now,<br>how a chart should be deployed and versioned. AI does the time-consuming<br>part. I still give the direction.<br>The Skill You Trade Away<br>The honest tradeoff: I&rsquo;m faster at building and debugging things than I was<br>two years ago, and I&rsquo;m also visibly rustier at the fundamentals underneath<br>that speed. My HCL syntax recall isn&rsquo;t what it used to be. My reflexes for<br>debugging a broken box over SSH are a little slower than when that was the<br>only way I knew how to do it. That&rsquo;s not a hypothetical cost - it&rsquo;s one I<br>can feel happening in real time, the same way plenty of engineers who came<br>up after Kubernetes never really learned to hand-roll a server image, and<br>were fine, because they never needed to.<br>Where This Goes Next<br>The part I&rsquo;m less sure about is how long &ldquo;I still give the direction&rdquo; holds.<br>Right now I&rsquo;m the one who decides the long-term shape of a stack, because I<br>have the context and the agent doesn&rsquo;t - not really, not beyond what&rsquo;s<br>written down in a repo&rsquo;s AGENTS.md. But that&rsquo;s exactly...

rsquo layer kubernetes node still hand

Related Articles