Hey there! Welcome to Platform Weekly. Your weekly splash of platform engineering sunscreen. Every week, we cut through the glare so you can see what actually matters (this week, we also found a very good bar).

Plus... PortCon, the AI Software Factory Summit, lands in San Francisco on November 17 and 18 with two full days on how real enterprises are running AI software factories in production, and Platform Weekly readers get an exclusive 70% off tickets here.

We knew we had to come for you

Our virtual events start at 7 pm Berlin time. For our friends in Sydney, that is 5 am.

So what do you think happens to the show-up rate for virtual attendees? For my beloved Berliners, it’s 44%. At 5 am in Sydney for our Aussie platform teams? It’s 72%. The highest of any demographic in the entire community (with Kiwis a close second;)

I first noticed in our session, of our first run of the Platform Engineering Certification. There we all are in Zoom. With a group of Australians, 4am their time, all cameras on. Ready to roll.

Australia is just 0.3% of the world’s population, but it is 3% of our community and 5% of our PlatformCon viewers. That is ten times its share of the planet.

So this week we stopped asking them to wake up for us. We came down under for them!

What did we get up to?

PlatformCon Live Day Sydney landed for the first time ever on Wednesday, and it was our best PlatformCon ever. Thank you. People flew in from Brisbane, Perth, Melbourne, Auckland and Singapore. It felt like a celebration of platform engineering in a place where a day like this had never happened.

Where do I begin with summarising such a day? Well, with some affirmation! I did a fireside chat with Rodrigo Castillo, Group CTO at Commonwealth Bank, on why CommBank is investing in platform engineering for AI. It was an awesome conversation. And it’s all well and good for me to tell you platforms are key for AI, but when massive, massive companies are proving it every day (and shouting about it!) that is the thing to really absorb.

3 quick highlights/takeaways from me:

• I met Liz Fong-Jones in person for the first time to talk about going from 30 to 70 pull requests a day BUT without wrecking her systems. And while reducing cognitive load and risk too.

• What is happening locally with platform teams will blow your minds. Fortescue on platform engineering in a live mine. Serko on shaping a platform engineering stream. CBA’s Brendan Hopper on swarm engineering.

• ClearRoute CEO James Jarvis boiled it down perfectly. Whether you’re in LDN, SF, Singapore or Sydney. The fundamental question might be expanding from “How do we best serve developers?” to “How do we best serve agents?” but the answer hasn’t. It’s the platform.

And of course… because it was us. We finished the day with House of Kube, fireworks, and a saxophone player over Sydney bay at sunset.

We’ll soon have recordings of all these talks, and I’ll tell you - what is happening on PlatformCon stages goes beyond the borders of the hype wave.

It’s actionable, realistic ways to succeed with AI using platform engineering. I love hearing what Anthropic and Google are doing. But most of us aren’t Google or Anthropic. How is an Australian mining company delivering value with AI? What about a 100 year old bank? Those are the lessons we can all take from, and act on.

What’s next?

Something tells me this was not the last time we point a PlatformCon at Sydney, but for the other 90% of you reading, there is much more happening soon.

If you’re in the Bay Area, you need to dive into PlatformCon SF & AgenticCon - because we’re taking everything we learned this week. Putting it into action - and pushing even further in February.

Sydney, you were awesome! And as always... stay crunchy 🥐

Quick bites

Other episodes

• Why you need to build an AI software factory

• We. Will. Own. Spend.

• Your agents are about to blow up your telemetry bill

• Nvidia, OpenClaw, and why your platform team matters more than ever

• Should you force teams to use your platform?

• The State of AI in Platform Engineering is revealed.

• Is your platform a platform? Path to outcome explained

Hey there! Welcome to Platform Weekly. Your weekly shift on the platform engineering factory floor. Every week, we clock in, see what the community’s been building, and ship you the good stuff.

Plus... Do you want to negotiate your next pay raise better? We’re building the 2026 salary benchmark for the State of Platform Engineering report, and we need your input to shape it. In return, we’ll send you a free salary benchmark. Send your input here.

Why you need to build an AI software factory

The AI software factory is one of the biggest things in tech right now (prob one of the biggest things in the world, if you ask the right people).

12 months ago, it was overwhelmingly just a buzzword. But today there are real factories running in real enterprises. And some of them are shipping real value. (And some are burning a LOT of tokens to produce an overwhelming amount of PRs that are a nightmare to read)

It’s a big topic for us too. In the last few weeks, Kaspar’s Weave Intelligence article What is an AI software factory?, and Port Field CTO Matar Peles’s community webinar on building an enterprise-grade one have both been absolutely ripping. It’s such a big deal that Port is putting on an entire conference about it in November, PortCon, the AI Software Factory Summit in San Francisco. So let’s dig in.

Code isn’t the bottleneck anymore (Duh)

From the State of AI in Platform Engineering to Anthropic’s AI-native SDLC playbook, it’s the fundamental challenge. The bottleneck has shifted. Agents write it faster than any of us can review it. So now the slow bit is everything else. The planning, the handoffs, the reviews, the waiting around for someone to click approve. Nothing new for us here.

Like we’ve been saying for 2 years now, handing someone GitHub Copilot, or today Cursor or Claude Code, (or throwing a bunch of Grok bots at a problem) isn’t the surefire path to free ROI.

All of those things might speed up code generation, but they don’t automatically speed up everything around it.

That’s why teams who have massively adopted AI, even those who are starting to add agents to their SDLC, aren’t automatically seeing ROI from that work yet. Even if they’re producing way more stuff.

What is an AI software factory, and does it solve this?

Simply - an AI software factory is an Agentic Engineering Platform (AEP) where agents can take work from beginning all the way through to finish without a person in every single loop. Signals from production kick off the work then agents will build and validate the change themselves, and a gate will then decide if the work ships on its own or needs to go to a human. So humans design the line, set the rules, and handle the exceptions.

Also known as Level 3 or 4 of agentic development.

That is the big shift. Most orgs still use agents only as basic helpers. Where AI suggests code & a human approves it, or agents open PRs and a human signs off on every single one. The dev is still the engine, just a much faster one at pumping stuff out.

In a factory (Level 3 or 4 agentic development), humans aren’t checking every change and but are designing the system that checks them. And if you’ve read the State of AI and Platform Engineering, you know that Level 3 is where the magic starts to happen.

30% of teams at Level 1 doubled their throughput, and just 36% at Level 2. Then at Level 3 it jumps to 60%. Now throughput alone isn’t value.

But guess what else jumps at Level 3? The number of teams that are getting transformational ROI from AI.

What does an AI software factory need?

These are the 5 things you need to build an AI software factory:

• Signals. Your observability, incident, security and usage data actually feeding the platform, so work kicks off from what’s happening in production.

• Paths. Every type of work has a defined path and a clear definition of done.

• Gates. Evals good enough to replace human review for the changes that don’t need a human.

• Identity and budget. Every agent run gets its own identity, scope and spend limit, and you can trace any change back to the run that made it.

• Context. A service graph, ownership and change history agents can reason over.

You’ll be hitting most of these in parallel, but context is where Matar sees most teams start (with identity in place first ofc, so agents can’t touch what they shouldn’t), and Port’s numbers on it are wild. In their own testing, a unified context layer cut agent costs by up to 80% versus agents piecing context together from a bunch of MCP servers.

But the big difference between agents at Level 3 and agents at Level 2 is that orgs at L3 manage the blast radius (otherwise, there’s no way to unchain the agent). Every change gets checked for how much it could break. Small, contained stuff (a dependency bump, a config fix) ships on its own once the tests and evals pass. Anything big gets built in an ephemeral environment, and a human makes the call. And when a change fails? It doesn’t just go to a human’s never-ending list. It goes back to the agent with the reason, and it tries again until it passes, hits its budget, or genuinely needs some human insight..

Then Matar showed pretty much the same thing running live in Port. An agent scores the risk of each feature based on the service tier, what it touches, and its blast radius, and that score decides whether a human gets pulled in. (Matar’s going to be at PortCon too, so you can grill him on it in person.)

It’s airport security for your code. Most changes stroll through the fast lane. A few get taken aside and have their bags emptied out on the table.

So if you want to see how the teams who’ve already done this pulled it off, go to PortCon. It’s November 17 and 18 at SHACK15 in the Ferry Building in San Francisco, and it’s AI software factories all day, both days.

Day one is hands-on workshops where you actually build a factory line. Day two is the conference, with Kelsey Hightower, Travis Gosselin from GitHub, Port’s CEO Zohar Einy, and NVIDIA’s Aaron Erickson. The event is bringing together the most advanced AI software Factory use cases from top tech giants, some join leaders from NVIDIA, GitHub, SpaceX, and Uber to see how they run AI in production.

Tickets start at $99 until November 2nd. As part of the platform engineering community, you also get 70% off with the code PC_70% at checkout.

Grab your ticket

See you on the factory floor. And as always... stay crunchy 🥐

Quick bites

Other episodes

• We. Will. Own. Spend.

• Your agents are about to blow up your telemetry bill

• Nvidia, OpenClaw, and why your platform team matters more than ever

• Should you force teams to use your platform?

• The State of AI in Platform Engineering is revealed.

