I joined a company about four months ago and found an environment that mostly worked but had frequent unexplained outages, very little monitoring, and poor visibility. The existing monitoring was based on Icinga2, which I had never used before. Rather than replacing it immediately, I kept it and started managing the configuration through Git, Ansible, and deployment automation.
With extensive help from AI, I expanded monitoring to cover databases, service health, Active Directory and DNS, DHCP, NTP, pending reboots and security updates, event logs, and connectivity checks across Windows and Linux. The results have been genuinely useful, but the system has also become complex enough that I no longer fully understand every part of it. If a sensor stops working, I often need to research the issue, consult external support, or ask AI before I can troubleshoot it effectively.
This concern extends beyond monitoring. The company wants to implement IAM with Entra ID within nine months, and I am expected to automate much of it with Terraform. There are also plans involving Ansible patching, configuration and VM deployment, Grafana, Prometheus, and some Kubernetes responsibilities. I am currently the only senior person driving most of this work, while my colleagues have limited experience with Linux, YAML, VS Code, and infrastructure-as-code.
The automation is improving stability, standardization, patching, and security, and I am learning a lot. However, I worry that I am becoming dependent on AI and that the whole platform would be difficult for anyone else to maintain if I left. I document configurations and maintain handbooks, service guides, explanations, and troubleshooting notes, but keeping up with the documentation and learning everything properly is difficult alongside the rest of my workload.
How can I keep using AI productively without losing the understanding needed to operate and troubleshoot the systems I am building? How should I manage the risk of becoming the single point of failure for this growing infrastructure stack?
3 Answers
This sounds primarily like a capacity and ownership problem, not an AI problem. You have gone from poorly managed monitoring to owning Icinga, Ansible, Terraform, Entra, dashboards, patching, deployments, and parts of Kubernetes while still being the only senior person. No one can keep all of that in their head or safely support it alone.
AI can help you move faster, but management still needs to understand the operational risk. Make the dependency visible: document what systems you own, what happens if you are unavailable, which tasks have no backup, and how much time is required to maintain them. That gives the staffing discussion a concrete business and resilience angle rather than making it sound like a personal concern.
Keep using AI, but make understanding and review part of the workflow. Instead of asking it for a complete magic file, require it to explain the design, assumptions, risks, dependencies, failure modes, and maintenance procedure. Review the result, test it in a safe environment, and make sure you could describe how to recover if it fails.
For the systems already built, use AI to generate maintenance guides, architecture summaries, dependency maps, troubleshooting exercises, and runbooks from the actual code and configuration. You can also have it act as a course instructor and quiz you on the technologies you need to operate. That turns AI from an opaque replacement for your knowledge into a learning and documentation tool.
The documentation you are already creating is a strong foundation. The important part is making sure it is accurate, tested, easy for someone else to follow, and actually used by your colleagues.
That is mostly how I work already. Configurations contain explanations, and I maintain general and service-specific handbooks with setup details, commands, references, and troubleshooting notes. I also use AI to turn reliable technical sources into readable study documents. Building structured training courses and exercises for myself and my colleagues is the next useful step.
Treat the infrastructure as a reproducible system rather than a collection of commands you personally remember. Keep the source of truth in version control, use pull requests and peer review where possible, add validation and testing, and make rollback straightforward. Record the intended end state, not just the steps used to reach it.
This approach helps with disaster recovery, configuration drift, monitoring coverage, and standard operating environments. Manual commands are still useful when investigating something new, but once the process is understood, capture it in automation and test that the automation really recreates the expected result. Good automation reduces dependence on your memory, but it does not remove the need for clear ownership, review, and operational training.
That is increasingly how I operate. Most configuration now lives in Git and is deployed rather than entered manually, so reverting a bad change is easy. I still document unusual installation steps, and AI helps create much of the supporting material, but I review and refine it before using it. Some of the resulting automation, such as certificate-based WinRM binding and automated certificate renewal checks, has already proven reliable.
I have raised this several times. I do have two colleagues who are supposed to get involved, but they are not very interested in DevOps or Linux and only recently started using tools like VS Code and YAML. I am trying to move the work forward because it is valuable and I want to keep the job, but right now the whole stack depends on me—and without AI, I would struggle to keep up with it myself.