Transcript: How teams of AI agents write and check code
An AI-generated audio overview (Google Gemini), transcribed by machine on Blaine's Mac (Whisper). The audio was checked against primary sources; what it gets wrong is listed at https://blainomd.com/learn#audio-inside-agentic-software-factories

Welcome to the Deep Dive.
You know, usually we picture software development as this artisanal craftsmanship.
Yeah, like a single developer hunched over a keyboard at 2 a.m.
Exactly.
Just typing out every line by hand.
But today we're taking you into this wild 2026 reality where AI systems like Cloud Code are actually writing like 90% of their own code bases.
Which is pretty mind-blowing.
And our mission today is to synthesize some of these technical architectural analyses just to help you understand how these agentic software factories are totally rewriting the rules.
Right.
And it actually traces back to a vision from 1968, doesn't it?
Yeah, Bob Beamer at General Electric.
He argued back then that we needed to stop treating software like an artisanal craft and start treating it like industrialized manufacturing.
Okay.
Okay. Let's unpack that manufacturing idea for a second because the marginal cost of actually generating code has plummeted to practically zero today.
It really has.
It's like we invented a machine that prints infinite pages instantly, but we still only have one human proofreader.
That is the perfect analogy.
And that proofreader dynamic completely flips the traditional engineering bottleneck.
Because the code generation isn't the problem anymore.
Exactly.
For 70 years, the scarce resource was getting the code written.
Today, the scarce resource is verifying it, securing it, and making sure it integrates without breaking production.
So if verifying is the bottleneck, how are teams keeping up?
We're seeing developers use AI to manage AI, right?
Yeah.
There's this brilliant architecture in our sources from a developer named at Zazen Codes.
Oh, right.
The in-repo factory.
Yeah.
They essentially built a factory inside their code repository.
So they use one AI orchestrator to manage seven specialized sub-agents.
You've got a spec writer, builder, security, UX, UI, code reviewer, and an approver.
Here's where it gets really interesting, though.
You might be wondering, why not just use one massive AI for everything?
I mean, it sounds easier, right?
Right.
But, oh, it's because of confirmation bias.
If it writes the code and reviews it in the same window, it will just, like, grade its own test and ignore its own mistakes.
Exactly.
It suffers from context pollution.
By isolating them, the approver agent forces rigorous verification of whatever the builder agent does.
But wait, running seven heavy-duty AIs all the time sounds incredibly expensive.
It would be, which brings us to asymmetric model tiering.
Oh, they mix and match.
Right.
They don't use the same model for every task.
They deploy a heavy-duty, expensive model like Claude Opus 5.5 for deep logic tasks.
Things like security audits or final approvals.
Yeah, the guardrails.
But for straightforward tasks like UI formatting, they route that to a faster, cheaper model like Sonnet 5.5.
It perfectly balances high cognitive capability against computing costs.
Makes sense.
But, um, isolating these agents has to create a massive logistical headache.
Oh, completely.
So what does this all mean for you, listening?
If you have all these specialized AIs working at once, how do they not constantly override each other's work and crash the whole system?
Well, they move from sequential to parallel execution using Git work trees.
Which lets them work in parallel isolated branches.
Right.
So they can work at the same time without stepping on each other's toes.
But state contention is a huge issue.
The benchmark data shows just how messy this gets.
Yeah, that's all that.
In one parallel run, seven out of nine pull requests actually conflicted.
The agents were just tripping over shared files on the main branch.
It's like having seven chefs in the kitchen all trying to write their modifications on the exact same recipe card at the exact same time.
That's exactly what it is.
So to fix that economic and routing nightmare, architects introduce a foreman.
Like a manager.
Yeah.
They use a hyper-fast system one decision model like JEV.
Think of it as a bouncer at the door.
Oh, wow.
It performs this split-second binary triage, simply answering yes or no on whether a file needs attention before waking up the expensive AI.
And that simple filtering slashes token usage by, what, 86%?
86%, yeah.
That is massive.
So for you, the listener, your role is fundamentally shifting from software engineering to harness engineering.
You aren't typing out the code anymore.
Right.
You are defining the intent, structuring the factory layout, and setting the escalation policies.
And, you know, the source notes a fascinating detail during the setup of this factory.
The Opus 5.5 model autonomously analyzed the architecture and independently added three brand new, unprompted features to its own backlog.
Wait, really?
Yeah.
It just decided to build them itself?
Yeah, entirely on its own.
Which leaves us with a slightly terrifying or maybe provocative thought for you to mull over.
Yet these dark software factories can already self-heal bugs via runtime error logs.
Which they can.
How long until these systems begin independently designing and launching entire businesses while we sleep?
The days of the artisanal 2AM coder are definitely over.
The factory might just be running itself.