I'm not an AI doomer nor a maxi. But, of all the tech field roles it seems to me devops is ripe for automation. Been seeing it on my teams.
What do you all think.?
Devops is MUCH less complex than app development. Much more repeatable and engineers already have a good base knowledge of the space. They just don't specialize in it.
Only a few years ago it wasn't even a job. If I were a Devops guy I'd be diversifying and getting good at using AI.
Hmm... if you mean that creating a set of yaml pipeline descriptors for actions or azure pipelines can be done by LLMs, then you're right, but the result suffers hard from GIGO (prompts but also internal docs and existing infra) and I wouldn't dare auto-deploying LLM-only pipelines without HitL.
Bugfixing from an issue ingestion pipeline is much the same. Can automate it until PR, but auto-merging is risky. Even if you have the tailored markdown with all institutional knowledge your org has accumulated over the years, you'll probably still want HitL. Remember: Amazon enforced HitL and full bot-operator accountability after a series of poor LLM-generated patches caused downtime.
Yes, there will be less yaml-writing going on, but there will be more yaml-reading going on, and presumably edits.
I personally heavily rely on devops and more importantly issueops pipelines in my day-to-day, with tons of automation, LLM integration. Like the CD pipelines for many orgs, this has become critical infra for me; perhaps the most critical component of my entire set-up these days. yoloing in a bot-authored change on that can be extremely costly.
So, I'm not sure. Experienced devops engineers (as in they who design and automate the end-to-end stack) are perhaps your most valuable colleagues nowadays. They'll spot the problems in LLM-generated implementations of LLM-generated ideas fueled by LLM-generated prompts all derived from the one-liner "plz Claude, gief CD pipeline"
Yeah... was not suggesting auto anything. You need an operator. Was suggesting we may go back to the generalist engineer with these tools.
That was what the "original" devops vision was about anyway: putting ops with the devs.
I loved it because it removed a barrier / point of friction, reducing tension between IT services and R&D, less stupid blame games, less frustration, more customer minded developers. So I think that that's not a bad outcome; I never liked the "worst of both worlds" where we put new teams between devs and ops and called it devops.
Yeah, I could have an outdated definition of devops. FWIW I did also say devops people should get good at using these tools.
Idk, I still get a lot of “this will work”, followed by me trying it, sharing an error, and “oh yes, I should have caught that.” That’ll probably get better over time, but it’s not there yet.
As a software engineer, the thing I find challenging with DevOps is the testing cycle tends to be long (compared to app code), so it’s harder to iterate and find a solution quickly. Plus there’s also more rigid constraints on infra than app code. Perhaps that’s just because I’m not a DevOps person though
You are describing my experience with Claude and also my experience with everyone that writes code. This will work... Wait. Now it will work.
My colleagues and I have been able to do a lot with Claude. There are issues. There is operator skill and experience required. You can't expect to one shot it. But it is a much easier problem space than greenfield app dev IMO.
IMO It’s a bit like how folding laundry is less complex than programming. Maybe it’s more rote for humans but bots are not trained to do devops and have a harder time with that class of problems.
I dunno man. Claude has been very effective given enough context and specifics on tooling.
It depends on what you mean by devops. If you mean the programming part I agree. If you mean the reactive/event driven stuff, I don't imagine we're there yet.
I might have a weird view of devops. I see them kind of like forest ranger firefighter types.
Another thing is that I work in a really big org vs the far more free world of indie / bitcoin Dev.
I also see a bug spectrum of effectiveness with LLM operators and paradigms that seem to fit better than others.
Functional programming and smaller modular approaches seem to be easier to leverage LLMs. Massive complex OOP projects are much harder to reason about. Even strongly and loosely typed languages seem to have different levels of effectiveness in this world.
And I also wonder how many people taking about LLMs are still using chatbots with limited context and memory vs tools like Claude Code, Pi, or Open Code. These things make a massive difference in the results.
On top of all this is learning how to use the LLMs instead of forcing them work the way you prefer. There are always tradeoffs. No silver bullets. We lose something when we use LLMs for sure
Yeah... we might need to define devops. The kind of tasks I am thinking of are tool configuration mostly. Not architectural design if systems. LLMs are good at patterns. Not so much at creativity.
With the pace AI keep evolving and learning, Devops aren't the only people that will need diversifying. Every tech job will need this evolution of skillset.
100%. My whole point is devops is low hanging fruit. I find myself working more like a hybred of a project manager and architect more than coder. Because I have written code for over 20 years that feels weird.