• Is your platform a platform? Path to outcome explained

• Your telemetry bill is growing. Your answers aren’t.

Hey there! Welcome to Platform Weekly. Your weekly haul of platform engineering bargains. Every week, we fill your basket with the best of what the community is building (and this time, we actually checked the price tags).

Plus…

• The State of Platform Engineering Vol. 5 survey is open! Your answers shape the next State of Platform Engineering report, and with AI shaking up pretty much everything, this one matters more than ever. Tell us what’s really happening in your platform team. Take the survey here.

Cost is going to be your problem. Here’s what to do about it.

Cost ownership is increasingly moved into the loving embrace of the platform team. We launched our first-ever FinOps market guide this week, and hot damn, it feels good to share that what we’ve been talking about in PW for almost 2 years is becoming more and more true.

Responsibility for AI and agent economics is still far from decided across the board. It often lands with FinOps, platform engineering, a dedicated AI leadership function, or engineering management, and evidence from the field shows every permutation - but when we compare trends across all our research and the best teams. My gut tells me it’ll be us who owns it.

The only way to control spend in the AI era is to shift it into the platform. This won’t be our last market guide - and you know I’ll be watching this closely.

But the market guide is much more than that. Florian, Dilek, and I dug into what this new frontier means for platform teams. The big takeaways:

• Shift down, not just left (shocker!). A cost estimate in the PR is nice, but it’s one more signal for an already overloaded dev. It’s no surprise that only 39% of respondents actually enjoy FinOps work. Encode the sensible default into the golden path so nobody has to decide, and you improve both your cost outcomes and the general happiness of everyone involved.

• Your bill goes way beyond the cloud. Beyond public cloud (84%), 41% of respondents also manage AI tool spend and 38% manage SaaS. A financial layer that only sees cloud billing is blind to whole categories of what you answer for.

• Fewer tokens doesn’t mean better. I might love caveman as much as the next guy, but use little token, but no use brain, maybe big problem. If you cut tokens by over-compressing context, limiting experimentation or blocking teams from delivering value, you’re losing dollars to save pennies.

• Recommendations are cheap. Safe execution isn’t. 77% rank workload optimization and waste reduction in their top three priorities for the next 12 months. But a priority doesn’t cut a bill. What actually moves spend is action with rollback, SLO awareness, and graduated autonomy, not another endless list of recommendations that no one is going to read.

The important caveat in all of this. More spend does not automatically mean bad (Just as more spend in our Tokenmaxxing phase didn’t automatically mean good 6 months ago).

The CEO of Coder said on stage at our Platform Leaders Summit in Silicon Valley a few weeks ago that 1% of his engineers drive 40% of the company’s token cost, and 5% drive 80%. Are they wasting tokens? Maybe, maybe not. The point is that cost isn’t bad on its own. It’s a question of whether that cost is getting value.

A team spending four million to earn twelve million should invest more, not less. Unit economics is how you make that case to finance.

The full guide also maps the vendor landscape into five archetypes and lays out four moves for your platform team. Go grab it before your next costathon ;)

SHA pinning isn’t the security blanket you think it is

Whaaat? A second section in Platform Weekly? Let’s do this! I want to share something cool from my friends at Chainguard, who are running a community webinar on October 20th. There is more code than ever flowing through CI, and every run trusts third-party code someone else wrote. It’s the same problem in every conversation in every category, but security is where it’s most urgent to fix. More code means more runs trusting actions by version tag, and the go-to answer from a lot of platform teams right now is “pin everything to a SHA.” Voilà, problem solved. WRONG(ish).

A SHA is a tamper seal. It proves nobody opened the jar since you sealed it, but it tells you nothing about what’s inside. Seal a poisoned one (*cough* tj-actions/changed-files if you pinned mid-attack *cough*) and you’ll keep eating the poison over and over and over. And your sealed jar can still reach for other jars nobody ever checked ;)

The only way to solve the problem is by solving it before it’s a problem. Revolutionary! And the only way to do that is by building it directly into the platform. Take a look.

Register for the webinar

As always… stay crunchy 🥐

Quick bites

Other episodes

• Your agents are about to blow up your telemetry bill

• Nvidia, OpenClaw, and why your platform team matters more than ever

• Should you force teams to use your platform?

• The State of AI in Platform Engineering is revealed.

• Is your platform a platform? Path to outcome explained

• Your telemetry bill is growing. Your answers aren’t.

• 200 weeks of platform weekly

Hey there! Welcome to Platform Weekly. Your weekly drizzle of platform engineering maple syrup. Every week, we pour the best of the community’s thinking over your Friday stack (no pancakes required).

Plus…

• AgenticCon is coming! It is our new conference focused fully on the AI platform teams building, shipping, and delivering INSANE value with agents and agentic engineering. Join us in San Francisco on February 25 if you own your company’s agent infrastructure. Get super early bird tickets here. I am so excited for this!

• Did you miss my webinar with Kelsey Hightower, and Dan Ciruli from Nutanix? It was an awesome conversation where I unpacked with them why AI is just another workload, how to secure agents, and what it all means for platform engineers.

Your agents are about to blow up your telemetry bill

For the last few years, telemetry volume has creeped its way up and up and up, but we just about managed to optimize our way around it. That has all changed. Fast.

The economics of telemetry are breaking. Agents aren’t just creepin, they’re stomping all over a problem that was already getting harder to manage. Just look at these numbers.

• 28-40% annual growth in telemetry volumes, while IT budgets stay flat

• 2-5x more telemetry from each LLM query than from a standard application log event

• 10-100x the query load AI SRE tools can put on observability endpoints when they chase parallel hypotheses

And at the same time, 57% of practitioners say their observability setup is too noisy or doesn’t help them find the root cause… ouch.

These stats are from our Market Guide for Observability Trends in Platform Engineering and were shared in Tuesday’s community webinar (alongside how to combat them) by James Conway & Bill Emmett from Cribl.

Agents investigate differently. A human mostly works through one hypothesis at a time. An agent spins up ten, spawns sub-agents, and fires queries at all of them at once. Every architecture and pricing model we’ve built over the previous decades assumed curiosity capped by human-speed. That just ain’t it anymore.

Every one of those agent queries burns tokens and hits your observability backend, and often every one of those queries spits out more telemetry that needs to be absorbed. This is a huge increase in noise and cost, often without enough extra value to compensate.

So what is the answer? Well, James from the webinar and I feel the same thing. You can’t just “buy more storage” your way out of this one. It’s twofold.

• You need to stop treating all data the same. He called it caviar versus peanut butter. Your detection tier gets the premium, indexed, expensive treatment. Your compliance and archive data gets spread cheap, but kept at full fidelity so you can replay it later. Only pay to analyze what’s actually worth analyzing.

• Then of course… you can’t solve Agent problems with human solutions. There is a reason 47.5% of teams are now (finally) embracing shift down. Shifting this down into the platform is the best way to manage the deluge of telemetry, to get actual actionable results, and keep costs down.

There was a final question in the webinar, I’d love to get your answer to - how many different data engines in your environment are storing the same log right now? Two? Three? Four?

If you’re not sure, go watch the webinar and learn how to figure it out.

There is a good chance you’re one of the around 50% who say cost or wrestling with AI is their biggest observability challenge, so if you’re looking for some big wins… I’d start there ;)

Tell us your about experience:

Read the full report

As always… stay crunchy 🥐

Quick bites

Other episodes

• Nvidia, OpenClaw, and why your platform team matters more than ever

• Should you force teams to use your platform?

• The State of AI in Platform Engineering is revealed.

• Is your platform a platform? Path to outcome explained

• Your telemetry bill is growing. Your answers aren’t.

• 200 weeks of platform weekly

• We wrote the book on platform engineering

Hey there! Welcome to Platform Weekly. Your weekly knead of platform engineering dough. Every week, we fold in the best of what the community is building, breaking, and arguing about.

Plus… The hottest party in cloud native. We’re taking over Salt Lake City during KubeCon, then Vegas during re:Invent this November. Will I see you on the dance floor?

Nvidia, OpenClaw, and why your platform team matters more than ever

Do you know what the most successful GitHub project in history is? It ain’t Kubernetes with an embarrassing 128,000 stars, or Linux with a measly 250,000. It’s OpenClaw. Ofc! The open-source agent control framework, with its total lack of any built-in security, governance or guardrails, the epitome of the AI yolomode.

60 days after its launch, as OpenClaw blasted its way to 350,000 stars and the top of the list, Jensen Huang announced on stage at Nvidia GTC “NemoClaw”. OpenClaw BUT with secure sandboxing, model routing, privacy, and lifecycle management.

Why? Because the world’s largest company sees what we have seen in the State of AI in Platform Engineering Vol.2

• Only 8% of teams are seeing transformational ROI with AI

