Is AI the key to improving DevOps, or is AIOps being overhyped?

In an age where automation and AI are reshaping the tech landscape, the promise of artificial intelligence improving DevOps seems almost inevitable. But does AI truly hold the key to advancing DevOps or is the concept of AIOps being overhyped?

David Buchalter ??? is a solution-focused senior engineering leader with a genuine passion for leadership and empowering people. His experience spans the full cycle of delivery, from concept to testing and deployment.

Throughout our conversation David spoke about the the nuances of DevOps vs SRE vs Platform Engineering, the evolution of DevOps, and where AI could (and could not) fit into the picture.

Defining DevOps, SRE, and Platform Engineering

DevOps is about breaking down the Chinese wall between development and operations teams.

It’s a collaborative approach where teams work together to bring operations concerns, like scalability and security, to the forefront of the development process.

In DevOps you’re shifting left on non-functional requirements - scalability, security, efficiency - things the customer didn’t ask for but expects.

DevOps ensures that engineers consider performance and resilience early in the coding process, an idea often referred to as “shifting left.”

Platform Engineering, on the other hand, focuses on creating standardised, repeatable environments.

Platform engineering is about providing an environment where the code can run safely, securely, and at scale.

This involves setting up development, test, and production environments that developers can rely on to be consistent and secure. A significant part of this work is treating the platform as a product, making it easy for developers to use.

The goal is platform as a product, where developers press a button and have the resources they need without worrying about the underlying infrastructure.

Finally, SRE takes a metrics-driven approach to maintain system reliability and performance.

SRE is about monitoring uptime, service-level objectives, and response times.

SRE teams use data to anticipate and address issues before they affect the end user, often by setting up alert systems that notify them of performance dips or security incidents.

It’s like driving a car - you need to know if your engine’s overheating so you can pull over and fix it before things get worse.

Platform as a Product

As platform engineering has evolved, so too has the concept of 'platform as a product'. Platforms are no longer simply environments where code runs; they’re tailored tools designed to help developers focus on coding without worrying about infrastructure.

David pointed to Humanitec as a company leading the charge in making this vision a reality.

Humanitec is building platforms with the view that the platform is a product that developers can consume seamlessly.

The goal is a user-friendly system where developers can, in David's words, be like "kids in a candy shop," choosing resources from a well-defined menu without needing deep DevOps knowledge. This aligns with the movement toward NoOps or CodeOps, where platforms handle deployment and operational concerns automatically. David explained that in a NoOps environment, you don’t need the DevOps expertise because all the considerations like scalability, security and efficiency have been built into the system. For organisations aiming for high agility and speed, NoOps provides a streamlined path to production, freeing developers to focus on business logic and product features rather than infrastructure.

Who is David?

David’s journey from biomedical engineering to software development, and now to engineering management, has been one of transformation, shaped by both technical expertise and personal growth. His career began at companies like IBM and Meditech, where he built a strong foundation in software development, problem-solving, and delivering reliable solutions in the healthcare sector. These early roles highlighted the importance of precision, quality, and the impact technology can have on people's lives.

As David’s career progressed, he sought to contribute beyond technical work, focusing on collaboration, mentorship, and technical leadership to drive broader impact. A pivotal moment came with his move from South Africa to the UK - a shift that not only marked a new chapter for his family but also saw him transition from software developer to engineering manager. This shift allowed him to expand his role from software creation to guiding teams and shaping strategic outcomes.

David’s first formal leadership role came at Untied, a startup focused on personal tax automation where he stepped into engineering management. Combining his technical insights with mentorship, he realised how guiding others in both technical skills and professional growth could strengthen teams and elevate organisational success. At Liberis, a FinTech scale-up specialising in revenue-based finance, he refined his leadership approach further, scaling an engineering team from three contractors to a high-performing unit.

In his current role at One World GTM, a SaaS company dedicated to sustainable supply chains, David manages four teams - Quality Assurance, Platform Engineering, and two cross-functional, value-delivery teams - with over ten direct reports. Working alongside a principal engineer who leads on technical strategy, David’s responsibilities include driving technical best practices, strategic delivery, and fostering a collaborative, high-performance culture. His leadership approach integrates mentorship with technical direction, ensuring his teams deliver value-aligned solutions while growing their technical and professional skills.

Platform engineering requires constant attention to the individual’s career growth, skill development, and job satisfaction.

Throughout his career, David has observed how the demands on platform engineering have evolved with changes in DevOps and SRE practices. With experience reviewing and interviewing over 100 platform engineers, he has gained a unique perspective on the skills and qualities essential for success in these roles. His hiring process often explores candidates’ perspectives on the distinctions between DevOps, SRE, and platform engineering, revealing how they view their contributions within an organisation.

