Ask an infrastructure team what their worst week looks like and you will hear about alert storms, a migration nobody has budget for, and a ticket queue that never empties. None of those problems are intellectual. They are volume problems, and volume is exactly what machines handle well.
That is why AI for IT operations has moved from conference talk to budget line faster than most enterprise technology. It attacks the repetitive middle of the work: correlating alerts, triaging tickets, writing the boring half of a migration, drafting runbooks and summarising an incident timeline while it is still unfolding. What it does not do is remove the need for judgement, and the teams that assume otherwise tend to discover it during an outage.
At iSpark we work with IT and engineering leaders who are under pressure to show AI results quickly without destabilising a production estate. This article sets out where AIOps for enterprises genuinely helps, a documented example from a US company that published its own numbers, the mistakes that create risk rather than reduce it, a checklist you can use immediately, and a realistic order of operations for getting started.
What AI Actually Changes in IT Operations
The useful mental model is that AI moves bottlenecks rather than removing them. Coding assistance is the clearest case. Generating code is now cheap, which means review capacity becomes the constraint almost immediately. Teams that add assistance without expanding review discipline simply produce a larger backlog of unreviewed change.
The same pattern holds in operations. Alert correlation reduces noise, which moves the constraint to whether your asset and dependency data is accurate enough for the correlation to mean anything. Automated remediation shortens response, which moves the constraint to whether your rollback path has ever been tested. In our work on AI for IT and engineering teams the first step is almost always instrumenting current flow, because you cannot see a bottleneck move if you never measured where it was.
Where AI Driven IT Management Earns Its Place
| Use case | What AI contributes | The constraint it exposes |
|---|---|---|
| Alert correlation | Grouping related signals into single incidents | Accuracy of asset and dependency data |
| Ticket triage and routing | Classification and assignment in seconds | Quality of your service catalogue |
| Incident summarisation | Timelines and draft reports during an incident | Every summary still needs verification |
| Code migration and refactoring | Bulk mechanical change at scale | Review and test coverage capacity |
| Capacity and failure prediction | Early warning before impact | Whether anyone acts on the warning |
| Runbook and documentation drafting | First drafts from real system behaviour | Ownership of accuracy |
Bulk code change deserves particular attention, because it is the one area where the results published by real engineering teams are dramatic rather than marginal. The industry direction is visible in product terms too, with Microsoft’s GitHub Copilot coding agent designed to pick up refactoring, test coverage and defect work asynchronously rather than line by line.
A Real Example: Airbnb’s Test Migration
The challenge. Airbnb had nearly 3,500 React component test files written in Enzyme, a framework the company had used since 2015 and had stopped writing new tests in. Deleting them would have left serious gaps in code coverage. Converting them by hand was estimated at around 1.5 years of engineering time, which meant it was never going to be funded.
The solution and implementation. Airbnb built a pipeline rather than a prompt. The migration was broken into discrete per file steps that could run in parallel, with configurable retry loops and expanded context in the prompts. An early hackathon had shown the approach worked on hundreds of files, and the production version added automated validation, status stamping on each file so failures were visible, and breadth first tuning for the long tail of complex cases.
The outcome. The team reported reaching roughly 75 percent completion quickly, then doing considerably more work to get to 97 percent. The remaining 3 percent were fixed manually, using the failed automated attempts as a starting point, in about another week. The whole migration finished in six weeks.
The business impact. Test intent and code coverage were preserved, which was the actual requirement. Airbnb also reported that total cost, including model usage and six weeks of engineering time, came in well below the manual estimate. The honest detail worth copying is that the team decided chasing 100 percent was not worth the return, and stopped.
Common Mistakes in AI IT Automation
- Adding code generation without adding review capacity, so unreviewed change piles up.
- Reducing alert volume by raising thresholds and reporting it as an improvement.
- Granting write access to automation before a rollback path has been tested.
- Building correlation on top of a configuration database nobody trusts.
- Treating an AI generated incident report as a record without a human verifying it.
- Measuring tickets closed rather than repeat incidents and change failure rate.
Best Practices Checklist
- Instrument current flow first, including queue times, not just resolution times.
- Run any new automation in observe only mode for at least one full cycle.
- Keep a tested manual override owned by a named person, exercised before go live.
- Expand review and test standards at the same time as generation capacity.
- Track change failure rate alongside speed. Faster with more failures is not progress.
- Decide in advance what level of completion is good enough, as Airbnb did.
How to Get Started
- Pick a bounded, mechanical job with a clear pass or fail test, such as a migration.
- Record the current estimate and the current baseline metrics honestly.
- Build a pipeline with retries and visible per item status, not a single large prompt.
- Accept partial automation. Manual cleanup of a stubborn tail is usually cheaper than perfect tooling.
- Only after that, move toward operational automation with reversible actions first.
Future Trends in AI for DevOps
Three developments look durable. Asynchronous coding agents are becoming normal parts of the pull request workflow rather than editor features. Agent governance is emerging as its own discipline, because an estate running dozens of agents needs a control plane, audit trail and permission model. And the caution is real: Gartner has predicted that more than 40 percent of agentic AI projects will be cancelled by the end of 2027, largely over cost, unclear value and weak risk controls.
Key Takeaways
- AI moves bottlenecks rather than removing them. Generation gets cheap, review does not.
- Bulk mechanical change is where published results are strongest, as Airbnb’s six week migration shows.
- Correlation and remediation are only as good as your asset and dependency data.
- Decide what good enough looks like before you start, then stop there.
Frequently Asked Questions
What is AI for IT operations in practice?
It is applying models to high volume operational work such as alert correlation, ticket triage, bulk code change and incident summarisation, with humans retaining judgement and accountability.
Is AIOps for enterprises only worth it at large scale?
Scale helps, but the deciding factor is repetition. Any team with high alert volume or a stalled migration can see value without enterprise size.
Should we let AI resolve incidents automatically?
Only for reversible actions, and only after a tested rollback path exists with a named owner. Anything affecting the wider estate needs human approval.
Does AI coding assistance actually reduce engineering cost?
It reduces time on mechanical work. Net savings depend on whether your review, testing and deployment processes can absorb the increased volume of change.
What should we measure?
Queue time, change failure rate and repeat incident rate. Tickets closed and lines generated tell you almost nothing useful about operational health.
Where to Take This Next
The teams getting real value from AI infrastructure management are not the ones with the most tooling. They are the ones that measured their flow first, picked a job with a clear pass or fail test, and expanded review discipline at the same rate as generation capacity. That order matters more than the choice of platform.
If you want a clear view of which part of your operations would benefit and which would only add risk, iSpark runs fixed scope reviews of engineering and operations workflows that end with a written recommendation either way. Bring your current queue and incident metrics and start there.
Published by iSpark.
