I am old enough to remember when people questioned whether Google Cloud even had a future within Alphabet. Well now we have a pretty clear answer – yes. I originally began this post as a quick roundup of news from Google Next 2026, but given Google’s results dropped the following week, let’s look at them first.

In the first quarter, Google Cloud revenue jumped 63%, year over year, to $20 billion, in the parlance of the day – absolutely crushing it. To the moon, etc. Growth rates like that on an already hyperscale business is quite something. Google Cloud now accounts for 18% of Alphabet’s total revenue. Which is to say, it’s a keeper.

Sundar Pichai, Google CEO said:

“Google Cloud is differentiated because we are the only provider to offer first-party solutions across the entire enterprise. Our growth in revenue, operating margin and backlog highlights this differentiation.”

AWS and Azure also had excellent quarters, but Google’s growth, even though from a lower base, was still a clear marker of substantial progress. I often say the best packager in any tech wave wins and wins big, and Google is looking increasingly well positioned. Packaging and integration go together hand in hand – you want an offering that makes things easy for the customer, reducing cognitive and organisational overheads. But packaging and economies of scale are also closely entwined – Google is well placed here because it owns technology up and down the stack.

Google also really pushed its position as a “full stack” AI infrastructure provider- it has technology leadership that spans from custom silicon to productivity apps, and unlike Microsoft and AWS it has its own capable frontier model in the shape of Gemini.

It is agents and harnesses however that are really going to drive model growth.

The agent platform

At Cloud Next Google announced tools for agent management and orchestration, and demonstrated continuing strength and depth in data infrastructure. It also apparently reintroduced Knowledge Management as an enterprise concern for the AI era.

The agent story is on point because, frankly, agents are finally capable enough to do some real work (on their own). Developers noticed a step change in coding agents around the turn of the year, arguably as big a leap forward for AI capabilities as the launch of ChatGPT in November 2022.

You just have to use the tools to see the clear difference in capability, or listen to AI-savvy developers across the industry. We’re in a fundamentally different environment now – the code being generated now is of a much higher quality, and with agents, an entirely new degree of autonomy.

Devs also began to better understand the value of brute force, and single task iterative loops (see the “Ralph Wiggum” pattern, invented and popularised by Geoff Huntley) in getting agents to do what they wanted. Harnesses are also becoming more effective, for example in providing consistent developer experiences as models evolve. If agents are getting this good at building and deploying software, other business processes are also going to be affected. The infrastructure we rely on just wasn’t built with agents and models in mind though – scale, security and management challenges are all massively increasing.

Google introduced Gemini Enterprise Agent Platform, building on and replacing its Vertex AI platform, with new features in its Agent Development Kit, scale and memory improvements for its Agent Runtime, but most importantly from a manageability perspective – Agent Identity, Agent Registry, and Agent Gateway. The central idea of Agent Identity is that you can assign every AI agent a unique cryptographic identity. Google also announced Agent Simulation, Agent Evaluation, and Agent Observability. Evals are as important to LLM apps as unit tests are to current software development. Observability is of course more important than ever, given we need to understand outputs and behaviours in production.

Google’s Dev Rel team did a solid job explaining how all of these tools play together in a demo during the developer keynote on day two – with a scenario of planning a marathon in Las Vegas. Each step in the development process was outlined and explained during the keynote.

For example a demo featuring Agent Studio – a collaborative workspace for building new agents. Key to the demo flow as whole was making it clear that different tools will be used by different personae, including “low code” developers using natural language, people living in markdown for specs, specs that cover business rules, not just software guardrails. Prebuilt agents include code modernisation, financial analysis, and deep research.

We’re going to see a lot more marketing around agent capability from platform providers as agents become more capable and widely deployed – indeed it’s pretty much the 2026 summer keynote.

The agent permission, security and identity play

With agents you have a bunch of autonomous systems using non-deterministic models to try and achieve outcomes. These agents are capable of taking action – sometimes very bad actions, such as deleting production databases. They absolutely need guardrails, and a markdown file just isn’t going to cut it. That’s where tools like Agent Identity come in. Permissions will need to be tightly managed. Role based access control (RBAC) will be essential for this agent buildout. But things are made even more challenging because most agents are ephemeral. RBAC systems were built for employees, and perhaps contractors, not agents you spin up and dispose of in minutes. New scale challenges everywhere you look.

Simon Willison coined the phrase the lethal trifecta:

• Access to your private data—one of the most common purposes of tools in the first place!
• Exposure to untrusted content—any mechanism by which text (or images) controlled by a malicious attacker could become available to your LLM
• The ability to externally communicate in a way that could be used to steal your data (I often call this “exfiltration” but I’m not confident that term is widely understood.)

“If your agent combines these three features, an attacker can easily trick it into accessing your private data and sending it to that attacker.”

Threats are growing all the time, partly because the tools are so powerful. Take OpenClaw, for example, designed as an AI personal assistant, arguably the fastest growing open source project in software history. OpenClaw reached 250,000 GitHub stars in about 60 days, surpassing React, which took over a decade to reach the same milestone. OpenClaw drove a spike in Mac mini sales as developers clamoured to use the software with a modicum of safety. The project went from launch to explosive growth to acquisition by OpenAI in about three months. Peter Steinberger, the lead developer, is now at the forefront of the movement to create agents that can do a range of tasks on behalf of the individual. For now it’s a developer play, but in the longer term it will be for enterprise users as well. It is a capable autonomous agent, built for messaging and integration to third party systems. But deploying it on your corporate network without a huge amount of supporting security infrastructure would be extremely foolish. It’s definitely not ready for the enterprise at this point. It’s simply too powerful as a lethal trifecta accelerant.

Agent sprawl drives the need for orchestration platforms

Orchestration platforms are increasingly a necessity because software developers are using teams of autonomous agents, sometimes working in parallel, but requiring asynchronous communication for handoffs and state management (memory) in the service of tasks and workflows.

This pattern reminds me of the evolution of containers and microservices. The container revolution began with devs running Docker locally on their laptop. As complexity compounded we needed an orchestration layer to manage all of these containers in production, which is how Kubernetes came into being. We’re now at a similar point with agents.

Agents as the primary driver of scale

Agents also drive much higher scale requirements. Look around the industry and you can see existing players and startups crushing it, or being crushed by, agent generated workloads. GitHub’s reliability issues are being exacerbated by agent-based software growth. There’s just so much software being built. Just look at Jarred Sumner of OpenAI, who just rewrote the entire Bun Javascript runtime in Rust, replacing the Zig implementation. One million lines of Rust code, all AI-generated. Regenerated is probably a better word than rewritten. Open Source projects are like Doctor Who now. Across the industry there are thousands of Sumners, also building huge code bases and new applications at an entirely new speed.

Token Economics and the Full AI Stack

Being an end to end stack player matters because it means you’re in control of costs of goods sold. You’re not reliant on third parties to serve customers, which is a clear economic advantage.

Control of cost is so important because the future of AI is going to be defined by token economics – that is, who can offer the greatest range of capabilities at the lowest cost. Anthropic and OpenAI are both going to raise prices in order to meet their sky high valuations. In recent months it’s become clear that the cheap token era is ending, even as some developers crow about “tokenmaxxing” as a badge of honour or productivity.

