Vi.Tech and Shturval examined what remains of DevOps after the hype and where AI is useful

DevOps went through a phase of loud promises and debates about terminology, but didn't disappear from engineering practice. In an analysis from SRE at Vi.Tech Dmitry Sinyavsky and the "Shturval" platform team, the main conclusion sounds simple: labels change, but working principles remain.

DevOps Without a Funeral

The authors suggest looking at DevOps not as a trendy word, but as a set of disciplines without which modern development begins to stall. Shared responsibility for production, infrastructure as code, observability, fast release cycles, and clear incident processes haven't gone anywhere. Against this backdrop, talks that DevOps "died" look more like a dispute over a sign.

Platform engineering in this logic doesn't cancel DevOps but packages it into a more convenient internal service for teams. An important point here is that business needs not a title on a business card, but predictable delivery of changes. If a platform helps developers deploy faster, change configs more safely, and spend less time on manual environment setup, it continues the same engineering line.

So the dispute between DevOps and platform engineering makes sense only as long as it doesn't prevent the team from delivering products more stably.

Automation with a Downside

The most unpleasant but honest thesis in the material—automation can indeed weaken an engineer if it turns infrastructure into a black box. When pipelines, deployment, and recovery from failures are hidden behind scripts and buttons, the team wins in speed. But along with this, people gradually lose the skill to understand the system at a lower level, which means dependence on ready-made scenarios grows. This is especially painful to see during rare but complex outages.

"Automation makes you weaker."

This phrase is not about rejecting automation, but about its price. The problem shows itself the moment the abstraction breaks: CI hangs in an unexpected place, the network behaves off-pattern, a cloud limit suddenly hits the ceiling, and the familiar button no longer helps. If an engineer hasn't done this path manually before, diagnostic and recovery time increases sharply. The practical conclusion: you need to automate routine work, but at the same time preserve understanding of how everything is arranged under the hood.

Where AI Is Useful

In this picture, AI gets not the role of "autopilot for DevOps" but the role of accelerator for humans. It works well where you need to quickly parse a large volume of text, suggest a starting solution, or help assemble a draft artifact. But handing the model responsibility for production without verification is dangerous: it doesn't have full context of the system, the history of compromises, and a sense of the cost of mistakes. So AI is better understood as a first-pass tool, not a final decision maker.

• Summarization of logs and alerts before incident investigation
• Drafts of CI/CD configs, Terraform modules, and runbooks
• Search across internal documentation and explanation of legacy connections
• Initial pull request review for obvious risks
• Preparation of postmortems, changelogs, and technical descriptions

The key limitation is simple: AI is useful only where an engineer can quickly verify the result and take responsibility for the decision. If a team starts replacing understanding of the system with beautiful model answers, it gets the same problem as with excessive automation, just in a new interface. So the place of AI in engineering today is alongside humans, not instead of them. The working scheme is narrow permissions, mandatory review, and clear responsibility zones.

What This Means

After the hype faded, DevOps turned out to be not a dead concept but a working foundation for platform engineering, automation, and AI tools. The teams that win are not those who loudest change terminology, but those who can accelerate delivery without losing engineering depth and system control. For team leads, this is a signal to build processes so that speed isn't bought at the cost of degraded expertise. This is what distinguishes mature engineering from a collection of trendy tools.