The alpha, twice a week
That was 5 min.
Get the best new moments in your inbox every Wednesday and Saturday. It's free.
Check your inbox
We sent a link to your address. Click it to finish signing up. Not there in a minute? Look in spam.
or
The Pragmatic Engineer · 5 min · Oct 7, 2026
Run an AI software factory on one module, not the whole system
Sam Newman

Gergely OroszHost · Host, The Pragmatic Engineer
Spent four years at Uber heading mobile, web and backend teams; shipped part of its payments system.
About this segment
Sam suggests splitting a system into modules and trying a no-code-review factory only on low-risk ones. Pick modules with solid tests and SLOs, and keep humans close to the critical ones.
From “Building resilient systems with Sam Newman”, Oct 7, 2026. Watch the full episode
Thanks. We'll look at and fix what's off.
“this area here is where we're trying a full software factory approach, where we don't look at the code anymore, but we specify the interface.”
Takeaways
- Use modules to run different AI approaches in different parts of a system.
- Good candidates have strong tests, SLOs and are cheap to rewrite.
- Humans should spend their effort on the gaps between modules.
In this episode
Full episode- 1:21:33Fail open or fail closed depends on the business context4:39
- 1:08:19Make retries safe with idempotency keys, not just fingerprints4:48
- 1:26:21Robustness is only one of four parts of resilience1:58
- 1:01:59Decide how resilient you need to be before building resilience6:01
- 35:16Spec or code as source of truth depends on tacit knowledge5:17
1:44:55Run an AI software factory on one module, not the whole system4:47
- 1:16:04Thundering herds have different causes, so the fixes differ5:12Up next
- 1:32:49Hedge AI vendor risk by being multi-model and using plain code3:39
Transcript
Transcribed by machine (Whisper) from the episode’s audio, so a word may be off here and there.
- 1:45:07
comes full circle a little bit which is the idea of potentially not looking at the code isn't to say that you don't care about what the system is that you're building. Here's to say that you've got a better way of understanding what you're building. So one of the concerns is if I'm using AI to create code, this is going to create awful loads of debt and a complicated system. No one's going to understand. Well, we can't let that happen. We still need to remain connected to the system that we're building, which is what I'm a big fan of like modularizing system. Whether or not you put those modules in different computers, I don't actually care. Getting AI to work within the modules having the humans think carefully about what those modules are and the connections between them let the ai go hog wild inside those boundaries that are easy to change
- 1:45:43
the gaps between them that's where the human beings spends to think about the mental mold how things fits and slots together um that feels a very sane way for us to balance our time and our energies appropriately so do i understand correctly that you're saying that it's probably sensible approach is have the architecture in your head know how your system works know how the boxes work know where there's ai inside it maybe it's generating code maybe it's running your incidence response in in isolated ways and then spend your time talking with other people in the business on your team with your customers because you're you know as you said systems like software is is people's ideas connected and you have things in in your head or you write it down But now you're using it as an AI as a tool to enable you to maybe take on larger chunks of the business and maybe make better decisions because maybe you have more time to, as an engineer, understand more on the business, on what is working, what is important, those kind of things.
- 1:46:40
Yeah. And also to make the structure on the model system a bit more explicit as well. I mean, that's one thing a good modular structure does. I mean, this is why Shopify have been so successful keeping their thing as a monolith, right? because they spend a lot of time building their monolithic application as a modular domain-driven architecture, right? Because it makes the structure easier to understand.
- 1:47:00
You can zoom out and see how those things fit together. But also in the short term, while we're having these debates about are we going full software factory or not, we don't have to make a one-size-fits-all approach. We can say, look, this is our architecture, be it a modular monolithic or a microservice architecture, it doesn't really matter. And over here, this area here is where we're trying a full software factory approach, where we don't look at the code anymore, but we specify the interface.
- 1:47:25
We have verification around that. We know what good looks like for that module, right? We've got functional tests, tests that look at, say, some of the operational requirements as well. These areas over here, we're still grappling. These are really key and really important to us. We're not ready to give up on these yet because we don't have the trust level yet. We don't want to take that risk just yet.
- 1:47:45
And so over here, we're going to work with the AI more of a collaborative way while we work together. and we're still going to be intimately involved with the code because we're not ready to make that step here. But if we approach our whole system with one big black box, then we're forced into making one or either decision. I don't think that's healthy. Do I understand that you're saying that you think that the software factory, the dark factory, you're giving it a spec or the AI either building it or operating it, that you see that as viable?
- 1:48:11
There are some companies I know that are already all in on this. Not everyone should be doing it whatsoever. I think if that is our future, if that is our future, and I think it's a lot of ifs there. The question is about how you go about adopting and trying. So what I'm trying to do is find ways in which we can lower the barrier to entry to try these ideas out in a safe way. And like low-risk environments and maybe simpler domains, those kind of things, right?
- 1:48:33
But also like a lot of dark factories don't create finished products, like real world. Beyond the fact that real-world dark factories, there aren't many of them, most of them create components. They don't create the finished product. So in the same way, if you think about a module being a piece of the overarching system, well, let's have a factory around these bits here. And actually looking at it, like if we had to rewrite that from scratch, it might take us, like with the collaborative way with AI, it might take us a few weeks to have to rewrite that if we had to.
- 1:49:04
So actually we're quite relaxed about leaving that to go as is. and it's been working fine. It's a module around which you've got great test coverage already, for example, where it's not on the critical path from a latency point of view, or it's a service where we've got really good observability data and really well-defined SLOs and we've got good steady state, where we can start running it as a factory now and seeing what's happening in production.
- 1:49:25
We can have a look at the SLOs. We maybe add some special SLOs around it. I'm hearing correctly that you're saying that as a professional,