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.
See you on the factory floor. And as always... stay crunchy 🥐
Quick bites
Highlight of the week
Want more factory talk? Our friends at AI DevCon are back in NYC (Nov 2-4) with three days on scaling coding agents across real orgs, plus a Steve Yegge closing keynote. 30% off for the community here.
Upcoming webinars
[Last chance to register] On October 29, 19:00 CEST, Join Sonny Shi from Stacklet will talk about making coding agents policy-aware for Terraform and Kubernetes, plus runtime enforcement for what slips through. Save your spot here.
From the community
Every PlatformCon talk, past and present, is on the Platform Engineering YouTube channel.
The gate is where these factories quietly fail. If it scores a change on tests the same agent wrote, a green run tells you very little, so the auto-ship rule needs at least one check the agent can't edit.
The risk score shouldn't grant a run the fast lane if the same agent can change the policy it is scored against. I'd keep that policy and the production write identity outside the run, and test an attempt to edit them in the same PR. A small dependency bump is a useful counterexample: small diff, potentially large runtime effect. What is allowed to bypass human review, and who owns that allowlist?