OpenAI and Anthropic need third parties to provide chips – NVIDIA. They also need cloud providers to provide compute, network and storage – business for the hyperscalers, as well as Coreweave and to some extent racle. Meanwhile AWS, Azure and GitHub are reliant on OpenAI and Anthropic (and their eye-watering balance sheets) to provide frontier models and associated services to their customers.

Owning a capable first party model is a crucial competitive advantage. At Next 2026 Google Cloud CEO Thomas Kurian announced that Google Gemini would be powering the next generation of Apple’s Siri service – see my post about it here. Gemini is now powering both Siri and AI services on Android phones worldwide — an almost incredible cloud win, given it covers most new phones being sold in the two key mobile ecosystems. Neither AWS nor Microsoft Azure could have won this deal given their reliance on third-party models.

What about the lower level stuff? Google has its TPU microprocessor architecture, which means that it’s not reliant on NVIDIA. AWS and Microsoft are investing in their own architectures optimised for model training. AWS will likely get there with Trainium, given the engineering process of its chip business – Graviton for general compute has been, and will continue to be, a huge differentiator for AWS as it seeks to lower the cost of compute for customers.

Google labelled its hardware advantage the AI Hypercomputer but we’ll largely stick to the agent story for the purposes of this post. It’s enough to say that AI is very specific in terms of compute patterns, and that’s why being in control of technology up and down the stack matters. And we haven’t even talked about the fact that Google Cloud also has a huge installed base of customers using its productivity tools. There is so much upside potential for integrations there.

But let’s cut to the chase. Enterprises are not going to take seriously the proposition that they should spend thousands of dollars per week per developer or agent. That’s not going to fly in Illinois, let alone Nairobi, Paris or Jakarta. I am old enough to remember enterprises balking at paying an extra $30 per calendar month per user for GitHub Copilot. So thousands of dollars per developer just seems unlikely at this point. Model choice is going to become more important, in this environment.

Data, Context and the new Knowledge Management

Data was the first business that Google Cloud landed in the enterprise, with companies making deep and strategic bets on Big Query, seeing Google as their “data cloud”. This beachhead is now increasingly realising gains in the AI space.

Google is world class at managing, and managed databases – Spanner is a globally distributed database offering near absolute transaction guarantees. It’s unique. It’s also increasingly appropriate for AI workloads, with multimodel capabilities including Spanner Graph, vector search and built-in full-text search. Google also offers Postgres in a couple of flavours, and Valkey for caching. You can have CloudSQL for MySQL if you’re looking for it, and for those so inclined of course you can get managed Oracle databases.

So what did Google announce at Next in the data space, to build on these strengths?

The key announcements were about what Google is calling the Agentic Data Cloud – key components of which are Knowledge Catalog, the cross-cloud Datalake, and the Agent Data Kit (meeting devs where they are, ensuring that Claude Code, Codex etc can do a solid job of accessing Google data services).

The Knowledge Catalog is essentially an AI-maintained index of all your enterprise data, structured so agents can actually use it. This is a modern, AI-inflected take on the classic Knowledge Management projects of the early web era.  We’re talking about Ontology with a capital O again.

Yasmeen Ahmad, managing director of Agentic Data Cloud at Google Cloud, is one of the best communicators in the industry. She introduced the data infrastructure section of the keynote, bringing the announcements to life with… Frozen Yoghurt. Yep – not a holiday booking, or revamping a camping company e-commerce site, but Froyo.

When you’re a food retailer you want to make sure you can meet people’s dietary needs – gluten and dairy free are both growth markets. Allergy information however might all be in a bunch of PDFs – it’s classic unstructured data, or what Ahmad calls dark data.

So what if the system identifies potential allergens? That’s new knowledge you can take advantage of for product management. So AI has enriched the knowledge catalog. But then you want to correlate that with a bunch of customer information about allergies. That might be in your system of record. But what if that database was hosted in AWS?

With Google’s Cross Cloud Datalake you can access data directly in third party clouds, using the Apache Iceberg standard. Finally you want to query the data before making a new product decision, so you use your favourite agent, and it’s ready to provide the correct answers based on your enterprise data via the Agent Data Kit. Great demo.

So the idea is that first you build a Knowledge Catalog. You don’t even build it. AI does.

I talked to Andi Gutmans, who runs Google’s data infrastructure and storage businesses. He said that humans are not going to be able to scale to the amount of data and events we’re talking about. Ontology is going to have to be machine learning based. Given the failure of Ontology efforts in corporations over the last few decades, partly because it’s just a hassle to annotate enterprise data with technologies like RDF, it would be hard to argue with him. Ontology, he argued, is actually an agent problem, so he has put together an “AI forward team to work on enrichment”.

The product design goal is essentially smart storage – a file lands, it’s instantly tagged, enriched and made agent ready. Every file or interaction should help the model learn about your business semantics. That’s where valuable context comes in. Google cited Virgin Media O2 as an early customer of the Knowledge Catalog, which it’s using across 20k different assets.

Of course you need a really good search engine on top of that ontology. Apparently Google has some proprietary search technology that is quite good.

We keep coming back to this question of human scale vs the scale that agents are going to drive. What does it look like to run an infrastructure business when a swarm of agents at a customer are going to spin up a hundred thousand databases in an hour and tear them all down again?

This is key to how Gutmans is architecting Google’s data products – agents take action, they don’t just make enquiries. Gutmans said Google Cloud is therefore now working towards an expectation of customers managing zettabytes rather than exabytes. Agents driving unprecedented data scale, just as they drive the need for compute, and transactions.

Rebuilding in flight

One thing I can’t stop thinking about that Andi told me:

“Now – I need to rebuild a lot of stuff we built a year ago.”

That’s the point. Everything – literally everything, is now about rebuilding in flight. You need to update your priors every day with AI, agent, and LLM progress, and that often means restarting projects because they simply don’t meet the new requirements. For an enterprise software business this is super hard. There are new product management disciplines required when the targets are moving so fast. This is going to find out a lot of companies, which are going to struggle with this rate of change and how to manage it. The days of ship it and then run it for the next decade are behind us. And if you don’t have an incredibly solid foundational platform, making these changes is all the more risky.

Related to this is the need to meet customers where they are. If enterprises thought shadow IT was hard, just wait til they start getting their heads around the new rates of tool adoption.

In a conversation at Next Peder Ulander, VP of marketing said:

“Years ago you could say here is an enterprise tool, and here is what you use at home.
It used to be – find a tool you like to work with, and maybe bring it into work two years later. Now it’s now the next year, it’s the next day.”

That’s the reality, and it’s a reality that agents are only accelerating. The tools are more capable than ever, the opportunities to improve business processes using autonomous agents is increasingly clear. People aren’t going to wait for traditional enterprise sales cycles to start using the tools. Vendors are going to need to respond with strong product led growth plays from the bottom up, supported with the usual large deal size top down procurement. The market is moving incredibly quickly, and Google Cloud is very well positioned for the agent era.

During his Google Cloud Next 26 keynote CEO Thomas Kurian said:

“We’re collaborating with Apple as their preferred cloud provider to develop the next generation of Apple Foundation Models based on Gemini technology. These models will now power future Apple Intelligence features including a more personalized Siri coming later this year.”

This is a big deal. This news didn’t come from Apple, which is notoriously tight lipped about such things. There wasn’t a press release about it. But assuming it’s true, and there absolutely no reason to doubt Kurian, then its worth considering what it means.

