Operations | Monitoring | ITSM | DevOps | Cloud

For longer than I’m proud of, I was an AI skeptic. Then, over the holidays, I vibe coded an app whose sole purpose was to make me a better person. The app is a motivator. It’s programmed to send me timely reminders along certain themes, like reading every day, making healthy eating choices, and giving myself plenty of time to plan for anniversaries and birthdays.

Writing code is moving from the good old IDE into the realm of autonomous AI agents. One example of this is OpenAI, which has been developing internally with 0 lines of manually written code. You can read about their workflow in their engineering blog: Harness engineering: leveraging Codex in an agent-first world. For me, the main takeaway of OpenAI’s article is how AI has rewritten the constraints equation.

Tech headlines are being dominated by the perfect storm that has led to a global shortage of Random Access Memory (RAM). As the short-term, temporary memory that handles data for processing and applications, RAM – and specifically Dynamic Random Access Memory (DRAM) – is a foundational business technology. The primary driver of this shortage is an industry-wide shift to High-Bandwidth Memory (HBM). This is the specialised memory required for artificial intelligence (AI).

Internal platform adoption usually doesn’t fail because developers “hate standards.” It fails because the platform doesn’t make their day easier. If your portal still means waiting, waiting on an environment, waiting on an approval, waiting on the platform team, it becomes one more tab that people stop opening. But if the platform lets engineers get the common stuff done quickly (with guardrails that keep things consistent), they’ll come back on their own.

Most engineering teams know the difference between “we have tests” and “we know we’re well-tested.” Your CI builds may be green, but without code coverage, it’s hard to prove how much of your code is actually exercised by automated tests. Code coverage measures what percentage of your code runs during tests (lines, branches, and functions), and when you wire it into CI gates, it becomes an enforceable quality signal and not a vanity metric.

At SREday NYC 2026, the ShipTalk podcast welcomed Birol Yildiz, Co-founder and CEO of ilert, for a conversation about the next evolution of incident response. In the episode, ShipTalk host Dewan Ahmed, Principal Developer Advocate at Harness, spoke with Birol about how artificial intelligence is transforming reliability engineering—from simply assisting engineers during incidents to autonomously diagnosing and resolving outages.

A DevOps pipeline is a critical part of modern software delivery. It is a series of automated steps that move code from commit to production quickly, reliably, and consistently. At its core, a DevOps pipeline is a system that helps teams build, test, and release apps in an easier way. It cuts down on manual work and mistakes. This helps teams send out updates more often, make better software, and react quickly when the business needs change.

This is a guest post from Stephanie Herr. If your team uses GitHub Actions to ship application code, you've probably wished your database changes could move through the same pipeline just as smoothly. Today, that's easier than ever. We've launched verified Redgate Flyway GitHub Actions on the GitHub Marketplace, giving you a simple, reliable way to integrate database deployments into your existing GitHub workflows.

For seven years, I've watched the same pattern. An organization decides it needs a platform and assigns two of its best engineers. They estimate it will take three months, but eighteen months later, they're still integrating ArgoCD with their secrets manager, still debugging Crossplane providers, and still arguing about how to structure the GitOps repo. What’s happened is they’ve built something that works for one team and can't be repeated for a second.