• Barely 1 in 10 say the model is their biggest blocker to scaling with AI. (Guess what is the #1 blocker - platform readiness!)

• And a whopping 29% of platform teams are already having to serve agents as customers

There is a reason Nvidia, AMD, and more are spending billions on open source, releasing a deluge of composable stacks for platform engineering teams to use. And the reason gets increasingly clear when you look at the data. The teams that are succeeding with AI are not winning because they have better access to models or have the highest number of agents burning the most tokens in their orgs.

Mo agents, mo problems. Mo secure agents? Mo moolah

Let’s start with a quick refresher on the four levels of agentic development.

• Level 1: Human in the Loop. The human directs every step, while agents act as coding assistants that get prompted

• Level 2: Human on the Loop. Humans trigger the work. Agents produce complete code changes in parallel, and humans verify behavior and evidence rather than reviewing every diff

• Level 3: Human as Orchestrator. Agents run continuously behind automated validation loops and CI/CD gates, and the platform starts generating work from signals. Humans only get involved when something blocks or fails.

• Level 4: Human outside the Loop. Still emerging, and so far only in narrow domains. Agents pick up signals themselves (bug reports or production alerts etc) and fix and deploy on their own. Humans design the boundaries they work within.

It’s a mistake to think that the primary difference between level 2 and level 4 is that L4 has “mo agents”. The difference isn’t that there are more, it’s that the conditions exist for more agents to be made, and used safely and securely.

Think through what has to exist for level 3 and 4 to be possible. You need governed, machine-executable paths. You need agent identity, sandboxing, clean data guardrails, effective context engineering. It’s an order of magnitude more, though, than at any level below. It’s not the realm where you can simply RBAC your way out of problems.

It’s also the realm where all the value comes from. Bolting an agent like OpenClaw onto your existing workflow barely makes a difference compared to just prompting in Cursor. That’s still Level 1 and 2 territory.

But once you are able to enable full agentic development, the rate at which you can deliver value supercharges (and will continue to do so) as most orgs start with enabling a few core teams before expanding out across the entire enterprise.

If it’s not clear from all this already. All of this tells us that the platform team is more important than ever before. It’s you and your team that will enable agents in the enterprise, that will provide the platform and the paths that let them deliver the kind of value the 8% seeing transformational ROI are reporting already.

And if Nvidia spending billions, and my words here in Platform Weekly aren’t enough to convince you.

Well, you’ve got another 3,500 words diving deep into all of this to make it crystal clear what’s happening, why it’s happening, and how you and your team can make the most of it.

So go dive in. The future is literally yours! Hell yeah.

Read the report

As always… stay crunchy 🥐

Quick bites

Other episodes

• Should you force teams to use your platform?

• The State of AI in Platform Engineering is revealed.

• Is your platform a platform? Path to outcome explained

• Your telemetry bill is growing. Your answers aren’t.

• 200 weeks of platform weekly

• We wrote the book on platform engineering

• A brief tokenomics masterclass

Hey there! Welcome to Platform Weekly. Your weekly drizzle of platform engineering syrup. Every week, we dig into the conversations, research and ideas moving our community forward.

Plus…

• Our new free course is live! Developer Portals for Platform Engineers is one hour on what breaks first when AI is doing a real share of the work, and how to keep ownership, reliability, and security from falling apart when it does.

• Annnnnnd we had PlatformCon Paris this week. What a day! It was great to give the keynote with Manuel Pais, a big thank you to all the Parisian platform engineering community for coming to the book signing. Platform Engineering is entering its agentic era, and Paris you’re definitely onboard.

  

  

Should you force teams to use your platform?

It’s a golden era for research into the platform engineering space. In this week’s Platform Engineering community webinar, Sam Barlien (who co-authored our State of AI in Platform Engineering report with me) interviewed Dr. Charlotte Fleming from Octopus Deploy on their new report, “The Future of Platform Engineering.”

And the insights are pretty interesting…

Getting adoption on your platform has always been a tricky subject. It’s not enough to simply build it and hope they come, while mandates have tended to be a sign of an immature platform. The thing is - mandates are a tool in the tool box. And we see that becoming even more clear, particularly when it comes to enabling AI.

• 62.2% of teams with mandated platforms report their platforms better achieve their goals, compared to just 27.5% of teams with platforms without mandates.

• 78.9% of mandatory platforms are confident their budget will be renewed over the next five years.

• Yet platforms without mandates are now the majority at 54.1%, up from 37% last year.

So is mandating a silver bullet for becoming a successful platform? If only things were so easy;)

In Thinking in Platforms, Kaspar and I talk about carrots and sticks. Carrots are the reasons teams choose your platform. Sticks are orders from above, and they can badly backfire. Our advice is to disguise your sticks as carrots. Rather than punishing teams who aren’t on the platform, reward the ones who are.

Make policies mandatory, and let the platform earn its place.

And that matters even more with AI. In the State of AI in Platform Engineering Volume 2, the teams pulling ahead are the ones whose guardrails, identity and cost controls live in the platform. That makes your platform the easiest way to use AI safely. Which is about the juiciest carrot you’ll ever get.

So does this finding give you carte blanche to mandate your crappy platform? NO. But if your platform drives clear wins and adoption still isn’t moving fast enough, a mandate can be the catalyst.

But are mandates the only takeaway from the report? No shot.

• Platforms that have been running for 3+ years are 2.4x more likely to be a platform that achieves (Not a surprise with the journey of MVP to IDP to AEP.)

• The most common number of features a platform team owns jumped from 4 to 23 in a single year (Don’t you just love when the data corroborates your slogan? #PlatformEngineeringEatsTheWorld)

• Slack and Teams channels are both the #1 most used and #1 least effective way to get platform feedback (42.2% of teams still rely on them as their main source of feedback…)

Read the report

Go watch the full conversation with Sam and Charlotte, and download the report, then send them to your team, your boss, and your whole family.

As always… stay crunchy 🥐

Quick bites

Other episodes

• The State of AI in Platform Engineering is revealed.

• Is your platform a platform? Path to outcome explained

• Your telemetry bill is growing. Your answers aren’t.

• 200 weeks of platform weekly

• We wrote the book on platform engineering

• A brief tokenomics masterclass

• AI didn’t break your security. You’re just doing it wrong.

Hey there! Welcome to Platform Weekly. Your weekly survey of the platform engineering landscape. Every week, we zoom into another spot in the platform engineering universe, from best practices to community updates and more.

Plus… Google’s bringing its agentic enterprise platform event to London & Paris.

The State of AI in Platform Engineering is revealed.

How do you condense the impact of the fastest adoption of a new technology in history into one report?

The first draft of the State of AI in Platform Engineering Volume 2 was 25,000 words. We went deep on every topic you can imagine, from regulation to observability, to security and agent control planes, and more and more and more. But if you say everything, you say nothing.

So, we condensed the AI & platform engineering universe to five core questions:

• What are platform engineers doing with AI?

• Is the industry achieving ROI?

• What are the fundamental challenges facing platform teams?

• Why are some organizations achieving 10x the results of others?

• What can we expect from the future?

The report answers all of them.

Read the report

What are platform engineers doing with AI?

Last year, we defined the AI implementation plateau, the stage where organizations stop seeing rapid gains from AI adoption and face slower ROI, integration hurdles, and the need for actual cultural or organizational change.

What we saw was that, though basically everybody was using AI, they were overwhelmingly just using it for generating code, writing docs, and sending emails. And that meant that most teams very quickly plateaued from the crazy, exciting gains they saw in the first months (and expected to continue), as basic chatbot usage didn’t really deliver the Day 2 ROI they were hoping for.

But things are changing fast. Code Gen and Docs might still be #1 and #2, but more complex use cases like IaC generation and log analysis and debugging, and data analysis have massively increased in the last 12 months.

Is the industry achieving ROI?

Technically… yes. But not really in any way to write home about. 1/3 report either incremental efficiency gains or operational savings; another 1/3 are still in their experimentation phase, while 14% are seeing negative gains. The outlier? And the position we all want to be in… 8% are seeing transformational ROI.

These numbers, at face value, don’t seem particularly inspiring. Remember, it was only last year that MIT reported 95% of AI pilots saw zero ROI. Our data is pointing in the same direction.

The industry is maturing. Teams are seeing value. And some teams are operating at a level that would have been impossible to imagine just a few short years ago.

What are those teams doing?

Why are some organizations achieving 10x the results of others?

If you’re a long-time reader of our reports, it’ll probably not come as any surprise to you. The winning teams are increasingly the ones with the better platform, not the better access to models or higher AI adoption. And not just a platform for developers using AI.

They evolve their IDP into an Agentic Engineering Platform to serve agents as a first-class user. That means governing their identity, their spend, and enabling them to work autonomously to deliver insane business value.

And the industry gets it too. When asked what’s the main thing stopping your team from scaling AI? 27% of you said platform capabilities. And only 1 in 10 named the model.

Isn’t it great when the data proves what we’ve all known?;)

And all this is just the beginning. In the full report, we break down the four levels of agentic development, what your platform should look like, our predictions for the future, the main challenges facing teams, how to break through them, and so much more.

Download the full report and get it all!

Download the report

As always… stay crunchy 🥐

Quick bites

Other episodes

• Is your platform a platform? Path to outcome explained

• Your telemetry bill is growing. Your answers aren’t.

• 200 weeks of platform weekly

• We wrote the book on platform engineering

• A brief tokenomics masterclass

• AI didn’t break your security. You’re just doing it wrong.

• Your platform was built for a different era

• How the hell to build an agentic development platform?

• Your platform won the argument. Now it has to evolve