Pretty much every phone on the planet is going to be powered by Google Gemini AI going forward – certainly Android services will be, and this now bring iPhones into the mix. This is an almost absurdly great position for Google to be in, as AI moves out to the edge.

Every phone on the planet. That’s potentially billions of devices.

As we know, model preferences are far from sticky. They change day to day. Who knows what Apple will be using in 2027 or 2028? Model choices change quickly, but rolling these changes out at Apple ecosystem scale would be no mean feat. A ton of things would break. And Apple actually building its own frontier model based on Gemini – that does feel kind of sticky. Over the longer term Apple will very likely build and lead with its own model. But it certainly took a while for Apple to make Maps competitive, for example, after its initial use of Google Maps. Google Search is still the default on Apple devices (to be fair Google pays for this privilege, but I believe the point stands.) This is a landmark win for Google Cloud.

There are all sorts of questions – not least architectural. Will Siri be running AI with local models, maybe something like Google Gemma, or is it about Siri’s back end running on Google Cloud with Gemma. Is this actually a client side win, or a cloud win. Given Apple’s strict approaches around privacy one assumes there will be a local component. Plenty to unpick though.

Nobody chooses a model for life. But for this era of AI service buildout Gemini powering Siri is very notable. It’s a huge cloud win whichever way you look at it, and frankly neither AWS or Microsoft Azure could have done so, if it was based on owning a competitive frontier model. Unlike Google they lead with third party models.

I will be watching Google I/O closely next week to put this into further context.

disclosure: Google Cloud is a client, and paid for my T&E to the event.

This year’s theme was “Prepping Craft” – in a world where safety and normality are slipping away, how do we make our code, our communities, and our lives truly resilient? I loved the topic when I first heard it, and it’s only become more urgent by the day. – Alex Chan

In a moment when institutional trust is declining, political environments are hostile, and the open source ecosystem is under genuine strain, a conference that centers human connection, psychological safety and community resilience isn’t a nice-to-have. It’s a model for what the industry needs more of. – Alyx McQueen

Monkigras is my favourite conference of the year, sorry to all the other conference friends I have, and it is not even truly my industry. Every year the conference has a theme and this year’s is about being prepared. – Dave Letorey

“Listening to inspiring speakers from around the world helped me understand how to navigate challenges—both as an individual and within a community. I also had the opportunity to gain different perspectives from experienced professionals in tech and individuals working in tech-related fields. Hearing their journeys and insights really broadened my thinking and inspired me to keep growing.” – Rahwa Haile

So I guess we did OK, then. Monki Gras 2026 was a couple of weeks ago. The feedback from delegates was lovely. The theme this year was “Prepping Craft” — examining what it means to be prepared for whatever comes next, technically and culturally. What it means to be prepared: for the impact of AI on the industry, for geopolitical uncertainty, for the challenge of product rollouts, for (distributed) systems failure. We explored strategies, tools, and philosophies that make people, communities, products, and platforms safer and more resilient. All of the quotes above and below are from blog posts about the conference. They’re all well worth a read! 

I would like to thank all my amazing speakers:

Laura Tacho kicked off with a clear eyed view on data versus hype, considering what is going on in the AI and generative coding space. Anna Hevesi asked how we win in the age of robots. Ashley Rolfmore made the case that trust has to come before truth when building explainable AI systems. Sue Smith raised the question of whether our fingers still remember how to code as we become increasingly reliant on AI tooling. Liz Fong-Jones brought something deeply personal and important about rights generally and trans rights specifically— what do you do when you may need to change up your citizenship? After lunch, Hazel Weakly got intentional — about her life and how she crafts herself. Daniel Roe took us into the world of the npmx project, but also atproto, federation, and resilience in open source. Holly Cummins and Sanne Grinovero tackled the open source bus number problem – what happens if something happens to your key project maintainers? Finally Adrian Cockcroft made the case that resilience requires conscious observability, which in many respects was a talk for what you need to do to prepare for a long and successful career. 

Day two pushed the prepper theme further. Danilo Campos prepared us for unimaginable change – and a world of abundance in energy and cognition (have you ever considered just how magical it is that you can simply flush a toilet?). Chad Metcalf shared his own story as a the owner of an old gold mine near Yosemite in California. Adam Zimman offered a trans guide for CIS parents. Heidi Waterhouse and Kim Harrison looked at resilience in communities, highlighting work in Minneapolis and Oaxaca. Matt LeMay closed things out by reframing how we plan for uncertainty itself. We closed things out with a book signing with the Progressive Delivery crew.

Another important word – a huge and epic thank you to our sponsors – you can’t run an event like this without the help of amazing sponsors. We live in capitalism, and we need to appreciate that.

• Bishop & Dinner: AWS (the cheese mountain, oysters, and amazing Indian food)
• Abbot: Heroku by Salesforce
• Dean & Diversity and Inclusion: Oracle
• Ops: Chronosphere
• Lunch: PostHog (Turkish on day one, Vietnamese on day two). 
• Buy a Round: Dynatrace, The CNCF, Betty Junod
• Amazing Coffee: MongoDB, GitLab (amazing coffee from Scenery coffee roasters, served by the excellent people at Handles).

Many thanks to Dan McGeady, my production manager, Handsome Rob on beer and beverage operations, and their respective teams. Jessica West for being my spar. To Elena Barker, our D&I manager (amazing job!) And of course our incredible designer Gail Myerscough – her take on punch cards really pulled the whole event together. She is open for commissions, does brilliant design work, is flexible and works really quickly.

So let’s close out for now with some more commentary from delegates, because really it’s their conference after all.

I’d barely set foot into the venue when James introduced me to Elena Barker from Code Your Future to enlist me as a mentor for the folk coming along under the auspices of the diversity & inclusion programme. It was a real pleasure to meet some of the participants and talk about how we’re all on a learning journey. Working with early career folk has been one of the highlights of Atsign over the past five years, so this was a chance to chat with some similarly talented and enthusiastic people. – Chris Swan. 

I think many would agree – these were two days full of pure joy. No clichés, no repetitive speeches – just unique, thoughtful and often deeply personal talks. At times, it was emotional for both speakers and the audience, and that’s exactly what made it so special. In a world that often feels uncertain, this space reminds you it’s okay to feel, reflect and connect. – Elena Barker.

The talks themselves covered everything from AI hype versus real data to resilience engineering and the future of software careers. Some sessions were technically deep, while others were unexpectedly personal. I loved the mix of technical depth and humanity. Sessions from speakers like Liz Fong-Jones and Hazel Weakly weren’t just about systems and resilience they were about people, responsibility, and the realities behind the work we ship every day – Hawwah Okunmoyimbo

What’s better than a conference that combines TED talks with beer? Two conferences! Monktoberfest in the autumn and Monki Gras six months later in the spring. This year’s Monki Gras was my first. Open source wouldn’t exist without its community, and Monki Gras brings together some of the brightest minds in that domain. – Tarus Balog

I was writing this post today when the news dropped that Cursor has just raised a new round.  

> We’re pleased to announce a new round of financing: our Series D of $2.3B at a $29.3B post-money valuation. We’re excited to deepen our work with existing investors, including Accel, Thrive, Andreessen Horowitz, and DST, and welcome new partners Coatue, NVIDIA, and Google. 

