Hi guys. I have a question out of curiosity. How do you feel about AI agents and DevOps? What's the future of DevOps? Are you using AI agents in your day to day work? It's obvious that the AI agents require DevOps human sight, but I'm curious about what direction you think that DevOps is going to given AI agents invading the infrastructures on all major platforms. I got a feeling that DevOps will also be moving eventually into more the security/governance side (I could be wrong).

From what I've seen thusfar is that mostly play an assistant/bot role but do not get to take actions on their own, even with a human in the loop. The main reason seems to be that it requires the usually rather unique ecosystem to be documented in a palpabale way for the agent as well as tasks just being too diverse for an agent to properly handle. Either the process is so well documented that it gets automated out or it's still too complex to put an agent on it.

I agree with you on this. When I use copilot for example, it seems to be good for just changing small chunks of code but beyond that, I don't think we will see it soon doing everything from end to end especially for micro-services architecture (even though it's possible in theory). Documentation is indeed a bottleneck for a lot of organizations since most organizations nowadays follow the MVP approach. I think that DevSecOps will remain difficult to fully automate since I've also had first hand experience of how complicated deployments could be.

Same here. It's possible to improve workflows but as the overarching entity for solutions we usually deal with the special cases as 80% of our workload which is inherrently near impossible to automate. You'd also need a ton of context for any LLM to properly deal with it and even then you'd need to keep a human in the loop at all times. Plenty of examples where suddenly entire PRD database have been deleted because someone let an agent just do whatever. As for documentation: Is that a problem you ever tried to tackle?

Yes, in the past I tried to encourage Dev teams to treat documentation as part of testing but unfortunately, it's easier to ask a Dev to write an algorithm on a white board than testing and documentation 😁. I do think however, that we might see organizations improving on this by using AI to incrementally fix the documentation problem; most tech organizations don't like hiring technical writers (I don't know why). For example, I could imagine AI agents generating documentation as part of the CI/CD pipelines and it gets reviewed alongside code on the PR.

It's actually a problem I'm trying to work on but more specifically for DevOps/Systems engineers who keep the lights on. There's already a lot of tools that generate documentation for code but very little to help engineers that work in the terminal. In order to write something that would work for everyone I'm trying to understand how different organizations see documentations and what struggles they encounter trying to introduce it. Any chance you'd be willing to tell me some more about how you encouraged them and what problems you encountered along the way? :)

Sure, the following are as per my personal observations in big tech with multi-functional teams. Challenges • Documentation as a checkbox rather than mindset • Ship now, document later • Documentation is outdated (no one has time to update it) • People scared of losing their jobs experience amnesia when documentation is brought up. • Multiple documents written by different people who don't know about each other but about same repo. An organization I worked with in the past, was able to improve documentation traceability via Backstage but it only solved the problem of tracing repos and ownership. Since Atlassian rolled AI already into their confluence (if you're on the SaaS version), helped solve a lot of problems but outdated information still problematic since updating it is usually treated as "Nice to have". I tried encouraging my teams by first of all doing it myself and then I kept reminding them that when all of us are comfortable with the documentation, everyone will afford taking days off and not worrying about prod problems. The main tension point is where leadership focus usually is highly focused on revenue generating tasks and the overall unrest with economy and mass layoffs so everyone is gatekeeping out of fear of being laid off. As for the yummy yummy scripts each engineer is creating, I created a repo where they could add those scripts with a simple readme file; but unfortunately, I didn't get support for this from the manager so it was not taken seriously. Documentation needs to be part of policy and governance and not just during demos or presentations 😉

Thanks for the feedback ^^ This seems to match what most engineers have seen in other orgs as well. Did you ever discuss tooling like Mintlify (basically AI monitors your codebase and updates docs automatically) when pushing for more docs? Or was that not around at the time/not on the radar? I'd be making something similar to that but still with some manual work as you'd still have to take the time to at least write some raw notes like clicked here, filled in that, ... and to push that to the application, with that then handling the part of updating the KB with new pages (including formatting and expanding on the notes), updating existing pages and marking pages as ready to archive. Do you think such a tool would help the push for more documentation? Is it something you'd use a team's budget on?

Good questions "Or was that not around at the time/not on the radar?" • Such solutions were not there yet at the last 2 employers I worked with (2025). Many organizations are still in the AI adoption stage and results on the ground are mixed. "Do you think such a tool would help the push for more documentation? Is it something you'd use a team's budget on?" • When it comes to internal documentation, there is a lot of friction. The root cause of the frictions comes from nowadays Dev's mindset and corporatism. A lot of people in the Dev community think that only coding matters and some of them think that if you can't understand the application by hacking it, then you're not "Good" enough. This unfortunately became the standard or the new norm because many leaders avoid getting involved. At the corporate level, competition became too heated (especially today) that Devs joining a new team are expected to either swim or sink. • For me, as a consultant, if a client asked me for advise on governance and controls, I'd definitely push documentation and recommend such tools; Overall, the friction for internal documentation is mainly due to corporate culture and this is why such issues need to be thought of by the leaders instead of relying on Dev teams to push for it. I'd say if you spoke to a leader who is all in on "AI", they will be interested in learning about it but if the lower level managers are stuck on coding first, they might push back against to save the company few bucks 🙂

Hmm that confirms my fear that indeed documentation is not really a matter of having the right tools but rather having the right metrics to understand the value of documentation. That said, there are engineers teamleads and consultants such as yourself that push for better documentation and who can use such tools to reduce the cost of writing documentation. Thanks a lot for your insights, they really help a lot with bringing another perspective. I'm going to take this into consideration for further development of my tool, more as an enabler for those that are pushing docs and less off a general "this wilm fix your docs situation" type of tool. If there's anything I can do in return please let me know!

Thank you. Always happy to share any insights or thoughts!