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"