# Software Factory Strategy: Context, Locality, and ROI

**Podcast:** Dev Interrupted
**Published:** 2026-07-31

## Transcript

So, Andrew, what do you think about all these discussions around software factories that are happening right now?
I love the idea, but the naming is a little unimaginative for me.
As you're familiar with by now, I'm...
experiment with a bunch of different nouns for what people are approximating the factory.
And frankly, I loved it back when it was called things like Gastown.
Wasn't that a little more fun and exciting than just a factory?
What about you?
Do you think that the factory metaphor is here to stick?
It feels so sanitized.
We're literally talking about the English language.
We could call it really anything we want.
We're pioneering something new.
Yeah, I mean, our factory is typically deterministic.
I guess, because the idea is you want to tie it back to the deterministic conveyor belt.
You want to harken back to what I'm saying is it has to output a like it either successfully creates the thing that you wanted or it doesn't do that.
You know, you like you don't want a like a car part that fails 10 percent of the time, you know, like to me, like a factory has to be a determined like the output has to be a deterministic output.
Right.
And that's I don't disagree.
not the nature of the beast, but also to a factory is like, when you think about how like a factory even works is.
Typically, it's built to create something very specific.
And then when you want to create something new out of the factory, you have to tear everything down and rebuild it.
And that was something we learned about, actually, when we had a past guest, Brian Gerke, the CTO at Intrinsic, you know, builds.
He's a robotics leader and robotics are used extensively in manufacturing assembly lines.
He talked all the time about how, like.
Every year, a whole factory line would wipe all of its robotics, wipe all of its machine, and have to start all over to create a new production line for a new item.
So it's also like a level of waste, right?
Like, is that what we're going to do when we have software factories?
Is like every few months, we're going to gut everything inside and rebuild it?
Maybe, but like, kind of scary to think about.
Yeah, absolutely.
All right, well, we'll get into this because we have more on this topic, but welcome to the Friday Deploy brought to you by Linear B.
I'm your host, Ben Lloyd Pearson.
And I'm your host, Andrew Ziegler.
And this week we are covering, yes, more software factories, hiring a million bad employees, defending our strange balconies and the orchestrators hidden tech.
So we've got a great lineup today.
Andrew, let's just kick it off with more discussion on these software factories.
We have a few takes on them this week.
The first comes from friend of the show, Zach Lloyd over at Warp, where he's published this guide to building software factories for engineering leaders.
So Andrew, what's in this guide?
Yeah, so I really love this topic of software factories, despite my complaints on the terminology itself, because so many really smart, dev-interrupted alumni and experts in our industry are all talking in a buzz right now about software factories.
So if you've been reading or seeing these takes on socials or in the news, let's kind of dive into some of the stuff behind it.
One of these is the viewpoint from Zach Lloyd.
who's arguing that the software development process is shifting from the interactive experience, that is like using a coding agent and a harness by hand, you know, as the engineer driving it, and more into being these automated processes that live places like in the cloud.
So here it's that interactive agents, he argues, are harder to tie to ROI.
They can be inconsistent across developers and their machines and what's available to them, and they're difficult to govern at scale.
So the idea of centralizing your compute and your build in one cloud space becomes a way for you to optimize it and improve its outputs.
And here, you know, we love optimizing and improving our outputs.
That's what we talk about here a lot on the show.
So this is like a really clean fit into our mental model about how they are supposed to work.
And so a big dive that he goes into is that like, obviously not all code that we do today is ready for that kind of cloud transformation.
Like really, he...
identifies 20 to 30% of issues are fully automatable.
These are the things that you'd fully divorce from the interactive session and put in the cloud, you know?
I think there's a lot to unpack, but obviously having a centralized shared space where compute is equal across your engineers and your teams and everyone has access to the same stuff, it's a really critical ingredient.
What did you think of this coverage, Ben?
Well, you know, we've been talking about this concept of factories, you know, dark factories in particular, with increasing frequency in recent weeks, it feels like.
And to the point where we're actually now starting to plan some content around this coming up here pretty soon, where we're going to explore this concept of building like the context layer for dark factories, because I really think that's sort of like one of the most critical components to success with this.
Because what we're kind of describing is, you know, we had prompt engineering back in like, I don't know, like 2024.
So last year felt like context engineering became this whole thing.
Now everyone's trying to get to this idea of intention engineering or intent engineering.
And that's where you really do need like one of these so-called factories to be able to execute all of the things that need to be done to convey your intention.
The problem is if you've never built that foundation of context underneath of it, then you just don't have, your factory doesn't have all the information it needs to make the right decisions along the way.
So if you're listening to this and you're wondering, you know, you're reading these articles that we're sharing about how to build your software factory and you want some help, like understanding, like as an organization, what's the next thing to do?
This is a topic that we're going to be exploring, you know, as a part of some of the content we're doing over at Linear B.
on how you build that context layer for these dark factories.
So stay tuned for this because I think it's a really, it's everyone's thinking about it right now.
And I think there's a lot, you know, it's again, there's sort of these primitives that we have to build and define to make these factories successful.
So yeah, if you're still trying to learn, wrap your head around these concepts, this is a really great article to figure it out.
Now, I want to flip the narrative a little bit with another story from yet another friend of the show, Dex Horthy.
And this one is all about why software factories fail.
And in particular, Dex is pushing back pretty strongly against the notion of the lights off software factory, you know, that dark factory where it's all AI agents doing everything and you don't need lights because there's no humans to look at anything.
The problem is that a lot of these loops that go into these dark factories are sort of built on like a pass-fail test benchmark that rewards the factory when it does something right.
So there's a lot of these organizations that are out there like trying to use these factories to achieve like 10 to 100x velocity by doing things like cutting out code reviews and just pushing agentic code straight into production without really looking at it.
Yeah.
And of course, you know, our own research backs this up.
There's a lot of research out there that's showing that, you know, this does have, this is creating potential quality risks for, you know, a lot of organizations.
Really the key takeaway from this is that, you know, there's a lot of benchmarks out there that are used to evaluate the success of a software factory.
And it will tell you whether or not the code works, but it doesn't actually tell you anything about whether or not it's maintainable.
or if it's something that you can continue to build upon over time.
So it's really important, like as you're thinking about these software factories and you're trying to fully automate away human processes and human code reviews, you know, there's a lot of places that you need to inject human expertise to make sure that you have the right back pressure to keep these factories running well.
I always like to cover all sides of these perspectives.
And who knows, maybe we can get Dex and Zach to come fight it out on our show sometime.
We'll see about that.
But I do really like this kind of more skeptical take of just adding loops to your workflows and whether or not that's actually what is needed in all situations.
So what was your thoughts, Andrew?
I really love how he boils it down to, there's a lot of benchmarks for understanding if you're an agent.
produces good code and for ranking the models against each other in terms of like their code output.
You know, we have the very famous, you know, software engineer bench and many others like it that measure that code output.
But there's no real benchmark for understanding how well these models can maintain like a pre-existing code base over time.
And that's really the problem that Dex is obsessed with solving.
It's really, I think, what makes his prevailing argument against being able to quote, turn the lights off, you know, something that's actually impossible.
And something that's fascinating about these two stories is that they're actually not really arguing against each other because there's a lot of alignment in what they say.
Because even Zach himself says there's only a certain amount of issues available or that are kind of like eligible for this kind of factory setting today.
You know, it's not for all factories.
You're not turning the lights off everywhere per se, but it's about identifying the things that you can.
So I do think there's a lot of synergy in both of those takes.
In particular, I really love how Dex fights against the rot that can happen inside of a software factory because really what you need is strong tooling.
You need, like what you said, Ben, that context layer to understand what's moving through that factory.
If you don't have that, then it really just becomes a black box.
All right, let's talk about how...
We have all now hired a million bad employees.
What do we have here, Andrew?
Okay, well, this is an article that's basically dunking really hard on loops.
And I love to hate read and love read this at the same time.
I think that this draws attention to how there's a lot of waste that's happening where people and team delegate out processes and actions to agents and loops that kind of run in the background and ultimately end up you know, bloating an artificial org chart, so to speak.
And the reason that this results in problems is because then you get poor management across all of those different types of running loops, the folks that are running them.
The expression of your org chart becomes even stronger in what your agents are able to do.
It's like some weird...
cousin variant of Conway's law.
And so I really loved how it pointed out that not all processes scale really well with loops in terms of like working as a team and also to.
really fought against the idea or rather protected the idea of the individual and the person who develops their craft and their domain expertise into their skills, into their loops, to being in situations where they have to loop those into larger organizational contexts can be very, very difficult because those loops are very specific to the individual.
It really kind of calls to action as well.
Like if we really want these loops to exist within an organization, they need to be more top down.
Instead of organically bubbling up out of the agentic abilities of their employees, because otherwise you're going to probably get a lot of waste and a lot of misalignment.
Yeah.
And of course, we've been covering the concept of token maxing quite a lot recently on this show and with content we've been doing over at Linear B to the point where we even had a whole workshop on how to get beyond token maxing and how to get beyond this challenge of just spending more tokens without actually...
like knowing whether or not they're contributing value to your organization.
A constant theme that we just keep hammering on is how AI amplifies both the good and the bad.
So if you're an organization that is struggling with your software development processes and tooling and workflows, and you start rolling out AI or you set a mandate that everyone needs to use AI for all of their code or those sorts of challenges, you're actually just going to accelerate the...
problems that your organization has to deal with rather than accelerating the value that you can generate.
And conversely, being smart about how you spend your tokens and having humans who are experts that guide these AI systems, like those seem to be the companies that are really having the greatest success with this technology.
This is, I think, a very realistic take on the capabilities of AI and how the benefits of it really aren't always just because it can outsource human effort or human thinking, but more so that the benefits really come out when you have a human who is leveraging AI to extend themselves even further than they have before.
All right, let's talk about this challenge with AI where it only sees the latest version.
fails to protect our original ideas.
So what do we have here in this article, Andrew?
Okay, this is a fun article from Mira Kiraki.
We've covered her a few times on the show, and I really loved how she brings her.
unique perspective to working with AI and understanding how to iterate with it and own your craft.
I think that's a really strong voice that she brings to this.
One of them that she calls out is the art of protecting your versions and having good, strong versioning practices when you work with your agents.
In the past, she's written about how...
comparing multiple prompts and running adversarial things like, oh, I'm going to run this through a cloud.
I'm going to run this through chat GPT and compare them.
And then you pick a quote winner and throw one away.
She really called out that practice.
She's like, no, you keep both.
It points back to your original idea where there were gaps.
And those two things are an opportunity themselves.
This is similar to this idea.
It's the idea that if You have models and you give them an input, but they don't understand the process that led to that.
that input.
They're going to make wildly different decisions on how it should be changed next.
This just has to do with the behavior of how models are able to understand change over time.
So in this case, she split the idea of like, I'm going to generate a house, a fun house, and decorate it exactly how she wanted.
It looked like a real real estate picture that she just generated, right?
And then she took an AI and she split in these different personas.
One of them was going to be in charge of being a property developer.
And she gave it her picture.
it made it something that a property developer would feel comfortable working with.
Then she gave that to an investor agent, someone that was going to invest in building and owning the project.
They wanted to see something slightly different.
And as it goes through these different layers, the personas of what was tasked to be and what was, you know, you came in with your prompt.
You can imagine that the investor, the developer, these are just kind of like.
prompts or coming in with inputs on stuff that you're doing, whether it's code or otherwise.
And if it doesn't understand what came before it and the decisions before, then it veers off of what the best path may be.
And one by one, each of these different agents kind of...
buffed away all of the cool creativity of her original building, and it just looked like something that you'd find on any street corner, because that's what the LLM's going to do, is degrade it to normalize, to like the 50% to the average, right?
So the key to keeping your outputs really strong is to hold on to your precious drafts and understand how they reflect on the journey.
I've actually done this a lot, too.
I have a lot of coding experiments where...
The agents have to study what the agents before it did.
This is a really key practice.
I just love to see this broken down so clearly.
Yeah.
And this kind of relates to, you know, where I've been focusing in some of my own personal effort lately, and that is on developing my first brain.
You know, I've been following this practice from Andrea Carpathi about, you know, building a second brain where you have this AI collection of AI or resources that are designed for AI to consume and help you do work.
But I think having that like corpus that is your own work that represents your values and your goals and the things that have to be done versus the things that are nice to have or shouldn't be done.
And then having that like sort of be constantly referenced against whatever the latest iteration is to make sure that you're staying aligned with it.
And if your initial corpus doesn't meet the needs of what you're trying to achieve, then it's making sure that you update it and keep it strategically designed very well.
This is sort of like spectrum and development.
This is a very common practice that's appearing in a lot of software engineering teams.
We certainly are seeing it both at linear B engineering.
We've seen it a lot already.
But then also across just our customer base, it's becoming a very common practice when teams get into these agentic workflows.
And we didn't get a chance to cover it, but we saw some research recently that was showing how AI really does have this lack of awareness of what changed.
From its final output to the actual final version that gets used.
And without that awareness, you know, if you're not building that awareness into your system, then it actually doesn't have like the full context of like why things have ended up the way that they are today.
So, yeah, this is a really interesting, you know, just I think a really great like way of viewing this challenge of like keeping AI systems aligned, whether it's for software development or design or anything like that.
By the way, at 6.30 p.m.
on August 5th in Soho, London, Linear B is bringing together a group of senior engineers to let off some steam and talk AI strategy with their peers.
Because AI is writing more of their code bases every day.
But the question remains, are we shipping faster or are we just busier?
And CTO Yishai Biri will be on site sharing the latest AI benchmarks from 2.7 million PRs and 250 organizations that made that data possible.
So if you lead engineering in the UK, don't miss your chance to connect with peers at this exclusive event.
All right, awesome.
I want to wrap this up today with the orchestrators tax.
And this is an article from Rahul Garg over at ThoughtWorks Engineering where he's been doing some research on multi-agent coding.
Where, you know, the TLDR of it is that, you know, the true cost of a sub agent isn't like the amount of time that it runs or whether or not it's like duplicating work.
It's actually how much it pollutes the orchestrator's context.
So the working memory is sort of getting connecting this to the back, the last story.
You know, if your sub agents are polluting the upstream content or the upstream source of information, it creates a lot of challenges for.
your organization.
And really the argument that Rahul is trying to make in this article is that your subagent shouldn't be justified by their speed or the amount that you can run in parallel, but whether or not they can actually maintain a cognitive locality.
Can they solve their problems with all the information that's been put into them without having to go back to the orchestrator to raise problems or ask it to change things?
As you're thinking about moving uh, from like two to four agents.
You want to start thinking about ways that you can, uh, protect yourself from this.
Uh, so Andrew, what did you think about this article?
I, yeah, I really agreed with this article, but I, I specifically the cognitive locality, this is really key to understand.
I want to, I want to harp on that for like a second because.
There's been a tendency, especially with how just prompt engineering has evolved in general into like harness engineering.
There's a lot of folks who still kind of take the idea of like, oh, you asked the AI to take a persona, right?
You are an expert, blah, blah, blah.
That was something that we did a year or two ago with AI that's not a practice that's really recommended for these types of things.
However, you still sometimes see engineers and teams where they have sub-agents that are almost like, There are roles.
Like this is the tester sub-agent.
This is the front-end sub-agent.
This is the CICD sub-agent.
Like whatever the case.
And so you get this like almost like, it's almost like LARPing or like role-playing.
It's like you don't, they're like wearing little costumes, but they don't need to, right?
And so that was something that we were doing.
We were bucketing.
However...
The true smart way to bucket is by this cognitive locality.
It's not by what your role is.
It's where is the domain of the code base that you are in charge of and you own.
That is the subagent that should own that.
If you get really good with this, you can get some really powerful stuff going in monorepos where you have a lot of cognitive locality that's living adjacent to each other that maybe aren't related to each other at all.
And that's okay.
Because now you have a high-level orchestrator who can sit on that mono-repo level, for example, and use sub-agents that can do incredible, drive incredible things within their cognitive locality.
And so...
If you otherwise take an approach of having the test sub-agent and the CICD sub-agent, the front-end sub-agent, you're talking about a lot of sessions touching a lot of overlapping stuff, and none of them own the mental model of that cognitive locality.
The other side of this, too, is that...
If you take the model of like what you said about this context pollution problem that happens with orchestrators, if you run orchestrators, you'd experience this.
They spin up a bunch of sub-agents, and then they're trying to figure out what the heck are my sub-agents doing?
I got to report back to this human.
I'm like, I don't even understand.
So they start like pinging and poking and interrupting, and then they do the worst thing they could do.
They tail the transcript log.
from the sub-agent.
And now their context is just blown out.
They are the sub-agent as far as they're concerned because that's how models work.
And so, like, those traps happen all the time.
So you need tooling and guards against it.
If you have this cognitive locality problem, you're no longer in that world of having to dive so deeply into this, like, wave of sub-agents.
So don't sleep on this advice.
Always really good stuff from ThoughtWorks, especially this one from Rahul.
sort of bigger picture implication from this, you know, context windows keep getting bigger.
And so really the bottleneck more and more is not the capacity of the model itself.
It's whether or not you have a strong signal to noise ratio.
Like if you're overwhelming your orchestrator with noise from sub agents, then your quality is going to degrade pretty substantially.
So yeah.
So that concept of like the quality of your working memory, like that's something that I don't think we've.
really as a whole across the industry have really explored enough yet.
I think this article is a really great effort at that.
All right, Andrew, what are your agents up to this week?
Oh, my agents are trying to break out of jail, Ben.
I've been doing some really interesting security experiments with my agents and playing around with tools that are more in the sandboxing world.
of like, what do you actually make available to the agent on a curl level?
There's just so many interesting tools out there now that allow you to literally bubble wrap the world that the agent lives in and strictly define what goes in and out.
So I've had a lot of fun and intrigue taking that approach to some of my projects and being like, how do we protect these agents from themselves?
Especially as I find the box that my agents live on and the things they do on, It becomes like a bustling city.
I'm like, I can't have a nuclear explosion over on the side of the city.
It's like, I got, there's people living over here, right?
So I'm just doing my due diligence.
But what about your agents?
What are they up to?
That's all really cool.
I just hope you're keeping them away from hugging face infrastructure because I really don't want to have to be like reporting on that story.
Like you trying to hack, like, you know, I can already see it now.
Andrew Ziegler's agents break out of the lab and start hacking the world.
Yeah, I don't want to be covering that story on the show, if that's all right.
No, no, no.
I'll try to keep it too tame.
Although I guess the agents did rotate on the story a little hard once that hugging face thing hit the newswire in the last week.
My agents have found that very intriguing, and maybe that should keep everybody concerned.
I don't think you should have put that in their context window.
They found it themselves, and now we're bubble wrapping them.
I'm like, you know, we got to make it safe.
That's the world we live in now.
Yeah.
You know, I've really, I have kind of been, I didn't know I was doing this until I read Rahul Garg's article this week, but I have been spending some time really thinking about like distilling information based on like the specific purpose that I need it for, because so many AI tools just love to proliferate text, just create more and more of it, like all the time.
And I've found there's a lot of value, like if you can.
you know, take whatever specific challenge it is that you're trying to solve.
And for us, it's usually content.
We're like trying to build some, some campaigns or some new content pieces, but really boiling down the context that you need for that piece, that piece of work that you're doing is, is very powerful because it just keeps the agents just so much more focused on, on your objectives.
So, um, yeah, it's less so about how many tokens am I spending right now and how, and more so like, am I giving, am I getting that right signal to noise ratio?
Totally.
The distillation effect, the idea that you're throwing everything in a big pot and being like, what can I boil this down to?
It's really appealing, actually.
The commoditization of intelligence is very real.
It even goes back to the second brain stuff we've been talking about a lot on the show.
Distilling that information down is really just that process, too.
So maybe another time we can talk about how I've taken a crack at some of those things for sure to learn and just be more curious about the world.
All right.
Well, this is Dev Interrupted brought to you by Linear B.
Thank you to our listeners for giving us your time today and for sticking around all the way till the end, actually.
We really appreciate the attention and the engagement that we get out on social media.
And speaking of engagement, you know, we love to get to interact with our audience.
So whether that's just giving us a thumbs up or a like or a rating, wherever you're consuming our media, and then reach out to us, comment on our sub stack, reach out to us on LinkedIn.
We love to interact with everyone that's out there.
So thanks again for joining us this week.
And thank you, Andrew.
And we'll see you next week.
See you next time.