Skip to main content

Posts

Red Hat Previews AI Agent Integration with Ansible Automation Platform

Red Hat today revealed it is extending the reach of its Ansible Automation Platform for IT operations to artificial intelligence (AI) agents, in addition to making it simpler to build AI agents using existing application development tools. Announced at the Red Hat Summit conference, version 2.7 of the Ansible Automation Platform adds a technology preview of an orchestration engine for AI agents that are able to invoke capabilities via an integrated Model Context Protocol (MCP) server. Sathish Balakrishnan, vice president and general manager for Ansible at Red Hat, said these capabilities provide AI agents with a trusted execution layer through which they can automate IT operations. The overall goal is to make new and existing libraries of automation playbooks available to AI agents in a way that can be governed using a set of policies enforced via the Red Hat Ansible Automation Platform, he added. As part of that effort, the Red Hat Ansible Automation Platform can now serve as an ...
Recent posts

The Five Biggest Mistakes Organizations Make When Implementing SRE 

Site reliability engineering (SRE) promised a better way. Born at Google and evangelized by a generation of platform engineers, SRE offered organizations a disciplined, engineering-first path from firefighting chaos to measured, sustainable operations. However, years into the mainstream adoption of SRE, various organizations find themselves spending more on SRE tooling than ever, while their on-call engineers are still drowning at 2 a.m.   The pattern is consistent. Titles change. Dashboards multiply. AI-powered AIOps platforms get procured. Error budgets get defined in a spreadsheet and promptly forgotten. Six months later, the postmortems look identical to those from two years ago.   What’s going wrong? After surveying dozens of engineering organizations, five mistakes surface repeatedly, and they compound each other in ways that are hard to untangle once they’re entrenched.   Renaming your ops team ‘SRE’ without changing how work gets done is the organizat...

Continuous Security in DevSecOps: Moving Beyond One-Time Testing 

Waiting for a single annual pentest to secure your application is like locking your front door only once a year and hoping for the best. In an era where  133 new vulnerabilities  are reported every single day, relying on periodic snapshots leaves your organization exposed to evolving threats for months at a time.   This approach is no longer just risky; it is a significant financial liability. Data from the  IBM Systems Science Institute  highlights that fixing a bug in production costs 100 times more than catching it during the initial design phase. For modern teams, the ‘window of vulnerability’ between tests is where attackers find their greatest opportunities.   Transitioning to continuous security in DevSecOps is the only way to close this gap. By embedding automated validation into your CI/CD pipeline, you move from a reactive ‘checkbox’ mentality to a proactive, resilient posture. This guide explores how to move beyond one-time testing to build a defense that evolves as fast a...

Why Senior Engineers Still Do Manual Work in Highly Automated Environments

Automation has been part of enterprise IT for many years, and in many environments, it has grown into an extensive network of interdependent workflows that keep routine operations running smoothly. Scripts provision accounts, automated workflows manage cloud resources, orchestration tools coordinate ITSM processes, and AI-driven tools help employees across the organization complete tasks more efficiently. On paper, this level of automation should allow the most experienced engineers to spend less time on routine operational work and more time on architecture, optimization, and long-term improvements. In practice, however, many teams experience the opposite. Even in highly automated environments, senior engineers are frequently pulled back into day-to-day operational tasks. They are asked to rerun failed jobs, correct permissions, verify provisioning results, or investigate why an automated workflow behaved differently than expected. Instead of focusing on higher-value work, they bec...

Open Source Contribution is About More Than Just Altruism 

Open source software is a foundational pillar of modern technology. From operating systems and databases to cloud infrastructure and developer tooling, it is embedded across nearly every layer of the stack. Most organizations rely on it in meaningful ways, often without fully accounting for how central it has become to their ability to build, scale, and operate And yet, for all its ubiquity, contribution to open source remains uneven. Many organizations still treat open source as something to consume rather than something to participate in. It is pulled into internal systems, adapted, and relied upon, but the relationship often stops there. A  new   report by the Linux Foundation   found that 28% of organizations say they use but do not contribute to open source software at all—that’s over a quarter of all organizations that are not contributing whatsoever. And for those who do, the degree to which they contribute may vary significantly.   Within the open source world, that dynamic ...

GitHub’s Spec Kit Puts the Spec Back in Software Development

If you’ve spent any time working with AI coding agents, you know the routine. You describe what you want. The agent generates code that looks right. You run it. It breaks — or worse, it works but solves the wrong problem. This frustrating pattern has earned a name: Vibe coding . You give the AI a vague idea and hope it guesses correctly. For quick prototypes, that’s fine. For production software, it’s a real problem. GitHub’s answer is Spec Kit — a new open-source toolkit for spec-driven development that provides a structured process to bring spec-driven development to your coding agent workflows with tools including GitHub Copilot, Claude Code, and Gemini CLI. The core idea is simple: Write the spec first. Specs as the Source of Truth For decades, code has been king. Specifications served code — they were the scaffolding we built and then discarded once the “real work” of coding began. We wrote PRDs to guide development, created design docs to i...