Now I am old enough to remember when a company that approached a VC to say they were raising money for a dev tools startup would have been laughed at. Obviously that was a different time, but raising $2.3bn on a VS Code fork/Claude Sonnet wrapper is quite impressive all the same, no matter how great the developer experience is. Cursor is excellent software to be fair.

So what does The Eclipse Foundation have to do with this? It’s not the first name you think of when considering organisations supporting the current wave of innovation in AI tooling? I mean wasn’t Eclipse that open source Java IDE from the 1990s and 2000s? Yes it absolutely was, but the Foundation has continued to support the standardisation of open technologies, and find new niches (like automotive) to fill. [It’s also worth mentioning, though not the subject of this post, the excellent work the foundation is doing in corralling other open source foundations around security, for example helping them to come to terms with the implications of the European Cyber Resiliency Act. Further side note – if you build software you absolutely have to start paying attention to the CRA.]  

Open VSX, an Eclipse Foundation project, is an open source registry of extensions for VS Code compatible editors such as Cursor and Windsurf and vibe coding tools including Bolt.

Microsoft’s position is pretty clear – you can’t use the VS Code Marketplace to enable or support products outside the Visual Studio family. So while, for example, VSCodium is a community-driven, MIT-licensed distro of VS Code, which third parties can build on, they can’t take advantage of the official marketplace. VSCodium uses Open VSX registry as its default extension marketplace, as do most other VS Code forks. 

Microsoft has been fairly benign about forks of VS Code until quite recently, but with the huge success of the Cursor fork of VS Code it has begun to bare its teeth. Dion Almaer wrote about the forking issue, and Microsoft’s approach to it here.

> I want healthy competition. I want VSCode to open up more extension points so anyone can build great experiences without having to fork. I want changes to the marketplace rules so it can be more open. I want companies to be able to work together via open source so we can all gain from the rising tide (a la Chromium++).

> We are going through such an explosion in the world of development thanks to AI and the surfaces where we get to use it.

> What will be next? Will the companies with chess pieces on the board make moves that can help all? As developers what is our role to play? We can be clear on what we want to see… and we can adopt the tools that tie to our values.

Open VSX will be part of any pushback to Microsoft efforts to regain control of the situation. Amazon Web Services adopted Open VSX as the default registry for its Kiro AI IDE, which is another big win for the project. AWS recently announced it’s investing to support the Eclipse Foundation accordingly. So yes, Open VSX is in an interesting place.

As I wrote recently – Editors are up for Grabs– and the Eclipse Foundation is supporting this innovation and choice.

For those of you that are IT history enjoyers one significant irony of all of this is the original Eclipse IDE was written by Erich Gamma. He also just happens to be the original lead on the VS Code project, which began as Project Monaco, a web-based IDE in 2011. He’s still the key figurehead behind it. So an organisation founded to support a project that he wrote 25 years ago is now becoming a counterweight to what he later built at Microsoft – VS Code, one of the most successful and well-loved code editors of all time. What a towering influence Gamma has been on the world of developer tools. He really is the GOAT.

Disclosure: AWS, The Eclipse Foundation and Microsoft are all clients. 

It’s been a long time coming but the book has finally shipped. I am super proud to have worked with my co-authors Adam Zimman, Heidi Waterhouse, and Kimberly Harrison to deliver something that I think is going to be really useful to people. I can’t think of a better publisher than IT Revolution. I mean if you’re in the same stable as Accelerate and The Phoenix Project, you know you’re doing something right.

We wanted a strong analytical framework and great case studies and that’s exactly what we’ve got. We also wanted to cast a fresh eye on engineering and product management disciplines, putting the user first but really thinking about the business of software delivery and how to improve it. In the book for example we think about the third loop. It’s not enough just to have dev and ops. You also need the user in the frame. So much of the foundational work in defining modern software delivery was established before we had the world’s computing resources at our fingertips in the cloud. Before we had infrastructure as code as a guiding principle. Before we could really model and accurately codify every single element in our IT estate. Before we had accepted the primacy, even, of engineering and software developers in delivering new digital products. Before we could do real user monitoring. Before we could easily do dark launches using purpose built platforms. Before observability had brought all of the signals together that we would need to build, operate and iterate more effectively. We therefore established a framework based on the world as it is now, and the new requirements and capabilities, based on 4 key tenets – Abundance, Automation, Alignment and Autonomy. The past is a different country and the new country is progressive delivery.

Good business books need great case studies. And to that end we did really well. To have engineers from Amazon Web Services, GitHub, Sumo Logic, and Nike share knowledge and experience with us about the way they had built systems that put the user first, that would enable them to roll new services out to specific cohorts in controlled ways before broader rollouts, reliably, safely and quickly. Yeah that was super exciting and we’re so glad that we were able to include them in the book.

At its core, Progressive Delivery exists to serve a fundamental purpose that can be distilled into a simple yet powerful statement: delivering what users need when they need it at the least cost and risk to everyone involved.

This is perhaps the manifesto of Progressive Delivery—not a description of its methods but a declaration of its ultimate goal. It captures the essence of what we’re trying to achieve when we implement these practices. By keeping this goal at the forefront of our thinking, we create a clear criterion against which all of our technical decisions, organizational structures, and delivery practices can be measured.

When we center our work on this purpose, we naturally align our teams, our technologies, and our processes toward creating value rather than just producing output. It transforms software delivery from the mechanical process of shipping features to a thoughtful practice of providing solutions that genuinely help people accomplish their goals.”

– Progressive Delivery: Build the Right Thing for the Right People at the Right Time.

So Progressive Delivery is partly about developer and team autonomy, supporting alignment with the business. But it’s also very much about user needs. One of the great advantages of abundance is that we can run multiple versions of applications and services, and in some cases let the user decide when they’re ready to migrate to a new service. We need to put the user’s needs first. Now of course, great design and great product management are about bringing the user on a journey, and helping them find and enjoy new ways of working and playing. But jerking them around is not the way to do it.

So yeah, I’m pretty excited about the book. If you’re building digital products and services it will give you some important food for thought, and perhaps make you rethink some of your assumptions. Copies are available at Amazon and even book stores, which feels pretty wild. When you read it please review it too – that would be super helpful in getting the word out!

If you’d like to discuss Progressive Delivery, or have me or one of my co authors present these ideas at your conference or event please let me know.

It’s been nearly two years since Broadcom acquired VMware, and a turbulent two years at that. There has been plenty of disruption. Customers and partners have both been fairly vocal about business model changes. But as renewal deals have been signed things have calmed down for now. I recently talked to Prashanth Shenoy, vice president of product marketing in the VMware Cloud Foundation (VCF) Division of Broadcom about what’s going on with the integration, and what we can expect in future. 

 A few things really stood out in this interview:

1. Clarity.  The way Shenoy communicates what’s going on is really admirable. It’s well worth watching the video and/or reading the entire transcript because of that. His thoughts are well structured and very clear.
2. Continuity. Prashant repeatedly makes clear that in fact a lot of the changes that have been made since the acquisition were already in play with VMware. The difference is that Broadcom tore off the band-aid. Broadcom made a dramatic shift, but the direction of travel was already in place. It’s not like Broadcom came in and threw away everything that VMware was doing. It just moved more aggressively and with more clarity.
3. Chutzpah. Considering all the sound and fury about the acquisition, it was interesting to have Shenoy straight out argue that VCF lowered prices. As a VMware customer, industry commentator, partner, or competitor you will be surprised to hear that. But Prashant went there and made the claim that the biggest difference is the transition to subscription-based pricing and that in some cases there were reductions over what you would have paid for the equivalent VMware offerings. Bold moves and bold claims. 