Hey there! Welcome to Platform Weekly. Your weekly reduction of platform engineering noise. Every week, we boil down what’s actually worth knowing, cut what’s fluff, and flag what will bite you later.

Plus… Kelsey Hightower will be at PlatformCon’s Live Days in San Francisco this February and New York this June to open the discussion on our role as humans in the next era of platform engineering. Get your tickets before early bird pricing ends on September 15.

Does your platform deliver outcomes, or just output?

Is your platform actually a platform? Here is a test. Ask yourself - does it produce output, or does it produce outcome?

I was scrolling on LinkedIn a bit ago, and saw a great (I’ll humbly say) post on LinkedIn about Kaspar and I’s new book Thinking in Platforms. Rob, a Solution Architect, described his platform’s own journey moving from an early Backstage-based IDP built for discoverability and a decent portal experience into a fully fleshed-out internal developer platform. It’s a platform that delivers outcomes… not just a bunch of output.

That’s the exact distinction the whole Paths to Outcome model exists to make.

It is the why to stay focused on platform capabilities that actually create value. And built the model based on our work with you all across 100s of platforms, and it is proven in practice.

Output vs outcome

So why did Rob’s new platform make such a difference compared to one based primarily around Backstage? Because an interface, a portal, is simply where you “ask”. It doesn’t produce anything itself. It’s just the door. Ask through it, and the platform’s capabilities do the work and hand something back. A list appears, a database spins up, generated code comes out. That’s output. And output alone is not the goal, the goal is getting outcomes.

Outcome, for example, is a feature that ships and brings value, or measurable increases in productivity; it’s money in the bank, etc. A beautiful catalog listing fifty services is just output unless it directly taps into the value stream in a measurable way.

An example you will be immediately familiar with. You have a tool now that produces 10x the amount of code you ever thought possible. Output is up 2x. Have your feature delivery gone up 2x? Metrics, your revenue? Most likely… not.

This difference is fundamental to understanding the importance of successful platform engineering, ESPECIALLY, in the AI era where output is up 2-3x in many organizations.

This is the simple path model from the book. An interface takes the request, a capability delivers on it, and an output comes back.

The interface is where the intent gets expressed, the capability is what delivers and brings the output.

The capability has two layers to it - a promise, stated in outcome language (”provide a runnable test environment”), and an implementation, whatever databases, APIs, or agents currently deliver on it.

Your platform should revolve around those kinds of promises.

Now, looking at capability. A single well-designed capability is still just a capability. Outcome only shows up once you map your paths against a value stream, the actual end-to-end flow of someone’s work. How does providing a runnable test environment faster and more on-demand create real value? That’s something your team needs to know, otherwise, how can you decide whether that capability should be built or maintained?

Here’s what that looks like drawn out, one team’s actual feature-development flow, every point where a path drops in to hand something back.

This is an example feature-development value stream. Paths drop in at each point a team needs something back before continuing. A map like this is also your filter. Some of your paths contribute to real outcome, work that visibly moves the value stream forward. Others only ever produce output, busywork that looks productive but never actually feeds the stream.

The game is about building platform capability around the second kind. Every hour spent polishing a capability nobody’s outcome depends on is an hour not spent on a path that does.

You decide what capabilities to build, or keep building, based on the paths that produce outcome, not the ones that just produce output.

So what do you do with this on Monday?

I’ll let you have the weekend to rest. But Monday, it’s go time. Pick one path. Just one. Ask the question. Does output contribute to the value stream or not? Simply, does it produce an outcome?

If you can’t clearly answer that, then that path is not a good use of platform capability or your time.

Rob’s journey didn’t start with their fleshed-out IDP. It started with a portal, a few hard years of learning what devs needed in the moment they needed it, and a deliberate move from cataloging things to promising outcomes. That’s the whole model, compressed into one LinkedIn comment. The rest is just building it.

As always… thank you, go read Thinking in Platforms to go far far deeper (and wider) & of course stay crunchy 🥐

Quick bites

Other episodes

• Your telemetry bill is growing. Your answers aren’t.

• 200 weeks of platform weekly

• We wrote the book on platform engineering

• A brief tokenomics masterclass

• AI didn’t break your security. You’re just doing it wrong.

• Your platform was built for a different era

• How the hell to build an agentic development platform?

• Your platform won the argument. Now it has to evolve

Hey there! Welcome to Platform Weekly. Your weekly scan of the platform engineering radar. Every week, we round up what the community is building, breaking, and arguing about.

Plus…

• Datadog broke down for us yesterday exactly how good incident management is done in platform engineering. One of our most in-depth webinars yet, on exactly what you need to do to succeed.

• If you’ve also overspent on AI infrastructure without getting the promised value, you’re not alone. Kelsey Hightower from Google is joining us to break down what enterprise AI infrastructure actually looks like in production. You can register for the free webinar here.

AI is changing observability forever

For years I’ve said that observability is a quality problem wearing a scale problem’s outfit. But for a long time, we never got much opportunity to deep dive into proving whether that was the case. Now, with observability becoming a platform problem basically everywhere, I got the chance to go deep.

A few weeks ago, we published our first ever market guide, Observability Trends in Platform Engineering. It was based on survey data and EXTENSIVE interviews. And I mean extensive. Let’s just say there’s a lot of observability folks who aren’t going to hop on a “casual” coffee chat with me anytime soon. We spoke to every vendor under the sun, big enterprises, practitioners, team leads with 100m budgets. Everybody.

Now there’s no way to summarise 11,000 words of gold in one short Platform Weekly. But let me give you some of the juice so you know it’s worth diving into.

• 28 to 40% annual growth in telemetry volume, while IT budgets stay flat across the board.

• Every LLM query throws off 2 to 5x the telemetry of a standard app log event, while an AI SRE chasing 10 to 12 hypotheses at once is generating 10 to 100x the query load we’re used to.

• 57% of you say your setup is either too noisy or does not point at root cause

• As a response to this, 80% are on OpenTelemetry now, with 37% having fully replaced proprietary agents and 43% running hybrid

• BUT 58% name the skill gap between developers and SRE as the biggest cultural blocker to owning observability as a platform capability

Dilek Altin, Sam Barlien, and I unpacked a lot of this in a community webinar. Going through the highlights and detailing how observability is one of the clearest domains becoming a fundamental platform capability.

Let’s dive into some of that data.

OTel has gone massively vertical. And for good reason. if its agents reading your traces, standardization is do-or-die. Basically all LLMs are trained on OTel semantic conventions, which means an agent investigating an incident knows exactly where to look. But only if those conventions are actually enforced. Get that right at the Collector and your devs never have to think about instrumentation again (hopefully). That’s a massive massive boon. So it’s no surprise that OTel is becoming the de facto standard.

But this is not happening in isolation. Nobody is going to teach every dev cardinality management when agents deploy thirty services before the first smoke break. One dev adding a user ID to a metric can multiply your time series by orders of magnitude and nobody is going to catch that in a pull request at the speed that agents move. Either the load gets shifted down and the platform absorbs it by design, or nobody does.

This is a massive change from just a short time ago, when observability was still treated as a separate universe to platform engineering.

Which brings us back to that 58%. And to be clear, the skill gap isn’t a hiring problem. No one we talked to was saying they just need to hire new people with these skills. Basically, no one has the skills yet. We’re in a new frontier. It’s a paved road you haven’t paved yet. But it’s also something that’s very surmountable. We’ve got one course out on this already. And another course specifically on the OTel Collector coming soon.

Key thing to understand in all this. The cost blowout, the noise, the agent load and the skill gap are not four different problems. They are 1 problem wearing four hats, and the fix to all of them is the same thing. The platform. So here’s what you need to do on Monday.

Pick one service. Count how many observability decisions a developer had to make to ship it. That number is your backlog.

Then go and read the guide. All 11,000 words of it. Or… you watch me break down in 45 minutes. Depends how much this all matters to you 😉

Read the guide

And as always… stay crunchy 🥐

Quick bites

Other episodes

• 200 weeks of platform weekly

• We wrote the book on platform engineering

• A brief tokenomics masterclass

• AI didn’t break your security. You’re just doing it wrong.

• Your platform was built for a different era

• How the hell to build an agentic development platform?

• Your platform won the argument. Now it has to evolve

Hey there! Welcome to Platform Weekly. Your weekly lap of the platform engineering track. Every week, bring the latest and greatest from the platform engineering universe from community updates, to best practices and more.

Plus… We’re hosting an executive forum with Coder in Santa Clara – don’t miss it!

200 weeks of platform engineering

We’ve just announced PlatformCon 2027. And I couldn’t be more excited.

200 weeks ago, I sat in a cafe in Paris, talking to a friend about how badly I wanted to start a newsletter on what I was seeing around me in the world of platform engineering. He replied “So… make one yourself?”

This is issue 200.

I had a sense we’d last this long, what I didn’t think was how much the topics would evolve. The early days was arguing about whether platform engineering existed at all. Was DevOps dead? SRE rebranding? Was it worth embracing the discipline?

Then it flipped. Each week stopped being about “what” to “how”. Enabling product thinking. What paths people should walk. All the unsexy security work. Tasty.

