This works because he has decades of working experience at the foundational layers and understands each layer of abstraction, what it solves and the interaction between the abstractions. Can still reason it out, if not the fastest at troubleshooting lowest layers because its no longer in muscle memory. AI can make you productive if you have the necessary experience (which takes a long time).
But, AI natives have none of the knowledge of ANY layers, even at the highest layer at which they will be using AI. They only learn how to do prompts, etc and nothing else about what is being done. This is just like anyone can be a pilot because planes mostly fly themselves.
> 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.
It is Terraform’s configuration language. Locals mean something specific : non-exported variables. Constructing the map or whatever prior to plan phase is pretty idiomatic. Note the key in the map is a string concatenation. Not something you would do elsewhere but a constraint of that framework.
> 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.
SRE here, why would you create your own node images for Kubernetes Nodes? Unless they deliver some weird kernel that would cause containers not to run, there is no reason not to take cloud provider image.
If you need something extra on the nodes, 99% of the time, DaemonSets will do the job.
This article basically captures my current professional life to a high degree of accuracy. I still enjoy the work. I still get the satisfaction of conceiving a thing and seeing it realized. That has always been at the root of the pleasure that I get from this job. Like the author I find myself drifting away from the underlying layers that the agents has so thoroughly mastered, and like the author I wonder about its eventual mastery of the parts I still consider my domain.
> 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.
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.
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.
This is an extremely common misunderstanding about AI in software. In order for AI to "move up one layer of abstraction" it has to actually be an abstraction. But AI output will _always_ be flawed in ways that mean you still need to fully understand the layer below it.
But, AI natives have none of the knowledge of ANY layers, even at the highest layer at which they will be using AI. They only learn how to do prompts, etc and nothing else about what is being done. This is just like anyone can be a pilot because planes mostly fly themselves.
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.
> 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.
This dude is just bad at his job.
If you need something extra on the nodes, 99% of the time, DaemonSets will do the job.
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.
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.
It’s a good example of how highly structured, well- documented, opinionated frameworks help LLMs do well.