One engineer I interviewed said he saw them all as one big DevOps role.

David has found that many candidates and organisations blur the lines between DevOps, SRE, and platform engineering. This ambiguity can cause friction, especially when companies label roles like platform engineering but treat them as traditional operations positions. Such nuances impact team collaboration and the effectiveness of DevOps and platform engineering principles.

A theme throughout David’s career is the use of technology to make a positive impact. From healthcare software to personal finance automation, and now sustainable supply chains, his work is driven by a commitment to creating solutions that benefit organisations and society.

How Has Hiring for DevOps Changed Over the Past Five Years?

David feels that hiring for DevOps has shifted significantly over the past five years, and the approach largely depends on the organisation's size and resources. For instance, many startups need engineers who can wear multiple hats - taking on DevOps, platform engineering, and SRE responsibilities as needed.

It's common for start-ups to look for someone who can step into DevOps, platform, and SRE - a melting pot...someone who can just put on the different hats as and when they need to.

In larger corporations like Google, however, the workforce scale allows for dedicated SRE teams with narrowly defined roles. This difference shows us the varied expectations across company sizes; startups need agile, versatile engineers who can switch tasks based on immediate needs, whereas larger companies can afford specialised roles focused on specific areas.

At the end of the day, the customer doesn’t really care what you call it...Can we generate revenue? Did we make the sale? Is the customer happy?

For David, the terminology is secondary to functionality: as long as engineers can deliver reliable products on time, the title they hold is less relevant. In his view, tech roles can be branded and hyped in various ways, but the core goal is to meet performance expectations, whether it’s building a system or delivering a service.

Whether you're building a Toyota or a Formula One car, you need different requirements, different teams, and different skills...It’s all about what performance you expect from it.

Whether you’re building a regular car or a high-performance sports car, the skills and focus required will vary. If you're making a Toyota, you need engineers who prioritise reliability and affordability. But if you're creating a Formula One car, you require specialists focused on speed and high performance. Each context demands different skill sets and specialisations, just as startups and tech giants have unique hiring needs.

What Are the Measurable Benefits When DevOps is Done Right?

David referenced a real-world DevOps project he led at Liberis, where they integrated a “click-to-sign” feature within a customer onboarding journey. The goal was to streamline contract signing, a process traditionally handled via external links like Adobe Sign or DocuSign, by embedding it directly into the platform’s workflow. With this new setup, customers seeking funding could review, sign, and finalise their contracts all in one place, reducing friction and speeding up the onboarding experience.

David’s team owned the click-to-sign part of the journey, but their work required close coordination with the DevOps team to meet tight deadlines and ensure security compliance. Despite some knowledge gaps between teams, they bridged them through strong communication and a clear feedback loop, which was essential in preventing bottlenecks and avoiding typical silos.

Ideal is communicating, making sure you’re not operating in silos and minimising risks through that communication.

David admitted that while it wasn’t a perfect setup, they made it work by continuously aligning on requirements. He found that ensuring everyone knew what’s expected of them was critical for delivering the final product on time. They monitored the application through tools like Mixpanel, which helped track user interactions and spot any recurring errors. This setup also allowed the team to collect insights about user behaviour, enabling them to make small but impactful tweaks to improve the experience.

While the Mixpanel metrics were more front-end focused, David saw them as crucial for guiding backend improvements as well.

You have those hooks in your front end that link back...if things go wrong, you can refine your application and improve it.

The take-away here is that DevOps success wasn’t about reaching a flawless state but about maintaining open lines of communication, tackling problems together, and continuously refining based on what they learned along the way.

So, Is AI the Key to Improving DevOps, Or Is It Being Overhyped?

We finish our chat by weighing in on the role of AI in DevOps, with David emphasising that while it offers valuable enhancements, it’s not a substitute for expert human judgment. He sees AI as a tool that can 10X productivity but cautions against full reliance on it. For David, AI is useful for boosting output and improving workflows, but only when combined with oversight.

It’s going to improve your output, it’s going to improve your performance, but you still need to have that oversight to know when something is wrong.

David gave an example of using tools like GitHub Copilot and Cursor, which have AI capabilities for code improvement, but he’s found they still make mistakes. That’s why he believes it’s essential to have experienced engineers who can understand when AI’s suggestions are accurate and when they need intervention. For him, the best results come when AI serves as an enhancer of expertise rather than a replacement.

In his view, AI will undoubtedly evolve how we work, adding speed and efficiency to DevOps processes, but it requires a critical eye and an understanding of its limitations.

As he put it, it’s all about using it with a level of scepticism, knowing the risks and ensuring that if AI does encounter a problem, the alarms will go off and immediate action will follow.

So while AI isn’t a magic bullet, he sees it as a game-changer for teams that use it strategically.