And now the questions are about agents. Where they run. Who pays for their tokens. What happens to your platform when you get 100x the users and they are all tasmanian devils.

It’s the same discipline but bigger and bigger and more important than ever. And nothing captures that better than PlatformCon.

Why attend PlatformCon 2027?

PlatformCon 2026 was ridiculous. Around 1,800 of us came in person in London & New York, and almost 50,000 joined online… We had Gregor Hohpe on platforms defying the laws of IT physics, Patrick Debois arguing that context is the new code, Kief Morris on humans on the loop, Kelsey Hightower dragging us allll back from the blind euphoria with Zero Token Architecture (Our first vid to hit 100k views!), Jay Moran from Fiserv on what golden path scaling looks like inside an actual real enterprise, and Bruno Passos & Mansi Mittal on Booking.com’s GenAI platform journey.

The most important thing to me goes beyond that. Most of the talks across the entire event were STILL on getting IDP foundations right. In the biggest year for AI yet - most of the community still spent their time focused on the paths that make it all work. That proves to me what I have felt so strongly. Things are moving fast, and yes, we are moving with it, but we are still the ones building the foundations that hold this whole agentic house up.

What came from 26

• 300+ hours of talks and workshops came out of it. Even I still have 20 tabs over of talks to watch.

• The executive breakfasts, the platform clinics, the therapy sessions, the massive queues at the book signings, and ad hoc chats with every platform leader under the sun from Kelsey Hightower, to Nicki Watt, Patrick Debois and Gregor Hohpe

• I talked to over 300+ of you across the week to give advice on how to make sure your IDP is ready for agentic workflows, and how your IDP needs to evolve.

So why will 2027 be even better? (again)

This year, agentic engineering was new for 95% of the audience, with new concepts and new evolutions. By June 2027, a lot of you will have built platforms, broken them, and learned things that nobody could know today. PC26 was the year we got specific on an agentic future. PC27 is the year we get evidence.

Tickets are available now with a super early bird price of £99 in London and $99 in New York, against £499 and $499 at full price.

Two hundred PWs! Thank you for reading them, for replying to them, and being on this journey with me.

Come do it with me in June. London or New York.

And as always… stay crunchy 🥐

Quick bites

Other episodes

• We wrote the book on platform engineering

• A brief tokenomics masterclass

• AI didn’t break your security. You’re just doing it wrong.

• Your platform was built for a different era

• How the hell to build an agentic development platform?

• Your platform won the argument. Now it has to evolve

Hey there! Welcome to Platform Weekly. Your weekly pour of platform engineering concrete. Every week we take the community's loudest debates, hardest lessons and best ideas and turn them into one email worth your Friday coffee.

Plus… It's your last chance to have a say in what platform teams actually need. Take the survey!

We wrote the book on platform engineering

My book compiling everything we have learned and stressed tested over the last 10 years is out now - Thinking in Platforms!

If the platform is the prerequisite to succeeding in the AI era, which we now know is a fact, then the question is… what do YOU do to enable this? That is the goal of the book. It tells the story of platform engineering, and then goes deep on the frameworks and principles we believe are key to succeeding with it (from IT and beyond)

This newsletter is a snapshot of what we break down in extensive detail in the book.

The wrong way

Every organization already runs a production system, designed or not. My favorite example is with cars 100 years ago. In Detroit, 1903, it’s all ad hoc workshops, one main hot shot guy assembling the car. By 1906 Henry Ford asks the better question. “Why don’t we treat the production system itself the same way we think about the product?” As an evolutionary process that we learn from, evolve and develop continually with feedback. The rest is history.

We can think about our production systems in IT the same way we’ve done in industry. To start down that path, we identified four archetypes of production systems. You will recognize all of them from your org (and your daily life too).

They are artisanal, hero-based, bureaucratic, and platform-based.

Artisanal, all informal coordination and negotiation, think of the workshop where every chair is bespoke and no two use the same screws. Hero-based, where the system relies on that one engineer who owns deployment and can turn up asking you to double his salary. You pay. They leave anyway. Huge disaster. Bureaucratic (*cough the post office *cough), predictable, and failing very predictably, with a compounding cover your ass policy from basically everyone everywhere. Platform-based, where the production line itself is the product.

In your org, you probably have many of these patterns. And some will even rise to resolve the gaps in others. The hero engineer stays up late so the artisanly designed feature can hit the deadline. The leadership team puts in new “bureaucracy” in the form of approval gates to prevent AI compliance issues.

Does that mean then the goal is to assembly line everything? NO. The goal is to standardize freedom of means, but never standardize freedom of output. Let’s zoom in on that.

The right way: paths

You know that a platform is not an interface you can look at. What it is instead is users walking the same routes over and over, like students wearing tracks into a university lawn until somebody pours concrete on the most destroyed one. This is what for years we’ve called the golden path.

A path is one of those routes made deliberate. A user turns up with a single intent and the path serves it end to end. That is the molecular unit of a platform. The input is the ask itself. Think “give me a small Postgres database”. The interface is where the ask goes in, a portal, a CLI, a pull request etc. The capability is what actually fulfills it. The output is the database that gets handed back.

Capability really just means capability. It doesn’t mean specific tool or tech. It could be Terraform today, Crossplane next quarter, but the promise of the capability doesn’t change.

Then you stack them. One path gives you something. Many paths give you an outcome. That is what we define as the paths to outcome model, and it is the first framework that lets you draw your platform and take it forward not just to your boss for funding, but to actually securing adoption, and delivering value.

It also massively shrinks your problem. Teams assume they have 100s & 100s of paths, but it just isn’t true. A database is one path that accepts a few inputs. Count honestly and software regularly lands at 20 or 25 paths. That is a number that is knowable and manageable, and can become an immediate backlog you know will take you where you need to go.

Here is a model of exactly this - and we’ve drawn it for non-IT intentionally to really emphasize. This is NOT about specific tech and tools.

And where does AI play into this?

Well, everyone has seen a super dope day 1 agentic demo, and then right after hit the wall of “how do I actually make it day 100 ready?” If agents are users now (and they increasingly are), they need clearer paths than any human, ever. The agents have to run somewhere, and your role as the platform engineer is to build the platform for them too.

There are “platform engineers”, though they often aren’t called that yet, doing this in all kinds of organizations from marketing to legal, finance and ofc in our world of IT. The framework is exactly the same.

The playbook

This is a lot. I know. So part 3 of the book breaks it all down in detail. It’s roughly 80 pages of practical information. Minimum Viable Platform, then production readiness, then scaling. But mostly it is on helping you subtract. How to ask why until you reach what is actually essential, which is always way less than you originally think it is. How to identify that one team, a few paths, real users.

And to close off here with something I’d always dreamed of saying. You can get my new book Thinking in Platforms here.

As always…thank you & stay crunchy 🥐

Quick bites

And that’s a wrap on this week! As always, this newsletter is a community project. So if you have anything awesome to share from the cloud-native world, send it my way.

Stay crunchy 🥐
Luca

Other episodes

• A brief tokenomics masterclass

• AI didn’t break your security. You’re just doing it wrong.

• Your platform was built for a different era

• How the hell to build an agentic development platform?

• Your platform won the argument. Now it has to evolve

Hey there! Welcome to Platform Weekly. Your weekly top-up of platform engineering tokens. Every week, we round up what the community is building, arguing about, and quietly panicking over.

Plus… It's your last chance to fill in the State of AI in Platform Engineering survey!

Everything you need to know about tokenomics

Software is and has always been priced by capacity. The servers you bought, seats you licensed, or the engineers you hired. All of it is paid based on the ability to do work, irrespective of whether the work actually happened or not. Tokens price something else. They price attempts. A developer pre-AI who manually tries five approaches when coding themselves costs exactly the same as one who nails it first time. That’s because you bought their time, not their effort. While an agent that tries 5x costs five times as much.

Foundational tech often arrives underpriced. Railways, bandwidth, cloud, all sold cheap enough to make adoption. Add an exec AI mandate above all that and you get one of the funniest and trickiest trends of the last 12 months - tokenmaxing. Devs burning tokens as fast as they can think (or not thin;), partly to learn and partly because visible AI usage pretty rapidly became a proxy for being good at your job. Lol.

Well, that bill has well and truly arrived.. Orgs that never thought about the cost of a thought are suddenly trying to forecast it, attribute it and cap it, all at the same time. That’s AI tokenomics.

So how are teams handling it?

A sneak peek at the most recent data (survey is still live! Answer it) from our upcoming State of AI in Platform Engineering report:

• 36% have centralized billing or FinOps oversight behind their AI spend

• 21% enforce rate limits or token quotas

• 16% distribute costs to individual teams

• A quarter either don’t track token spend at all, or don’t know whether anyone does

Which brings me to the report recently put out by our own Sam Barlien and Pankaj Gupta of Broadcom. Their answer is an obvious but simple one. You don’t need a spreadsheet or a new fancy tracking tool. You need to think about spend as a platform component.

We identify this in the audit and attribution section of agent observability in the ADP.

What audit and attribution should do:

• Attributes every token call to a team, a path and a model, so all spend has a clear owner

• Watches spend velocity rather than spend totals, because the rate of change Itself is often the most important thing.

