6 min read
Introduction
There’s a push right now for whole companies to adopt AI wholesale - dump
every bit of context into it, write an AGENTS.md or INSTRUCTIONS.md in
every repo so any project is discoverable and contributable by an agent, not
just a human. Slightly funny, if you think about it: I’ve never once gotten
a human teammate to actually read the README, and now we’re all writing
better docs than we ever did, just aimed at a robot instead. The question
that comes with it is the obvious one: does this make engineering redundant? Once all the context about a stack and its
infrastructure is written down somewhere an agent can read it, are we next?
I don’t think that’s quite the right question, because we’ve already lived through a version of it.
We’ve Been Here Before
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? 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.
Nobody 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.
What Changed Day to Day
I use Claude daily to generate Helm charts and write Terraform modules. The
part it actually removed from my day isn’t the thinking - it’s the
lookup work. I don’t read through the AWS provider’s changelog to figure out
what changed between v5 and v6 anymore; I describe what I want, in whatever
shape I want the module or chart to end up, and Claude produces a version of
it. It takes iteration to get it into the shape I’d actually ship, but once
it’s there, it becomes the example for next time - especially with an
AGENTS.md in the repo pointing at it.
The 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.
What Hasn’t Changed
I 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.
The Skill You Trade Away
The honest tradeoff: I’m faster at building and debugging things than I was
two years ago, and I’m also visibly rustier at the fundamentals underneath
that speed. My HCL syntax recall isn’t what it used to be. 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:
locals {
subnet_tags = merge([
for account, regions in var.accounts : merge([
for region, azs in regions : merge([
for az, subnets in azs : {
for subnet_id, tags in subnets :
"${account}/${region}/${az}/${subnet_id}" => tags
}
]...)
]...)
]...)
}Four merge([...]...) calls stacked on top of each other just to flatten a
map of a map of a map of subnets. Claude writes the equivalent in seconds now,
and if you asked me to produce that from scratch today, I’d genuinely have
to sit and think about it. My reflexes for
debugging a broken node over SSH are a little slower than when that was the
only way I knew how to do it. That’s not a hypothetical cost - it’s one I
can feel happening in real time, the same way plenty of engineers who came
up after Kubernetes never really learned to hand-roll a server image, and
were fine, because they never needed to.
Where This Goes Next
The part I’m less sure about is how long “I still give the direction” holds.
Right now I’m the one who decides the long-term shape of a stack, because I
have the context and the agent doesn’t - not really, not beyond what’s
written down in a repo’s AGENTS.md. But that’s exactly the gap those
company-wide AI pushes are trying to close: give the agent the whole
context, not just one repo’s. If that actually works, an agent with a
genuine long-term view of the entire infrastructure - not just this
Terraform module, but every decision made across every repo for years -
might end up planning better than I do, the same way I can’t out-debug a
tool that’s read every changelog for every provider I use.
Kubernetes 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.