Subscribe
Share
Share
Embed
Why Software Factories Still Need Humans in the Loop
Ran Aroussi discusses “software factories” as automated systems that manage the full software development and deployment cycle, arguing the industry is moving from a single workstation to virtual, always-on cloud environments with agents running off-machine. Prompted by Dex (HumanLayer) describing a fully automated “lights-out” factory that produced “slop,” and Uncle Bob’s claim he doesn’t read agent-written code when surrounded by extreme constraints, Ran explains why he doesn’t believe in lights-out automation. He outlines Automaze’s internal factory, Cloop: tickets/PRDs are created and grounded in an indexed knowledge graph of the codebase; multiple models generate and critique PRDs; a human approves; agents implement in parallel, run unit/e2e/quality tests, simplify and profile code, then perform code and security review, looping up to five times before escalating to a human. Humans remain essential for alignment, enforcement, and final validation via PR review and temporary deployments, avoiding false positives, runaway costs, and untrustworthy results.
Ran Aroussi discusses “software factories” as automated systems that manage the full software development and deployment cycle, arguing the industry is moving from a single workstation to virtual, always-on cloud environments with agents running off-machine. Prompted by Dex (HumanLayer) describing a fully automated “lights-out” factory that produced “slop,” and Uncle Bob’s claim he doesn’t read agent-written code when surrounded by extreme constraints, Ran explains why he doesn’t believe in lights-out automation. He outlines Automaze’s internal factory, Cloop: tickets/PRDs are created and grounded in an indexed knowledge graph of the codebase; multiple models generate and critique PRDs; a human approves; agents implement in parallel, run unit/e2e/quality tests, simplify and profile code, then perform code and security review, looping up to five times before escalating to a human. Humans remain essential for alignment, enforcement, and final validation via PR review and temporary deployments, avoiding false positives, runaway costs, and untrustworthy results.
- Subscribe to the newsletter – the written version of this show, weekly: varops.com
- Read the books – Company-Scale Agentic AI (for operators and the C-suite) and Production-Grade Agentic AI (for engineers): varops.com/books
- Work with us – VarOps installs resident AI inside mid-market companies. It runs where your work already happens, sees the whole operation, and what it learns belongs to you: varops.com/transform
Creators and Guests
What is Old School / New Tech?
Old school thinking meets new tech — an unfiltered podcast, hosted by Ran Aroussi and a co-host you won’t see coming.
Live every episode. No production lag, no editing. Business, AI, tech, startup ideas, and whatever's worth talking about — through the lens of someone who's been building production systems for 35+ years
Welcome to a new episode of Old School New Tech. My name is Ran Aroussi and I was thinking that today we'll be talking a little bit about Software Factories. I've been getting requests to talk about this, and I've actually wrote about it recently. Maybe that's part of the reasons why I received requests to talk about it. And I would say that the trigger, for me at least, was a series of articles by Dex Hortney from Human Layer.
Speaker 1:But just kind of a of a background, Software Factory, this is a general term for using automated software that manages the code and does everything that is required to write software, deploy it, essentially do everything that is part of the software development cycle and deployment cycle. And it's a step forward or step up from using a tool on your computer. And I feel that we are all going in a direction of software factories. The discussion right now is more about how to do this right, much more than whether or not we should even do it. Because your next software project would need more resources than what your computer has to offer, I assume.
Speaker 1:And you also want that flexibility of having cloud agents, which I talked about it in the previous episode where my cloud agents are essentially local. I just have dedicated machines that are allowing me to log in from anywhere. But wherever you place the actual machines to do the work for you, the principle remains, which is that your agent would need to be in a separate machine. They shouldn't be limited to work when you're on duty, let's call it, and you want to be able to direct them or kind of steer them in the right direction while you're on your phone. So we are really going to see the start of separation from a workstation to a work environment and the environment would be virtual in that sense rather than a specific station.
Speaker 1:And I want to say that my view on this whole software factory is rooted in the fact that I run a real human software factory with automaze. We have a software development firm where we are using our own AI software factory, but we are humans at the end of the day. So I know what it takes to get people on board and what it takes to make sure that the software is of a good enough quality that you, and at what level you can trust the machines to get into a production environment. And I wanna start off with this article. Let me share my screen here.
Speaker 1:It all started here with this great post by by Dex. And he's talking about how he he started an experiment that and this experiment he started in in last year and he tried to run a fully automated lights out factory. And lights out factory means the the meaning is that it's always running. It doesn't need a human intervention. It doesn't need any sort of well, it does need a human instruction, but it doesn't mean human interaction.
Speaker 1:It doesn't need the human to be part of the loop. The software does, and you can see that he writes about it here, slightly lower the page. He has this whole software factory, how it looked a few years ago and how it looks right now with hygienic factory. And essentially he talks about the fact that it produced a lot of slob for him. And he doesn't think that we're fully there yet.
Speaker 1:And I replied jokingly, of course, you're holding it wrong because my experience, and this is an article that I posted as a response, my response was that I don't believe in the Lights Off Software Factory. I think that humans are very much needed in this loop. It doesn't mean that the human needs to be the bottleneck and we're going to talk about it in a few minutes, but we are going to go to the direction where the software is quite good enough where we can fully entrust it to run the pipeline. The question is what the pipeline is, and this is our pipeline. I'll go back to that in a minute and cover it for whoever's going to tune into the audio version.
Speaker 1:I'm gonna spell it out, so don't worry if you can't see the image. But it kind of started with, well, started, was extra ignited, let's call it, further inflamed with a post by uncle Bob. And if you don't know, uncle Bob is an elder or a very young boomer, let's call it. He's been doing software for ages and he himself admitted that he no longer read any of the code written by agents. And not only does he not write most of the code or any of the code, he doesn't even read it.
Speaker 1:And the only reason to be able to get to this point where you have such trust in the process is by having so many constraints that as he put it, you surround the agent with extreme constraints like unit tests, grating tests, QA procedures, quality metrics, mutation testing, coverage, etcetera, etcetera, etcetera. So there's so many tests that if the code the agent produced passes all of that, that it doesn't really matter if it's pretty, it doesn't really matter if it's very readable to a human to some degree, because all these tests quite literally prove that this code is efficient, that it works. So it's not just it works, but it works efficiently if you put in the right tests and that it passes anything from simple linters to performance and profiling. So all these tests kind of reassures us that the code works. So there's really not a lot of added benefits in manually reviewing the code the agent generates.
Speaker 1:My comment was, as I mentioned jokingly, you're holding it wrong because we're using an internal AI software factory within AutoMaze. We call it Cloop and I don't know if this is going to turn into a product or not, we'll see. But the constraints that we put in place in order for something like this to work really gave us the ability to trust it. So let me kind of cover how it works and where the human is still very much required because the human is part of our loop. We didn't let go of the humans here.
Speaker 1:So it all starts off with a ticket and a ticket could either be bug that was caught and traced dynamically from production. We have a feature called Ladybug, which is very similar to tools like Sentry Work. We have code that catches errors in the software and whenever a bug or some exception is being raised, goes through a full trace and sends it as an open issue to our system. And then the system does the decoupling and verifies that it is indeed a bug and it wasn't caused by a third party service not being available. I've yet to have an experience with Stripe was down, but for example, you couldn't generate an invoice because Stripe was down.
Speaker 1:So it's not a bug, but it is something that we need to address. So it's not a bug bug, but it is something that we need to make sure that we have a graceful fallback instead of generating an error. So it starts off with a ticket that either being caught automatically or being entered by a human or client, one of our team or agents themselves while they work on the rest of this loop and or a PRD or a mini PRD that is is being generated by an external source. So a lot of the time I like to brainstorm with Claw desktop or on my phone, same thing. It's just in terms of UI and experience.
Speaker 1:If I don't need external tools, it's great interface. So I do a lot of the brainstorming. And once I have something, then I dump it into this software factory. And then what it does, the first step is the software factory picks it up and it creates a PRD. And maybe even I'll go a step before that and before the ticket even registers, when we set up a project within the Software Factory, the first thing is that the Software Factory does is index the entire project, the entire source code.
Speaker 1:If the source of the project is comprised of multiple repositories, It understands the relationship between them. It understands what it needs. And if it doesn't understand it, it asks questions. But once everything is set up that it knows how to create an instance of that project, It has a full knowledge graph of the code, full index SD code. So it knows everything that there is to know about the code.
Speaker 1:So once the ticket is created and it's time to create the PRD, it already knows what we're talking about. So it already has a baseline. It knows that the ticket is part of this repo, it's part of that feature and it has all the relationship and all the structure mapped out. Now, on the size of the ticket, so let's go to the lower end, we need to change the button color to red instead of blue versus we need to add a new feature then when Azure submit a ticket to our support desk, we launch an army of agents to do something, that's a different scope, right? So based on the scope of PRD, a second opinion agent will jump in and will do two things.
Speaker 1:It will review the code and it will review the PRD and try to see if there are any gaps. These days we're using GPT and Fable, but yeah, so this the baseline, this is how we start. We start with a rotation of GPT and Claude discussing the project and the scopes, they have specific instructions to leverage code that is already existing in the application to try to simplify things from first principles, etcetera, etcetera. We don't want to over complicate our code base. And then the PRD is presented to a human and the human gets assigned to that ticket.
Speaker 1:The human can then review the PRD, review all the artifacts that were generated, if there are any diagrams or anything like that that were generated as part of this plan, and it can either comment and start an iteration process where it sends rejects back to the agent until the PRD is to the human's satisfactory or if the human is happy with the PRD then it approves it. Once it approves that, we're starting an implementation process and the implementation process will start off by breaking down the PRD into tracks. What can be done in parallel? What blocks what? So it will create sub issues in a system.
Speaker 1:It's a Kanban board type of very similar to how linear looks, look and feels. So it will create the sub issues there and it will start knock them off where different agents or different models are used based on the strength of every model. For example, we're using GLM for anything related to design. We found that it's the best front end developer, let's call it. Obviously we are also trying to optimize for cost.
Speaker 1:The underlying harness that we're using underneath all of that is factory by the way, Droid Factory. That's the underlying harness that actually does the coding and they have a very cool feature where we can just tell them, use an automated model. But for some tasks we are going to use a specific model. Anyway, once the implementation is done, we are moving it to the next phase which is writing and running unit tests, quality tests, end to end tests, everything that we need in order to rest assured that the implementer did its job correctly. If everything passes, then we're going through a simplification model.
Speaker 1:So that means that we have another model that this is going to arguably in most cases going to be one of the strongest models. And its job is to see what simplifications to the code can be introduced. Is the code too long? I'm not talking about readability or stuff like that. I'm talking about whether or not the code is efficient enough and runs fast enough, gets profiled correctly.
Speaker 1:So all of that is going through this process. And then finally, once we go through all of that, we have code and security review. The code reviewer is again using a combination of GPT and cloud models where the security review, sorry OpenAI, but Fable is the best one here. The tricky part is to actually get it to find the flaws without it thinking that we're trying to hack the NSA or something. It has this thing whenever you ask it to find flaws in the software security issues, then it automatically to, automatically thinks that you're trying to break into someone else's software and prohibits you from doing that.
Speaker 1:So we found some workarounds to actually have it trust that it is indeed our code that it's trying to review. And then we go through this whole loop. Once the code review passes and everything is green, if it's not green, it's going back to implementation, test, simplification, review implementation, test, simplification, review, blah, blah, blah. Goes through this loop until it's happy or until some sort of a threshold is reached. In our case, it's five times and if this loop wasn't getting the desired result five times, the human is being pinged.
Speaker 1:And the human is being pinged and it says, okay, human, me, the agent, I'm stuck. This is the current status. What do you want me to do? And then the human can intervene and kind of steer the model in the right direction. But if everything passes, essentially the human is pinged again, but this time because they are assigned a PR that the agent created.
Speaker 1:The graph here is actually not true. It's from here we go to the pull request and if the pull request gets merged, then an agent gets triggered where it updates the docs, the wiki, the code graph, make sure that all the cross repository relationship has been updated and so on and so forth. So we don't want to update the code graph or the agent's knowledge of how the code looks before the pull request was merged. And through all of this, we also have a parallel loop that whenever some other process, human or otherwise, updated the main branch of the repository that we're working on, it will automatically merge the main changes if we had like a hotfix or something back to the working branch and make sure that it doesn't break anything before we even get to the pull request phase. So, what I found is that, you know, if you compare the two approaches of trying to have fully lights out, the agents would either produce slop with either fake the results and a lot of mock calls too, just to make sure that the test passes.
Speaker 1:And I'm sure we've all seen coding agents add comments like to do later, this will need to be changed to whatever. So they have this tendency of letting tests pass because that's the goal that you've created for them. So without the human being in the loop as the one reviewing the PR, and I also forgot to mention that when the PR is also important, when the PR is up, the full application is also up in a temporary deployment that if there are any visual stuff and we want to log into the application and we want to see that it actually works, then kind of do a once over with the human eyes, then we also have this environment that we can run the test. But without that, I find that again, we'll either produce slop, either produce false positives, like the test has passed although they haven't, Or the worst possibility is SLOP and false positives with a high token bill because the agent just kept trying different methods because you didn't provide it with some off ramps to say, okay, I'm giving up. I don't have the ability to figure this out.
Speaker 1:And I think that the Lights Out, and I wrote it here, I think that it removed the wrong human. So I think the human is honestly very important that the human is always part of this planning and enforcement. So the human still needs to be part of the loop in the important places, in the what needs to get done, whether or not the plan the agent came up with is aligned with what needs to get done and at the end whether or not what needed to get done got done. So these are the places where the human still needs to be very much in the loop and that's kind of the things that I've covered here. And I think that if you are looking to build software factory lights on, lights off, lights out, whatever you want to call it, I think that if you're building a software factory, you would do yourself a great deal of favor and semi blocking all those fancy terms like, hey, we're doing loop engineering now and we're doing graph engineering because we've always done loop engineering.
Speaker 1:This was development all along. We've wrote something, we tested if it worked and if it didn't work, we went back to the beginning. We've always done loops. It's just now that the machines are doing that. So nothing, I don't think that nothing really changed aside from our ability to automate and speed up a lot of these things, but I don't think that nothing in the methodology had changed or at least should have changed.
Speaker 1:And with that, I want to leave you today is it always kind of goes back to the theme of this podcast, is the old school new tech. It is an old school approach where this is how people wrote software even back when they were using punching cards. It never changed. I don't see it changing. Maybe the human will move, maybe probably the human will move yet again at some point in the next year.
Speaker 1:Their role would probably diminish, but I don't know about you, I wouldn't want to have software that was only tested by a human or on the other hand never got tested by a human. So I think this relationship and this ratio is very important that we don't bother the human because human time is expensive, the mental load is expensive and they're slower than machines. So I wouldn't want to bother the human before the machine thinks it's done or then alternatively that it can't finish the job, but once we are at this stage, I do want the human to look at everything with fresh eyes and kind of look at the proof of work that the agent provided because we're using proof of work. The agents are providing videos and evidence that they actually did what they promised to do. So yeah, this whole system, this is how I think Software Factories should work at least for now.
Speaker 1:I may change my mind. I don't think I'm going to change my mind in the kind of conceptual way, but I will probably change my mind to where the human fits as model gets more and more powerful. But I think that the system as a whole is going to stick around for much longer. So yeah, I think this beats review everything on the one hand or review nothing on the other hand. Yeah, thank you everyone who joined me and I'll see you on the next episode.