Shenoy challenged me about the industry at large and the transition to subscription-based pricing – frankly he’s absolutely right that we live in a subscription rather than a perpetual license economy. These transitions are indeed painful. Adobe for example got in there fairly early – customers still complain about the transition to a subscription-based model, but Adobe’s growth since the decision shows it was merited.

Here’s his take on on “price cuts”.

In fact, when we had our subscription product for VCF, it was $700 per core per year. And we cut it down for $350 per core per year, the list price, right? Which is a 50% reduction. So, the contrary to popular belief that we raised the price, we actually decreased the price. But there was a shift from perpetual to subscription. 

One big theme of the conversation, and indeed the raison d’etre for VCF is portfolio simplification – he said that before the acquisition VMware had 9,000 SKUs for its cloud infrastructure product. It is absolutely inarguable that the VMware portfolio had become complicated, unwieldy, and messy. It needed to be simplified. There had been so many acquisitions, so many overlaps born of strategic shifts, that it was hard to fully grasp the portfolio. Tanzu for example started as a container platform, before it became a grab bag of technologies.

So, we went ahead and simplified the product based on what the customer wanted. give me a platform that truly helps me give a strong alternative to public cloud, like a true private cloud platform, right? And that was VCF. So, that’s where we focused our energy and intention. Portfolio simplification.

 A lot of our customers now understand the value that the platform provides. In fact, we’ve seen some major improvements in the total cost of ownership once they go through the Capex hurdle. And we have seen a lot of our customers move their workloads, including the modern workloads, containerized workloads, onto VCF to run their business. So, it’s been a pretty exciting transformation, but with its bumps. We could have done a lot better in terms of communicating why we did this and bringing the customer along. But we were so fast in making the changes that it caused some disruption in the market.”

Certainly true. Change management is hard.

One area where VMware is in excellent shape is in data, infrastructure, and operational sovereignty. The market has moved its way decisively. Global geopolitics has pushed sovereignty right to the top of enterprise IT concerns in 2025, certainly in Europe and also to some extent Asia Pac. If private cloud seemed like a luxury that only truly made sense for regulated industries, now it seems more like a luxury not to be hedging with private cloud bets. And that’s of course where VMware has been investing and building. We also spoke a fair bit about personae. Shenoy said VCF caters to three key personae – the cloud admin, the platform engineer, and the developer who doesn’t even want to think about underlying services. 

What do these apps look like? Enterprises want to drive value with new AI-based applications, but they’re really concerned about compliance, privacy, and security. 

How can we help customers move at the pace of AI, pace of software, pace of what the developer needs? Those are the kind of customers that we are truly helping to work with to provide them a platform, the private cloud platform, on which they can run their business for both their containerized application as well as the VM application.

When it comes to AI, one question I had was about GPUs. Don’t we live in a cloud-based GPU world now? What can Broadcom offer customers there? Well – apparently some enterprises are indeed buying their own GPUs, and Shenoy argues that virtualisation capabilities are more important than ever.

So Broadcom has a platform called Private AI Foundation that it built jointly with NVIDIA – which is designed to allow enterprises the most efficiency for the GPU hardware they buy, with 25 years of innovation behind it – dynamic resource scheduling, v-motion etc. Inference and training require high performance, and high speed data connectivity.

One of the key, again, misconceptions in the industry has been like, hey, you can run all these AI workloads on bare metal. If you look at all of the hyperscalers, they don’t necessarily run it on bare metal. They have a Linux kernel that they run on top of. It’s the same thing with us, too. We run it on top of ESX, which is our hypervisor. And all of the capabilities of virtualization that we built in also comes along with that. So, when we have run performance benchmarks with MLPerf, we’ve seen pretty much VCF and vSphere retaining 99% of the performance of a bare metal with all of the other virtualization capabilities that I just talked about.

For more about the simplification around VCF and Tanzu I again suggest you watch the video or read the transcript. How Broadcom decided what was infrastructure and what were application services as containers and VMs collided, given the application and PaaS services in its portfolio. VCF now includes Kubernetes runtime services, but not the higher level services.

Before signing off I have to mention customer feelings, which are still running hot. We’ll see over the next few years how things settle down, especially as renewals come up again. The competition, notably IBM, is very focused on competing more head to head with VMware. Hyperscalers too sense opportunity, sovereignty issues notwithstanding. 

But Broadcom is absolutely crushing it from a revenue and share price perspective. Remaining employees are certainly happy with their options. And the portfolio and messaging are a lot more straightforward. VCF is a marker. It was a good conversation. 

disclosure: VMware is a customer and sponsored the video. IBM is also a customer.

With all the buzz around Observability over the last few years it’s easy to imagine that when it comes to logs, metrics and traces, it’s game over. Just stick all the data you need in a database, or these days a data lakehouse, and start building queries and dashboards. Easy. 

Glibness aside, Observability tools vendors generally claim they can manage all your metrics and telemetry data in a single coherent store, with consistent access mechanisms. But as telemetry data has exploded so have costs. This is especially true when we want to correlate the data in terms of business needs- the problem with things like customer number, user or product ID, or IP address is that they are inherently high cardinality. Columns with many unique values drive up costs of memory and compute, and these costs get passed on to customers. 

Where it used to be that folks complained Splunk was expensive, these days we hear the same about Datadog. Datadog, long seen as the darling of the APM space, rather than a “legacy player” is now seen as expensive. In 2025 this is a Datadog weakness – this issue comes up repeatedly in customer conversations. It’s not that people don’t value Datadog – they rave about the user experience. But costs are a concern. 

There is a huge opportunity here around cost management, notably in the emerging log data management (LDM) space. Organisations are concerned with costs of storage, and cardinality. 

So what is Log Data Management and why is it useful? 

The bottom line is that log management is indeed a data management problem. Data sources continue to fragment, with every new platform the organisation uses. Modern Observability is not about instrumentation but data, especially in the open standards world of Open Telemetry. But we’re not yet living in a world where every piece of your infrastructure is using OTel. There is plenty of telemetry in different systems that needs to be integrated, collated and transformed before it’s truly useful- similarly to ETL in the data warehousing space.

So we’re faced with at least two factors that need to be addressed – cost of storage, and complexity of the data landscape.

You might justifiably claim if your tool is primarily used for troubleshooting by developers that you don’t actually need to store all the unique events in your log stream, but a lot of organisations with a strong focus on security and compliance, such as those in regulated industries, do indeed want to store all the telemetry. 

With log data management you’re concentrating on integrating data from a range of sources, often leaving it in place, but with pipeline routing and data refinery capabilities to allow you to manage all of your log data cost as cost effectively as possible.

The company that arguably best represents this view of the market right now is Cribl. It doesn’t position itself as a replacement for Observability or even log management vendors, but rather as an adjunct to them.

Cribl Stream, formerly called LogStream, is about sending data to multiple places, rather than collecting it into one. It can enrich or redact data, and is used by customers to reduce volume for existing ingest platforms. Storing every AWS CloudTrail or Windows XML event gets very expensive quickly. 

