Enterprise DevOps teams have adopted AI faster than they have adapted the operational systems that support it. Large language models generate Infrastructure as Code, deployment pipelines, and configuration files in seconds.
Development teams are delivering infrastructure changes at a pace that would have been implausible five years ago. Production environments have simultaneously become harder to reproduce, more difficult to govern, and more expensive to operate.
The problem is easy to miss at first, because AI looks like a clear win in the early stages. A team asks an AI tool to set up some infrastructure. It works. The team expands how much they rely on it. More teams follow. More infrastructure gets created for testing, demos, experiments, and development. The organization ends up with far more moving parts than it had before, but far less ability to track them.
Latest Videos FromTechRadar
Not the full picture
The tools generating this infrastructure are good at describing what something should look like at the moment it’s created. They’re not built to watch what happens to it afterward, decide whether it’s safe to make another change while one is already in progress, or notice when something has quietly drifted out of its intended state over the following weeks.
That kind of oversight used to come from experienced operations people making changes one at a time, in a predictable order, with a clear sense of what else was happening around them. AI removed the slow part of that process without replacing the judgment that made it manageable.
Now there are multiple people and multiple AI tools all making changes to the same systems around the same time, each one doing its job correctly in isolation, none of them able to see the full picture of what’s happening across the environment as a whole.
The result looks familiar to anyone running infrastructure today. Environments that worked perfectly last week suddenly don’t, and nobody can say exactly why. Cloud costs creep up steadily because nobody remembered to shut something down once it was no longer needed. Teams spend real, billable hours figuring out why two environments that were supposed to be identical have quietly diverged.
Security settings that were correct at launch slowly fall out of sync as everything around them keeps evolving independently. None of these are dramatic failures on their own. They’re slow leaks, and slow leaks are much harder to notice and much more expensive to fix than sudden breaks.
Too much fragmentation
The teams responsible for infrastructure have been adjusting to this reality in real time. A few years ago, their main job was making things easy for developers, such as removing friction, giving people self-service access to what they needed, getting out of the way. That’s still part of the job, but the role has expanded considerably.
Now they’re expected to enforce rules across the organization, manage costs on increasingly expensive compute, track what’s actually running where, and keep things consistent across a far more complicated set of environments than existed even two or three years ago. Bolting on another automated tool to handle some piece of that doesn’t solve the underlying issue.
More often than not, it just adds another piece to a pile that’s already too fragmented to manage well.
An environment isn’t just the infrastructure sitting inside it. It’s also everything connected to that infrastructure: who has access to what, what depends on what else, how much it actually costs to keep running, and how long it’s supposed to stick around before someone should be cleaning it up.
Getting ahead of problems means building that kind of awareness directly into how infrastructure gets deployed and maintained, rather than discovering issues after the fact through documentation nobody reads regularly or incidents nobody wanted to have in the first place.
Processes should be built in
This becomes even more important as companies pour money into AI-specific hardware. Setting up GPU-powered environments isn’t simply a matter of securing the hardware, it requires everything around that hardware, including networking, storage, security, and software, to come together correctly and stay that way.
Having the hardware on hand doesn’t make that coordination problem any smaller. Only better processes do, and that process has to be built deliberately rather than assembled from whatever tools happened to be lying around.
The questions worth asking have changed as a result, even if a lot of organizations haven’t caught up to that yet. How fast a team can generate infrastructure isn’t the most useful thing to measure anymore and it was never really the hard part.
A better gauge is whether environments stay consistent over time, how often things drift without anyone noticing, how long unused environments sit around quietly costing money, and whether anyone in the organization can actually describe with confidence what’s running in production at any given moment.
The companies that get the most lasting value out of AI won’t necessarily be the ones using the most advanced or most numerous tools.
They’ll be the ones that put just as much disciplined effort into managing what AI produces as they did into producing it in the first place and treating governance not as an afterthought, but as the thing that determines whether all that speed actually turns into something worth having.
We’ve featured the best laptop for programming.
This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.
The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit
https://cdn.mos.cms.futurecdn.net/qP76MS2BAb7kSuWrvJXXYL-2560-80.jpg
Source link