• Enforces hard limits in the platform, so a runaway loop doesn’t blow you up, cost-wise.

• Produces its own audit trail, which is also the same evidence regulators will ask for anyway

Cost needs to stop being for finance to report on and become something the platform enforces instantly and by design. If your platform cannot tell you which team spent what, on which model, this morning, that is your gap to close asap.

And then the boring part;) And we know the boring stuff is the important stuff. Default idle workloads to zero. Cache what you have already paid to compute. Route cheap work to cheap models. Not so sexy, but ya do what ya gotta do.

This is the FinOps discipline platform teams already have, but pointed at probably the only resource in the world that decides by itself how much it costs and how much it wants to spend. And guess what? It always wants to spend more.

So don’t let it.

Quick bites

And that’s a wrap on this week! As always, this newsletter is a community project. So if you have anything awesome to share from the cloud-native world, send it my way.

Stay crunchy 🥐
Luca

Other episodes

• AI didn’t break your security. You’re just doing it wrong.

• Your platform was built for a different era

• How the hell to build an agentic development platform?

• Your platform won the argument. Now it has to evolve

Hey there! Welcome to Platform Weekly. Your weekly pour of platform engineering cold brew. Every week, we bring you the best insights, tools and stories from across the community.

Plus…

• Thinking in Platforms, the book Kaspar and I have been writing for the past year, is out August 18!

• Last chance to have your voice heard in the State of AI in Platform Engineering! Answer the survey and shape one of our biggest research pieces yet!

Your coding agent is only 1% LLM

It is incredibly easy to spin up a next level day 0 AI demo that blows your mind. While everyone, everywhere, all at the same time is failing to scale it to day 100 success. That’s why we’re going into the belly of the beast with our new conference double launch - PlatformCon San Francisco, and a new format entirely AgenticCon, on February 24th and 25, 2027.

If you dissect the source code of one of the most popular coding agents out there, you’ll see that of its roughly half a million lines of code, roughly 1% actually touch the model. The other 99 is deterministic platform work. That’s loading context, routing capabilities, enforcing guardrails, verifying output etc.

So, is it any surprise then that when the majority of organizations still see AI as merely adopting a copilot - most orgs aren’t seeing any ROI? Writing code is maybe 15 to 20% of shipping software in a large enterprise, so a 20% coding speedup nets you around 3% overall. Lame. At the same time, all your competitors have the exact same licenses and same tooling, so even if we take that gain as gospel - at the end of the day, it’s meaningless.

So what then is the durable gain that AI actually provides?

The durable returns live one layer down in the harness, the governance, and the context that your org itself owns.

That layer is what we are dedicating an entire conference to. AgenticCon is happening February 25, 2027 in San Francisco, co-located with the PlatformCon SF live day on February 24. Two days, one stack, one registration. Day 1 covers platform fundamentals and the path from IDP to ADP. Day 2 goes deep on the agent infrastructure layer that every agentic workflow in the enterprise runs on.

So what’s actually on the map?

The whole event is built dissecting and disseminating the best practice in the agent infrastructure layer. Part of that is helping clear up a few things on these three ideas, nested one inside the next:

• Platform engineering is the art of building agentic platforms, the whole system many agents run on.

• Harness engineering is the art of building one agent’s operating system, a layer inside the platform.

• Loop engineering is the art of tuning how work flows through the platform until it produces repeatable outcomes.

They are not synonyms or contradictory concepts, but a matryoshka doll of AI success.

This logic is the same if you’re building an agentic development platform for writing software, or an agentic finance platform that your company’s accounts use every day.

So first zoom out and see the platform. The widest lens. An agentic platform stacks three layers:

• Tooling on top. For software development that might be Backstage or GitHub, but remember, we aren’t just talking about IT platforms ;) so marketing might run on a CRM and analytics manager.

• Path specs under that. The repeatable actions and agent rules, all either agent-driven and probabilistic, pipeline-driven and deterministic, or hybrid agent plus gate.

• Agent infra at the base, shared by everything above it.

No matter the domain from finance, marketing, or software, which we know and love, the agent infrastructure below is the same.

Now let’s zoom in on the harness. One agent’s operating system for a single spin. Context gets assembled, capabilities get resolved (think tools and MCP servers), execution happens in the sandbox where the model reasons, evaluation gates the output.

(As a platform engineer, you build the harness too. And of course. the governance you set wraps it.)

And finally, zoom into the loop. Work triggers, loads its path, assembles context, reasons, calls a tool, hits a gate. Gate fails? It enriches its context and goes again until the outcome ships. Loop engineering is the work of tuning path and platform until loops land repeatable outcomes.

trigger → load path → assemble context → reason → resolve capability → call tool → hit gate

We’re in that beautiful stage of technology where the knowledge and the winning formulas are out there. We just need to bring it all together in one room. So that’s what we’re doing.

Super early bird is open now. See you there!

Get Your Tickets

Quick bites

Highlight of the week

• Observability + Platform Engineering: The Market Guide

From the community

• Want to catch the PlatformCon talks and workshops you missed? We’re adding more every week to the community YouTube channel.

And that’s a wrap on this week! As always, this newsletter is a community project. So if you have anything awesome to share from the cloud-native world, send it my way.

Stay crunchy🥐

Luca

Plus… we published a market guide for observability in platform engineering! I’ve been working on this for months and interviewing many many of you so go give it a read:)

And our first week on Substack! How exciting;)

10 ways to survive the vulnerability apocalypse

AI didn’t make your software less secure.. Crazy seeming statement I know especially considering the recent news of OpenAI and Anthropic agents going rogue and hacking people. But it’s true.

AI just made vulnerability discovery cheap. Awareness of vulnerabilities is up 10x. And that is only going to get worse. I’m sorry to say this isn’t a one-off wave. I’ve heard folks argue that we’re in the chaos now, but eventually AI will “discover them all”. As if that were possible. I hate to say it… but this is the new normal.

This week’s community webinar with Ashley Ward from Minimus on surviving the AI driven vulnpocalypse breaks down exactly what we are dealing with and how we need to respond to it

It’s Little’s Law in practice. The rate at which we clear tasks is outpaced by the rate at which new tasks arrive. But what does this mean for us? It means that security becomes an operational question, not purely a security team one. The old paradigm isn’t enough. We need to build the systems that can grow and handle an ever increasing rate of vulnerabilities automatically and by default.

Ashley walked through his platform engineer’s checklist for this.

1. Reduce the software. The cheapest vulnerability to fix is the one you never ship. Minimal images, secure base.

2. Know what you’re running. If you aren’t generating SBOMs as practice then i don’t know what to tell you…

3. Verify identity. Sign your images, and put gatekeepers in front of whatever’s allowed to run.

4. Don’t run as root. You know this one. Do it anyway.

5. Stop lateral movement. Network policies plus a real threat assessment. Your frontend shouldn’t ever really be talking to the db should it?

6. Runtime detection. The crown jewels need to live where things actually run

7. Immutable deployments. If you’re still SSHing into containers, this one’s for you…

8. Continuous scan prioritization. CVSS alone tells dirty lies. You need to be thinking reachability and business context to figure out what’s actually urgent.

9. Rebuild automatically. Recovery must become a totally routine platform capability.

10. Measure resilience. You need to be thinking rebuild time and recovery rate (not measuring against scary colours in a dashboard)

But the most important thing is to reframe how you think about security. STOP asking “how do we fix this vulnerability?” and start asking “how do we make this whole class of problems cheap to deal with forever?” That’s the gap we need to close.

Check out the webinar itself. Ashley goes deep on each move.

Quick bites

Highlight of the week

• Platform Clinic in the age of AI: Fix what’s not working, identify new investments

From the community

• Want to catch the PlatformCon talks and workshops you missed? We’re adding more every week to the community YouTube channel.

And that’s a wrap on this week! As always, this newsletter is a community project. So if you have anything awesome to share from the cloud-native world, send it my way.

Stay crunchy🥐

Luca

Plus…

• If you missed it, Platform Weekly is in the process of moving to Substack! So don’t be confused or surprised when the changes start coming into effect;)

• I wrote a book, Thinking in Platforms! If you haven’t had a chance to take a look or pre-order it. You can find it here. It’s the culmination of almost 10 years of platform thinking and development. I’d love to hear your thoughts.

Your platform was built for a different era.

I had five different versions of the same conversation last month. An exec going crazy over token bills. A security platform engineer staring down the EU AI Act & CRA. A platform lead whose data scientists needed GPUs yesterday. Different people, different rooms, and somehow the exact same problem. Platform Weekly has been touching on each of these issues over the last couple months again and again…

Your platform can probably handle any one of these. What it was never built for is all of them hitting you in the face at once. Every one of them is really just a fresh way for the cost of chaos to show up on your platform.

That convergence is exactly what our own Sam Barlien and Pankaj Gupta over at Broadcom dug into for their latest whitepaper on the future of platform engineering, and unpacked live in a new community webinar yesterday. They name the 5 forces that are hitting (or will be hitting) your platform.