Cribl is taking a similar approach with Cribl Search. Rather than consolidating data in one place before searching, the platform will search at the edge, so that you can search across multiple contexts, with data left in place, using a unified query language. Federated search is really hard, but the philosophy of “search-in-place” is a great play for customers that don’t want to buy another centralisation promise. 

Chronosphere moved from using CrowdStrike as an OEM log provider to launching their own log control product in June 2025. Chronosphere’s platform is all about letting users control the volume of data they are storing, but because they don’t price on ingest users can have more visibility into what they need to keep. When Chronopshere launched their log product, CEO Martin Mao told RedMonk:

One of the big gaps is you don’t know which and which sections of your logs to reduce and how to reduce them. And the way we solve that, and this is one of the reasons why we built our own back end, is we actually have to analyze all of how you use the logs in terms of dashboards, alerts and things like that. Then we turn the analytics into suggestions to feed a telemetry pipeline, and you can reduce your data volume. 

Startup Control Theory was created to give companies more operational and cost control over their logs. Co-founder Bob Quillen argues that OTel helped democratize instrumentation and collection of telemetry, but it still led to “fat dumb pipes that dump into a data lake, and then you pay for ingest of that data, indexing it, and retaining it. And we thought, ‘there’s got to be a better way to do this.’” And so he and his co-founders set out to create a control layer to sit on top of telemetry data to better manage it.

Hydrolix, on the other hand, is tackling the cost problem of logs by delivering an extremely high compression data lake that can stay always hot. Hydrolix’s approach is maybe tangential to the other log data management approaches mentioned here. While other competitors focus on reducing the total volume of logs saved and stored, Hydrolix instead have focused on reigning in costs by building their own proprietary compression methodology. A big reason why they can compress so efficiently is that their solution focuses exclusively on logs, not any other type of telemetry. 

Honeycomb, which positions itself as the best solution for querying and analysing high cardinality data at scale, has responded to the need for pipeline-based log data management approaches. It launched the Honeycomb Telemetry Pipeline product. Telemetry Pipeline Manager uses the OpenTelemetry Collector to scrape and collect system logs. The collector supports multiple log formats. Logs can also be refined, the elimination of redundant data. The Refiner also enables the identification of potentially important events – showing for example, errors or slow requests. The rest of the data is archived, but you can rehydrate full-fidelity logs and traces directly from S3.