• AI codeapalooza: 90% of devs are pairing with AI assistants and shipping 2 to 10x more code. Don’t need me to tell you this. Every single person reading this is experiencing it. (And if you aren’t.. reply and let me know what you’re doing;) Code was never the hard part, delivering it is, and the platform you built for human pace isn’t going to handle it. This was never a model race. The models are commoditizing. The thing that actually separates the teams pulling ahead is the platform harnessing all that output, not whichever model they picked.

• Deluge of non-human users: A supremely exciting and powerful new persona has arrived, and lord is it needy. GPU allocation, MCP gateways, guardrails so it doesn’t go rogue, and an audit trail for every move it makes. Your platform has never served anyone like this. It isn’t enough to just assign an “Test engineer agent” the same permissions as the test engineer. It’s not enough to assign it the identity as a microservice. So wtf do you do?

• The FinOps / AI bill reckoning : Around 35% of cloud spend is already pure waste. This was already a huge challenge then AI infra and token spend pour fuel straight on the fire. We’ve well and truly exited the era of experimental tokenmaxing, and your platform problem isn’t ready for it. How are you handling it? Usage controls? Model routing? You need to get that cost under control, but without stymying innovation and velocity.

• New era of regulation fun: The EU AI Act, US executive orders, data residency rules, all landing at once and all landing on you. Compliance is being rewritten faster than most platforms can even read it.

• Everyone is important: Security, data science, FinOps, the business, they all need the platform now, not just the developers you first built it for. This is the user persona shift, and it is only getting wider. Serving one persona was hard enough. The whole org is a different sport entirely.

So… what do you do then?

Here is the good news. You don’t burn it down and start over. The fundamentals of platform engineering are exactly what carry you through this. This is an evolution, not a reset.

So pick the force screaming loudest right now, the one where you already have the exec attention and the budget, and start there. Treat the five as one connected evolution, not five side projects. And whatever you do, don’t let the foundations crack while you chase the shiny new thing. A wobbly base under a GPU workload and a fleet of hungry agents is a very bad place to be. Get the fundamentals rock solid first, then stretch them to carry the new load. That is the whole game.

A few weeks ago I broke down how the CRA is an opportunity for platform engineers. Find those opportunities. Use them to secure budget, and lock focus - and ride this wave. It’s gonna be epic.

Whether your platform is quietly absorbing the deluge or drowning under it, this is the hour to spend. Watch Sam and Pankaj walk through all five. Read the whitepaper. Get your surfboard out.

Quick bites

Highlight of the week

• How to prepare for the AI-mediated Vulnpocalypse

From the community

• Want to catch the PlatformCon talks and workshops you missed? We’re adding more every week to the community YouTube channel.

And that’s a wrap on this week! As always, this newsletter is a community project. So if you have anything awesome to share from the cloud-native world, send it my way.

Stay crunchy 🥐

Luca

Plus…

• Platform Weekly moves to Substack! I am very excited to share that we are (finally) moving Platform Weekly over to Substack starting over the next few weeks:)

• AND reminder that my friends at Tailscale are organizing an awesome conference - TailscaleUp! There are still some tickets available, so take a look. They’ll be in San Francisco on August 26, 2026! It’s gonna be a banger. They’re going to be dissecting and sharing the lessons from their 20k customers through a bunch of great talks and workshops. Few things more important than networking and security at the moment. And there is prob no better place to be for it ;)

“How the hell am I gonna build an ADP?”

I’ve been talking about Agentic Development Platforms (ADPs) nonstop the last month. You’ve probably noticed. ADPs are the platform that lets your engineers and AI agents build software together, safely, with guardrails. We covered them extensively at PlatformCon, in our review newsletter, and in Ajay’s guest newsletter last week. The response from everyone has been incredible. I’ve received so many replies. But there is one sliver of doubt that keeps getting slivered back to me - “I don’t even have a good IDP yet, or an effective AI initiative in my org. How the hell am I gonna do this?”

Fair question. If the PlatformCon deluge settled anything, it’s that the ADP is where our discipline is heading. But recognizing the future and knowing what to do about it on Monday morning are two VERY different things. Some of the industry seems to be sprinting, and the other half is still trying to get one golden path adopted.

So how do you close this gap? You close it the way our community has always closed gaps… by learning the discipline properly, step by step, from the foundations up.

That is how you secure your place in the AI future. And ride this insane wave.

Remember - an ADP is your IDP evolved, not replaced. Three layers, the tooling you already run, the path definitions that humans and agents both invoke, and a new agent infrastructure substrate underneath. If you can build and reason about those layers, you aren’t the person threatened by this new paradigm, you’re the person who makes it work.

That’s why, that is exactly the journey the new AI learning path on Platform Engineering University walks you through, taught by Mallory Haigh, who some of you caught on the New York main stage at PlatformCon. And it is built for the “I’m not there yet” reality, because it starts from wherever you actually are:

• Intro to Agentic Development Platforms (free, 1 hour, on-demand). Start here, even if your IDP is still a work in progress. Four modules: the IDP to ADP architecture shift, the three layers, designing probabilistic, deterministic, and hybrid paths that keep agents on track, and where to start building, including how to measure outcomes over your first 90 days.

• Agentic Development Platforms. The core of this path, and your real next step. Evolve the IDP you have (yes, the imperfect one) into an ADP that makes coding agents safe, governed, and productive at enterprise scale. This is where the concepts become your architecture. You will work through what it takes to design the paths that agents consume, put the guardrails and governance in place, and treat agents as first-class users of your platform (without losing control of cost, security, or quality along the way..)

• Agent Infrastructure for Platform Engineers (instructor-led, starts November 12). For when you’re ready to go all the way in: a hands-on build of the harness and governance plane that agents actually run on. The advanced step once the ADP course is under your belt.

Notice what that sequence actually is. It is the answer to the question. You do not need a perfect IDP or a board-approved AI strategy to start. You need one free hour to understand the architecture, then a structured way to evolve what you have.

AI is reshaping our industry all around us. And platform engineering is the foundation to do it effectively, and safely. There is no greater opportunity for you and your org.

So, how the hell are you gonna do this? One hour at a time. What are you waiting for?

Highlight of the week

• The cost benefits of modernizing your VM fleet (that no one talks about)

From the community

• Want to watch the recordings of PlatformCon workshops and talks you weren’t able to attend? We’re uploading more every day on the community YouTube channel.

And that’s a wrap on this week! As always, this newsletter is a community project. So if you have anything awesome to share from the cloud-native world, send it my way.

Stay crunchy 🥐

Luca

Hey there! Welcome to Platform Weekly. Your weekly peek behind the platform engineering curtain. Every week, we dive into best practices, news, lessons, and updates from the platform engineering community. This is a guest newsletter by my friend Ajay Chankramath who leads at Platform Engineering Consulting, the advisory and consulting wing of the Platform Engineering community!

But first… I WROTE A BOOK!

At its core the book is about one idea. Platform engineering is becoming the operating model for knowledge work in the AI era. The book is a conceptual model and a practical playbook for redesigning how organizations work in the AI era, across software, marketing, finance, legal, any kind of knowledge work.

Preorder your copy now!

The ADP is coming. Your IDP better be ready

PlatformCon 2026 just wrapped last week virtually as well as in London and New York. One word dominated the agenda - agentic!

Gregor Hohpe talked about platforms defying the laws of IT physics in London. Patrick Debois called context the new code. Kief Morris challenged us to put humans on the loop, not in it.  By all accounts, Bruno Passos and Mansi Mittal’s session on their GenAI platform journey at Booking.com was a standout.

In New York, Kelsey Hightower made listeners take a step back from the AI euphoria in his talk on Zero Token Architecture. Jay Moran from Fiserv showed what golden path scaling actually looks like at enterprise scale.

Kaspar and Luca introduced the idea of Agentic Development Platforms (ADPs) in their keynote both days. I took both main stages to talk about architecting Agentic Development Platforms, with Mallory joining me in New York. Think of ADP as an extension of an IDP, but the paths serve agents too in addition to humans (not instead of), so that it can run without direct human intervention when needed. I care about this because every week we talk to organizations being pushed to support agentic workflows without a solid IDP foundation underneath. 

PlatformCon was not all about AI. 55% of our talks focused exclusively on building the IDP/foundations right and only about 45% had AI focus. Still significant change in direction, but the focus continued to be IDP. For good reason.

I talked to hundreds (over 300+!) of you across the week through our executive breakfast gatherings, therapy sessions, and the platform clinic as well as my book signings. Teams hear “ADP” and immediately jump to agents, LLMs, orchestration layers. They picture autonomous systems dispatching work, validating changes, remediating incidents without humans in the loop. The destination is absolutely right, but you can’t build an Agentic Developer Platform on a broken Internal Developer Platform.

An IDP standardizes paths for humans. An ADP makes those same paths executable by agents. If the human paths are inconsistent, undocumented, or held together by tribal knowledge, agents won’t fix that. They’ll amplify the mess. This is where the “paths” matter. They’re the connective tissue between your IDP today and your ADP tomorrow. 

Most enterprises I talk to are in their early stages of building the platforms to support AI workloads. Closing that gap is the work that matters right now, and it starts with rearchitecting your IDP into an ADP.