Datadog also offers an Observability Pipelines product – customers save on egress costs by sending only valuable logs to a chosen observability vendor, and then routing other logs to long-term storage such as AWS S3, Azure Blob Storage or Google Cloud. As ever Datadog offers plenty of out of the box functionality, in this case more than 150 predefined parsing rules. to transform logs into structured formats for querying using its Grok parser. 

 Other products to look at include Mezmo (telemetry pipelines and log analysis) – it actively markets itself round, for example, reducing datadog spend. Edge Delta also plays in the (telemetry pipeline space)[https://edgedelta.com/comparison/edge-delta-vs-cribl/]

So telemetry pipelines is definitely part of the solution, but we feel an active and intentional approach to log data management, with a specific focus on, in effect, hierarchical storage, where data be stored in cheaper blog storage, but also quickly rehydrated and made available for querying. The key point here is that log storage is expensive. Every enterprise or SaaS company we talk to feels that pain. Which is where log data management comes in.

Disclosure: Splunk, Cribl, Chronosphere, Control Theory, Honeycomb, AWS, Microsoft (Azure), and Google Cloud are RedMonk clients. 

I recently appeared as a guest on the Context Window podcast hosted by IBM’s Anant Jhingran and Ed Anuff. It inspired a couple of posts. This one is about skills relevance – namely Java and agents.

Ed said that he had talked to some people that still flatly refuse to believe that AI works in any context. Perhaps they’ve had poor results, or couldn’t get something to work. My suggestion is to try again. The models and tools are getting better all the time. We also talked about the fact it feels like some people are saying you need to learn an entirely new stack in order to be relevant in the age of AI- trying to keep up with achingly cool kids. As someone that has tracked programming language adoption and usage for a long time this seems particularly wrong-headed to me.

Of course there is probably an underlying factor at work here – fear. People are naturally a little unnerved about the impact of AI on the software development jobs market. But this is where continued learning is so important. The swiftest path to irrelevance is to refuse to learn new skills and or refresh the ones you already have.

So what about Java?

Sure new languages and frameworks continue to emerge, and move to dominance. Java is no longer a top three programming language (Python, JavaScript and TypeScript are all ahead). But, and this is the important bit – that’s not to say your Java skills are not relevant. On the contrary – it’s highly likely they’re going to come into their own, particularly in enterprise contexts. Don’t think OMG I am a Java developer, but now I need to learn Python because it’s the language of AI. Python may have overtaken Java in terms of the current industry conversation – it’s the language of machine learning and AI after all. Sure, OpenAI is a huge Python shop. Python is the language of frontier models, and the Python ecosystem of libraries is just an incredible industry asset. But that doesn’t mean your Java skills aren’t relevant for developing apps that use models.

Java has incredible antibodies. Its ability to swallow and digest new innovation, to find new niches, is why it’s lasted so long in this industry and been so successful. Think about big data. For a while, people were saying, “Oh no, there’s no innovation in Java.” Big data came along, and sure enough, we saw frameworks like Hadoop and Spark written in Java and JVM languages. Java has maintained relevance through all of the waves that we’ve seen over the last couple of decades – it is the exemplar of a general purpose programming language and runtime. With the distributed systems and cloud revolution, so many of the applications and systems that were built, so much of the infrastructure, was built in Java, new languages like Go and Rust notwithstanding. The idea that somehow Java isn’t going to be play well with AI doesn’t make any sense.

Let’s look at an interesting example of innovation in the space, an an antibody in his own right. Rod Johnson founded the Spring project. Millions of developers around the world use Spring and Spring Boot every day. He’s now created Embabel, a strongly-typed agent framework written for the JVM. It’s designed to bring determinism to your project plan using a model that isn’t an LLM, before using autonomous agents to generate the code to map to that plan. Not everything is decided by LLM. According to Rod:

The critical adjacency for building business apps with LLMs is existing business logic and infrastructure. And the critical skill set is building sophisticated business applications. In both these areas, the JVM is far ahead of Python and likely to remain so.

Honestly, this checks out. Embabel is an enterprise play, and one where Java developers’ skills are on point. Spring has proven itself for business logic, systems that are built to last, event-driven systems, transaction systems and so on. Adjacency is a thing. Rod again:

If you’re a Spring developer, you’ll find building agents with Embabel to be as natural as building a Spring MVC REST interface.

On the LLM side, folks might just be thinking surely Model Context Protocol (MCP) is all you need? The hype might make it seem so, but security concerns around the standard mean the answer is almost certainly not. MCP became an industry standard remarkably quickly, but arguably too too much so. MCP became the new Hello World for every enterprise technology vendor, but there is still a great deal of work to do.

Here’s what Rod believes MCP lacks:

• Explainability: Why were choices made in solving a problem?

• Discoverability: MCP skirts this important problem. How do we find the right tools at each point, and ensure that models aren’t confused in choosing between them?

• Ability to mix models, so that we are not reliant on God models but can use local, cheaper, private models for many tasks

• Ability to inject guardrails at any point in a flow

• Ability to manage flow execution and introduce greater resilience

• Composability of flows at scale. We’ll soon be seeing not just agents running on one system, but federations of agents.

• Safer integration with sensitive existing systems such as databases, where it is dangerous to allow even the best LLM write access.

The last point really is absolutely critical. 

Rod is building in Kotlin, which is an interesting design choice. His argument is that Java can do a better job than Python agent frameworks like crew.ai. The proof will be in adoption, so this is a project I will be tracking with interest.

Another open source project to mention is LangChain4J, supported by vendors including Red Hat and Microsoft. Dmytro Liubarskyi, founder and project lead, says:

“Our goal with LangChain4j has always been to make advanced AI capabilities easily accessible to Java developers — without compromising on security, scalability, or developer experience.”

LangChain4J is designed to allow Java developers to easily work with LLMs, vector stores and agents. It also has a set of Kotlin extensions.

Meanwhile Jetbrains has built a Kotlin-based agent framework called Koog – “an idiomatic, type-safe Kotlin DSL designed specifically for JVM and Kotlin developers”.

It’s also worth checking out this post by Marcus Eisele for further context.

What makes LangChain4j attractive to architects is its alignment with established enterprise patterns. The framework offers unified interfaces for chat models (OpenAI, Anthropic, Azure, Google Gemini), embeddings, and vector stores.

Developers declare @AiService interfaces, similar in feel to REST controllers, and annotate methods with @UserMessage, @SystemMessage, or @Tool to define prompts and expose domain logic. This design keeps interactions type-safe, composable, and predictable.

LangChain4j also moves beyond simple model calls. Tool calling allows LLMs to invoke Java methods directly. This controlled bridging between models and systems turns generative AI into a first-class part of enterprise logic.

It’s those Java and JVM antibodies at work. I mean, sure, by all means learn some Python and or some TypeScript. TypeScript is the current language of the day in building dev tools. It’s really exciting how much innovation is happening there, TypeScript is exploding – it seems partly because AI is generating so much of the code written today. If you’re building dev tools, you’re building modern dev infrastructure, chances are high that you’re building in TypeScript. But one can’t learn every new thing that comes along. 

Of course questions will always remain. For example – what’s the future for Spring now it’s owned by Broadcom? But there is plenty of innovation out there in Java frameworks such as Quarkus (that team is currently working on a Langchain4j extension. Oracle remains a solid steward of the core language. IBM and Red Hat continue to invest in Java, and aren’t going to give up on the AI, LLM and agent opportunity lightly. 

According to my colleague Dr Kate Holterhoff Java is cool again. Anthropic and IBM are partnering – great post by my colleague Stephen O’Grady about the implications here– and I believe that definitely means Java modernisation and integration with LLMs.  IBM’s Project Bob IDE is explicitly being pitched for Java modernisation, with a focus on enterprise security when using agents. If you’re a Java programmer, you may be in better shape than you thought for building AI-enabled apps, integrating agents into your workflows.

Bit of a bonus update here. After I posted this on linkedin, Tyler Jewell CEO of Akka commented that I could have mentioned the company in this post. I think this is fair, given Akka literally pivoted from its historical language and framework roots to focus squarely on AI agent workflows. Akka was originally a framework written in the JVM-based Scala language for building high performance, concurrent distributed systems. Now the platform is positioned is as a safe, secure, agentic AI platform. According to Jewell:

Agents are unreliable:
– complexity with agents, memory, orchestration, streaming, endpoints, APIs, tools, integration, stochastic LLMs … all now running in a distributed system.
– distrust from unreliable systems, limited agent security protocols, lack of agent identity, transparency and explainability of LLM interactions, inconsistent outputs, and new AI security threats.
– shadow costs that extend beyond LLM fees as agentic systems require constant maintenance, integration with feedback loops, and continuous governance.

Java and the JVM is well suited to overcoming these complexity, trust, and cost issues.

disclosure statement: IBM, Red Hat, Microsoft, Oracle and Broadcom are all RedMonk clients.  

I recently guested on the Context Window podcast hosted by IBM’s Anant Jhingran and Ed Anuff. It was fun. I usually try to bring some pragmatism to a conversation, and this was no exception. One message I really want to get across to people is that your skills are still relevant. AI is disruptive, but that doesn’t mean it won’t create great opportunities for you.

Ed asked me about the challenge of keeping up with everything happening in the industry right now, which reminds us of the Javascript framework wars – oh my god I didn’t read Hacker News this morning, how will I even be able to write code?

He asked: “You’re a dev so how do you not lose your mind? What’s the path to sanity?”

Now It’s literally my job to know all of that stuff – OMG there is a new model. A new thing dropped. A widget, a platform, a frontier model, a startup. We’re in the midst of a builder frenzy.

I said that, as ever, people are a big part of the answer. You need some folks to help digest all of this stuff for you (snakes swallowing elephants). Yes AI wants to do it (“let me summarise that for you”), but it turns out humans are really good at digesting, understanding and summarising stuff for you. Who knew?

So yeah, who’s gonna help you navigate the thicket? You can’t spend all of your time trying to work out what’s really important to your day job, or your side project. There are some amazing summarisers, so I would say listen to them, and learn from them, to help you navigate this incredibly fast moving space, without being worried about that pace of innovation. 

Don’t try and follow everyone. Don’t spend all your time on X worrying about the latest launch you missed. Don’t be stressed about it. But by all means use AI in your daily work. If you’ve tried it before and been disappointed then I recommend you try it again. Generated code doesn’t all have six or four fingers any more.

So here are some people who can make your life better, by doing the work.

Angie Jones was originally a Java developer and is now a world class developer relations practitioner, technologist and educator. Today she runs dev rel at Block and she’s helping to build momentum around the company’s Goose AI agent. The work Angie and her colleague Rizel Scarlett are doing is practical, with applications of AI to software development. Angie is also helping to make it abundantly clear that your existing skills are relevant. Her recent post about How Developer Relations leading AI adoption is thought-provoking: it turns out that when everything is changing all the time, as it is in AI, teaching and samples and proofs of concept are more important than ever. Her team is doing industry defining work. Dev rel is having a renaissance because AI is all about education. So Follow Angie!

Simon Willison– every time I give a talk about AI in any context I tell people to pay attention to him. He is from the Python world, but endlessly curious about seemingly everything AI-related. Brilliant communicator. If there is one thing you read every day, go and check out what Simon Willison has to say. He will help you understand which technologies are ready for prime time and what’s happening across the industry.

Claire Vo – CEO and founder of ChatPRD. Amazing communicator about the value of AI tools from a business perspective. She is building a product management platform using all the latest models and AI tools. Follow Claire, you’ll get an entertaining, positive view of what works and what doesn’t. So get yourself over to her YouTube channel How I AI.

Jesse Vincent –  Best known for his work in the PERL community, where he was project lead. Also creator of the K-9 Mail email app for Android, which was acquired by Mozilla and rebranded as Thunderbird for Android. Anyway he’s doing excellent work helping people understand things like Claude Code Skills. Very practical, great writing. Read his blog Massively Parallel Procrastination. This piece, for example, is a good read – When it comes to MCPs, everything we know about API design is wrong. 

“This might be a hard lesson to hear, but tools you build for LLMs are going to work much, much better if you think of your end-user as a “person” rather than a computer. Build your tools like they’re a set of scripts you’re handing to that undertrained kid who just got hired in the NOC. They are going to page you at 2AM when they can’t figure out what’s going on or when they misuse the tools in a way they can’t unwind.

Names and method descriptions matter far more than they ever have before.”

Richard Seroter – he doesn’t just take a Googley view of the world. It’s about education. He takes a practitioner-based view and does a great job of keeping track of the latest developments, models and tools. His daily reading list is very useful.

And finally Rachel Stephens and Kate Holterhoff, my colleagues – are doing great work, using the tools and helping people understand them.

Your skills are relevant. There are great educators out there that are willing and ready to help you. If you’re struggling, then go on the internet and they will help you. You don’t even need to ask ChatGPT. I think it’s really exciting. To be honest I got slightly worried in 2023 – have I really got another revolution in me? As this bubble went into super expansion – I am a developers and practitioners matter guy, and do I have another rev in me? The answer is yes I do, and I think you probably do too. Its reassuring to know there are people ready and willing to help.

disclosure statement – IBM and Google are both clients.

A couple of months back Microsoft introduced the term “Agentic DevOps” at its Build conference (my full write up about the show is here). I thought it was interesting. I mean obviously, AI is having a profound impact on how we build and manage applications and services. Generative AI is driving the cost of creating software to near zero, and potentially increasing development velocity, and yet… the jury is still out. A lot more software means a lot more technical debt. Writing software is the easy bit – running and maintaining it – that’s where the costs are. And that’s where DevOps comes in. DevOps was intended to break down distinctions between development and operations, with a focus on automating and streamlining the entire software development lifecycle, from dev and test to deployment and operations. The idea reached a peak with the mantra – you build it, you run it. But with agents taking on more tasks, questions of responsibility are blurring. It makes sense that Agentic DevOps would be about using agents to take the automation aspects of DevOps to the next level, but in collaboration it also has obvious implications – because with modern coding practices we’re now increasingly collaborating with machines, raising a whole set of questions about specification, prompting, asynchronous workflows, and so on.

One of the intriguing aspects of generative AI is just how willing software developers seemingly are to jettison the last few decades of engineering best practices. The talk now is of One Shot, Vibe Coding, You Only Live Once (YOLO). It seems to me that Agentic DevOps is more about FAFO than YOLO. We’ve seen amazing horror stories emerge lately about just how cavalier folks are becoming in the gen AI era – oh yeah I’m giving Claude full access to my production database and asking it to change some up some functions in the identity management system. One thing DevOps should never be is cavalier.

But yes – FAFO. This is the age of experimentation. We’ll be spinning things up, seeing how they work, improving them rapidly, and iterating. Incident management is one of the DevOps principles where agents can potentially provide huge benefits. If using agents meaning getting paged less, and not woken up in the middle of the night, that has to be a good thing, right? And folks are indeed using agents in this way. Event-driven agentic systems will be at the heart of Agentic DevOps. Let the agent analyse performance and watch for anomalies. Let the agent suggest a fix. As we gain confidence let the agent make the fix, or simply roll back the change that led to performance degradation.

At this point I want to talk a little bit about AIOps, a now somewhat discredited term. AIOps was a term that came out of the monitoring space, and it meant using machine learning to improve the state of the art in some functions – particularly anomaly detection. While rudimentary automation was expected, AIOps was specifically focused on monitoring and logging. Developers and practitioners didn’t like the term, and the company that coined the term, Gartner, has recently retired it in favour of “Event intelligence”. Some enterprise organisations have literally banned use of the term. So yeah “AIOps” is kind of cooked.

And yet.. It seems to me that Agentic DevOps is really what AIOps always should have been, and perhaps would have been, if we’d had the AI technology available then that we do today. Remember that ChatGPT exploded onto the scene in 2022, and the rate of innovation across the industry has been frankly bonkers since then. We don’t fully understand the capabilities of new Frontier models as they are rolled out, but they are really really good at some of the things that we’ve needed for effective DevOps. Creating documentation of code and practices, creating runbooks, generating scripts, monitoring… monitoring systems for changes, writing plans, writing tests. Collaborating with operators, developer and users in natural languages. More detailed bug reporting (no more need to try and understand what’s happening in that screenshot, upload it and the system understands already), reading and parsing logs. Centralising and summarising information. And obviously agents don’t need to sleep, which is kind of handy in DevOps scenarios.

One of the areas I am particularly interested in given my work in Progressive Delivery is how generative AI impacts what AIOps was in the 2016-2024 sense – which is to say, AI used in Observability use cases. The days of trying to parse logs by hand – maybe they are indeed behind us. Generative AI is going to fundamentally remake monitoring, logging and tracing. Observability plus AI is a whole new frontier. Imagine not needing to learn a new query language in order to interact with system data.

Anyway – at Build I was lucky enough to spend some time with Gene Kim and Doctor Nicole Forsgren talking about these issues. Gene literally wrote the book on DevOps and is currently writing a book about Vibe Coding with Steve Yegge, which is sure to be essential reading – both of them are really good at writing prose that draws you in, to explain complex subjects. Kim is now a Vibe Coding maximalist – he believes the days of hand-written code are behind us.

Forsgren has made a huge impact on the the industry through her work as one creator of the widely adopted DORA and SPACE frameworks, and co-author of the Accelerate and the DevOps Handbook, alongside Kim. Naturally she is also working on a new book – about Developer Experience. She’s a little more pragmatic about people writing code.

Anyway – I can’t think of two smarter and more appropriate people to be in conversation about the future of DevOps in the agentic era.

I will end this post with a couple of quotes. First Gene Kim:

Agentic DevOps is a significant part of the way we all code now. Because no one should have to type in code by hand anymore. And the person who actually coined that was Dr. Eric Meijer. So famous in this community for his work on Visual Basic, C Sharp. He went on to develop the Hack language at Facebook Meta. And he said, yeah, we are probably the last generation of developers who will write code by hand.

And I just thought that just so spoke to me. And, yeah, so agentic is when you can actually show the LLM agent the output of his work and it can fix it for you.

And, you know, from my perspective, I mean, it’s just utterly transformative. I have an experience where I spent 45 minutes being bossed around by an LLM telling me to type this, type that. And, you know, the aha moment was asking it to run curl by itself. Right? And 45 seconds later, it fixed the issue with the Trello API that I was struggling with in 45 seconds. The same thing with Google Docs. I mean, so it’s just like once you see something like that happening it just becomes so obvious, you know, that there are some things that you just shouldn’t be in the loop. Because the only thing you are now is the bottleneck, copying and pasting from one window to another. So, and it’s not just for developers, it’s for everybody. Technologists, for operations, infrastructure, DevOps, all of that. So, I don’t think we want to say that the only people who benefit from this are just developers because as someone famous said, who broke my build is going to be said even more often.”

And Nicole Forsgren:

We’ve really spent a lot of time focusing on writing code and how AI and LLMs and agents, agents can kind of help us bootstrap and amplify and accelerate that, and I think there’s also a ton of opportunity, not just in the inner loop, but all the way through the outer loop. Absolutely. What do we think about the opportunity for AI? Especially now we have agents to improve local test and build, to improve our pull request and code review process, to improve build and integration, to improve things like release. So, for me, I think that’s, when I think about agentic DevOps, that’s kind of what it is. The foundational principles are still really important, especially now that the speed and volume of creation has sped up so much. Now the rest of that software development loop is even more important.

You can find the whole transcript of the interview here, and the video is embedded below.

Microsoft is a client, and sponsored the video.