We also ran Platform Clinic for the Age of AI sessions at both live days in addition to 1:1 advisory conversations with engineering leaders. Platform Clinic was where several of you came together to talk about the key challenges that your teams are encountering, but instead of one speaker telling you what their perspective is, this was an opportunity to work in a small group to come up with solutions yourself. We had about 5 prompts we discussed around platform value, need to build the foundations right, agentic identity, golden paths and when to choose an agent.  If you missed them and want a similar read of where your platform stands, that’s exactly what we do at Platform Engineering Consulting, and I’d love to talk with you about it.

AI workloads require platform engineering. But only if the platform is actually ready. To quote Kaspar and Luca from their new book, Thinking in Platforms, “AI expands what is possible, but platforms define what is usable”.

Quick bites

Highlight of the week

• How can a Context Lake cut down up to 80% of your token usage?

From the community

• Want to watch the recordings of PlatformCon workshops and talks you weren't able to attend? We're uploading more every day on the community YouTube channel.

Hey there! Welcome to Platform Weekly. Your weekly toast of platform engineering champagne. Every week, we bring you the best of what the community is reading, watching, and building. This week, we are talking about the last five days. PlatformCon 2026. The largest platform engineering week in history.

Everything you missed at PlatformCon this week

This was the biggest week platform engineering has ever had. Around 1,800 of you were with us in person across Live Day London and Live Day New York, and almost 50,000 more joined online, watching talks, getting hands dirty in workshops, and celebrating the discipline together🥹

The line up of speakers was incredible. My friends Kaspar von Grünberg, Ajay Chankramath, Mallory Haigh, joined by community and industry titans Gregor Hohpe, Nicki Watt, Kelsey Hightower, Patrick Debois, Caroline Wong, Kief Morris, Jay Moran and so many more. The talks spanned everything that matters to us right now. The agentic future, the infrastructure agents actually run on, how to actually build, run and succeed with agents and platforms and ofc the classic deep dives into sovereignty, security, supply chain, Kubernetes and GitOps, and mastering product thinking. If platform engineering is becoming the operating model for the modern enterprise, and we know it is, this was the week the whole community pushed us 100 steps forward.

There was a LOT announced this week, because there is a LOT happening.

• Thinking in Platforms: the new book from Kaspar and me, lands August 18. It distils ten years of learnings on platform engineering as the operating model for work in the AI era. We break down a new way to understand platforms as production systems for knowledge work, an abstract model for reasoning about and architecting golden paths and platforms, and a playbook for moving from first initiatives to production readiness and scale with a focus beyond the world of just IT.

• AgenticCon: a brand new one-day event all about agents, AI, and agentic infrastructure, arrives February 2027, co-located with PlatformCon San Francisco. Early access now! A new format for a new era.

• PlatformCon World Tour: We’re going global. The Live Day format isn’t just heading to Paris, Sydney, and São Paulo, but to San Francisco too! Couldn't make it in person this week? Now you can, from all over the world!

• Two new courses on Platform Engineering University: One on the move from IDP to ADP, and a deep dive on agent infrastructure itself!

And the big one that underpins all of this. We broke down the reference architecture for agentic development platforms, the ADP. It builds on your existing IDP, treats agents as users and interfaces, and splits into three layers: tooling, path specifications, and a new breed of agent infrastructure. The thesis? Without platforms, there is no productivity gain from agents. That statement is what sets everything that PlatformCon was about this week, and what the entire community is working off of.

What's still coming? A lot. The virtual program ran all five days, with 300+ hours of talks and virtual workshops dropping batch by batch across learning paths on the agentic future, sovereignty, security, Kubernetes, and more. You won't get through it in one sitting, nobody does, we all have 20 tabs open!

We are at an inflection point that will define the future of not just our industry, but basically all industries - and platform engineers sit at the very heart of that change.

The challenge and the opportunity literally couldn't be bigger. PlatformCon encapsulated that perfectly. Now let's embrace it together!

Quick bites

Highlight of the week

• How can a Context Lake cut down up to 80% of your token usage?

From the community

• Want to watch the recordings of PlatformCon workshops and talks you weren't able to attend? We're uploading more every day on the community YouTube channel.

Hey there! Welcome to Platform Weekly. Your weekly knead of platform engineering dough. Every week, we let the best of the community rise to the top and bring it to you warm.

Plus… PlatformCon CTA

Your platform won the argument. Now it has to evolve.

I keep having the same conversation. On panels, in Slack, at dinner after talks. And I know already it will be the #1 topic next week at PlatformCon 2026. Platform engineering has basically won. 90% of organizations have adopted it, 76% run a dedicated platform team, and nobody serious is still arguing about whether to build an internal platform.

And yet. The platform that won that argument was built for a different era. Overly, developer focused, human speed, and like last week approaching problems by being faster or better without recognising we’re in a new paradigm.

That gap is exactly what our own Sam Barlien dug into in a new whitepaper on Platform Engineering 2.0: An evolution for the AI era, co-authored with Pankaj Gupta over at Broadcom. It is the clearest map I've seen of how platforms have to stretch for the AI era. They break down how you should be thinking about your IDP. An evolution, not a reset. Your existing platform is the substrate for what comes next, not the casualty of it.

Sam lays the stretch out across five shifts:

• AI workloads become first-class citizens. GPUs, model serving, and MCP gateways flowing through the same self-service path as everything else.

• Agents arrive as a brand new user. The first non-human persona in over a decade, needing scoped identity, guardrails, and audit logging.

• Cost turns into a platform signal. FinOps moves out of the monthly rear-view report and into the moment of provisioning.

• Security shifts down into the substrate. Not piled onto developers, baked into the platform so every path is a secure path and AI security gaps addressed.

• Architecture gets composable. Repavable, API-first building blocks instead of the tired build-versus-buy standoff.

None of this throws away what you already built. Platform as Product, golden paths, self-service IDPs, they are all a fundamental part of this. The discipline doesn't restart at each phase. It accumulates. So while other fields spend this year asking if they still matter in an agentic world, platform engineers are staring at the single biggest expansion of mandate the discipline has ever seen.

The team that masters infrastructure for the AI era is the team that masters the AI era, and that starts with treating infrastructure as a first-class platform concern rather than the thing under the floorboards

There is no truly better primer before PlatformCon next week. So read this. And be ready to discuss it at the world’s biggest platform engineering conference in just a few days.

Quick bites

Highlight of the week

• 5 pillars your platform needs in 2026 and beyond

From the community

• Want to watch the recordings of PlatformCon workshops and talks you weren't able to attend? We're uploading more every day on the community YouTube channel.

Hey there! Welcome to Platform Weekly. Your weekly sweep of the platform engineering perimeter. Every week, we round up the sharpest thinking in the community and hand you the one story you can't afford to ignore.

Plus… we’re just two weeks away from PlatformCon! It’s your last chance to get tickets and say hi in London or New York!

You can't patch your way out of this anymore

I've been having the same conversation on repeat lately, with a bunch of you in the community. The patching treadmill is totally f*cked. We spent the last year just trying to run faster to outpace it - and I think it’s time to stop. And I don’t mean give up.

For thirty years the playbook was find the CVE, ship the fix, apply the patch, repeat. That made sense when vulnerabilities came in the hundreds and attackers took weeks to move. That world is GONE.

• 48,185 CVEs were published in 2025, up 163% from 2020. FIRST's median forecast for 2026 is nearly 60,000, and some people are suggesting 100,000+.

• The Linux kernel alone accounted for 5,530 CVEs last year, a pace of 8 to 9 new ones every single day.

• In 2020, attackers needed 30 days on average to weaponize a new CVE. By 2025 the median was under 5 days.

• 28% of vulnerabilities in 2025 were exploited on disclosure day or before a patch even existed. For that group the average time-to-exploit was negative one day. The fix didn't exist yet.

• Meanwhile organizations take 88 days on average to remediate a critical vuln (not to mention NIST has stopped bothering categorizing all of them…) You're on your own to figure out severity.

Those numbers come from Justin Garrison, Field CTO at Sidero Labs, in a piece called Patching Won't Save You. Oof. It's a banger, and it reframes the whole problem.

This is a fundamental platform engineering problem now NOT a patching problem. If attackers exploit in hours and no change advisory board on earth runs at machine speed, then a faster pipeline was never going to be the answer. The answer is to have less to patch. Sounds easy doesn’t it?;)

That's the game. Shrink the surface. If a package isn't there, the CVE against it simply doesn't apply to you. Justin has another great article on his favourite example Copy Fail, a 732-byte script that claimed to root every Linux distro shipped since 2017.

Talos Linux, which is an open source Linux OS for K8s, which Justin and the folks at Sidero Labs have been maintaining, is basically immune to this. No shell, no package manager, not even a Python interpreter, most of the exploit had nothing to grab onto. Whole categories of risk just come off the board.

That is how you need to think about these security problems going forward. If you aren't thinking secure by default, then to be honest, you're not thinking at all.

So here's what I want you to do this week - stop asking how fast you can patch, and start asking how much you can delete. Read Justin's full breakdown, take a look at Talos Linux, then go count the packages in your base image you've never once called.

Quick bites

Highlight of the week

• 5 pillars your platform needs in 2026 and beyond

From the community

• Want to watch the recordings of PlatformCon workshops and talks you weren't able to attend? We're uploading more every day on the community YouTube channel.