Building a Software Factory that actually works

Channel: Greg Isenberg
Published: September 14, 2026
URL: https://www.youtube.com/watch?v=_LCeJZFIsd4

Get your complete Financial OS at https://startup-ideas-pod.link/brex_SIP

Ras Mic returns to explain the phrase "software factory"—a concept that allows you to use AI agents to ship valuable software at scale, like an assembly line. Mic walks through his exact system: four steps (isolate, build, prove, and ship) kept in five or six markdown files that work with any model and any harness. By the end, you can boot up your own factory, run many agents in parallel, and trust the code.

Transcript

What are software factories and why is it going viral? It's basically this concept that allows you to use AI agents to actually ship software that isn't sloppy at all—that is more like a factory, more like think about an assembly line and you're just instead of building physical products, you're building software. And that's kind of the dream. I mean, if you're able to just create this factory that builds software and it's valuable software and you can create multiple apps that generate revenue and add value to people's lives. That sounds pretty good to me.

So, in today's episode, I brought on Ras Mic and he clearly explains the entire process. By the end of this episode, you're going to understand how to set your own software factory up yourself. So, enjoy the episode. I can't wait to see what you build. There's a reason why this concept is going viral and I'll see you at the end.

Today's episode is brought to you by Brex. My company's been on Brex for a year and a half and I started because I kept hearing companies like Vercel, OpenAI, Anthropic were using Brex and I figured if they're using it, why shouldn't I? It's been a game changer. The thing that got me is how smooth it is. It's got high limit cards. It's got banking. It's got AI that handles the back office busy work like expense reports which I don't want to do on its own. It's really just built for this agentic world. If you're building something new, it's time to get Brex. Check it out at brex.com/solutions/startups.

Greg: Mickey, welcome back to the pod. By the end of this episode, what are people going to learn?

Ras Mic: We're going to understand what this bizarre phrase software factory means. I'm actually going to show you how I run mine. It's a lot easier than you think and it's definitely model and harness agnostic. So you don't have to purchase some different product to have a software factory. It's going to be fun and it's going to be simple.

Greg: Okay. So you're going to explain what it is, why it matters, how it works, how to think about it. By the end of this, people are just going to be able to boot up their own software factory if they want or if they think, you know what, this Ras Mic guy, I don't like software factories. I don't like what he's saying. They can pass.

Ras Mic: 100%. With the term software factory, there's been a lot of like startups who have started and you know I'm not here to knock anyone's hustle, but a software factory is completely harness and model agnostic—meaning it doesn't matter what model you use. It doesn't matter what harness you use. It should work, right? Because a software factory is more about someone's workflow, skills, and domain knowledge and it's packed up in specific skills that they use in their development process.

Now, I want everyone to think like the last app that they built. You probably went on Codex, Claude Code, Cursor, whatever it is, and you just typed, right? You said, "I want to build this." And it built it out for you. You saw it and you didn't like it, and then you made some changes, right? And you saw the changes, maybe you liked it, you deployed it to Vercel or to production and you're good to go or you kept on iterating. That's the process.

The whole point of a software factory is in each step of the development process, how can I best maximize the model's capability to get the greatest output, right? And also, how can I move fast, right? Because if we're using the term factory, there's some sort of structure and speed and conveyor belt nature that allows me to ship as quick as possible without losing quality. That's the definition of software factory. Um, I haven't lost anyone hopefully.

Greg: That was perfect. Okay, so understood. But like why does that matter?

Ras Mic: The reason why it matters is intelligence is continuing to increase. We have amazing models like GPT-6 Astra. A good software factory allows you to systemize and use these models in a very efficient way versus just typing in and continuing to go back and forth. And I think it's better I just show you how mine works to give people an idea.

Now, I'll give my skills are available for free. No charge, nothing like that. But I don't want you to blindly copy me. I would like for you to think about it, understand the process and then apply it yourself. That being said, I have about five or six files that make my software factory. I have an agents.mmd file. And for everyone who might not be aware of what an agents.mmd file is, it's basically this one document, this one markdown file that's injected into the agent chat every time you communicate with an agent. So every time I say hi, before the hi is sent, the agents.mmd file is sent. And what's cool about this file is I can sort of dictate how I want the agent to act.

We actually did a video not too long ago, Greg, where I talked about how most people's agents.mmd file is useless because they were telling the agent in the markdown file what the code looked like—already information that's in the codebase that the agent could already know about. But if you look at mine, there's a simple workflow. And this workflow is something that's not native to the agent. So it explains clearly how to do it. And I'll walk you through every single step.

Step One: Isolate

The first step is isolate. There's a skill called new feature. And this is what it does: every new feature starts in a fresh git work tree branched from origin main so agents can work in parallel without conflicts. Never build on main.

So, with the first step when I'm working on a project and I tell it to work on a feature, the first thing it's going to do is isolate. What this basically means is you can think of Greg and Mike's app. You can think of the journey being we started here, we started prompting here and this is when we launched to production and we've got thousands of customers. The way most people work with their agents is at every single step of the journey, they're building a feature, they're building a feature, they're building a feature, and it's a very linear process, right? One feature at a time, one feature at a time, one feature at a time. And if you ever try to work on multiple features at the same time, sometimes there's conflicts, there's issues. People have, you know, "Oh, my agent deleted this file. It overwrote this file."

What this first step isolate does is the following: let's say Greg was like, "I really don't like our landing page." And I'm telling Greg, you know, our API calls can be faster. When Greg works on this feature, what the agent does using my agents.mmd is it's going to create a new branch. And you can think of a branch as a copy paste of the exact moment where the app is. So Greg is going to work on a new branch, a new work tree of the app. A work tree is basically a copy of the app. Like you can think of someone copying a block of text, pasting it in a new document, working on that document, and at some point going to merge it back in the original document. So that's what Greg is doing. He has a new document working on that feature. And guess what? Mike has another feature to work on. So I can do it at the same time or I can do it a different time. I now have my own branch.

Here's what's cool: me and Greg and another person or you yourself with 50 different agents can work on multiple features and there's not going to be an issue of one agent overstepping on another agent's work. This happens a lot to people. If you ever see tweets of people saying, "Man, like, I was working on this and the agent deleted a bunch of stuff," almost always it's because people have their agents working on different features on the same branch. And the agent will do what you tell it to do. So you told it to update the landing page, but then you also told it to make the API calls faster. And now it's noticing, "Oh, these pages, the way they're calling the API suck. Let me delete these and write these again," but then it was working on a design on that page. So issues start to arise.

Isolate allows me to work on multiple features at the same time in parallel without having an agent overstep on another agent. This is the first step of my workflow. This isn't native to the agent. So this makes sense to exist in the agents.mmd file. And when Greg is done or when I'm done, when Mike's done, all I do is merge these changes back and then when Greg's done, he can either do it before me or he can do it after me. But we're merging into the main document and there's not going to be conflicts because we worked on a copy at first. So this allows me to ship fast with multiple agents.

If I show you my terminal, if you notice, there's four tabs. Three of them finished, but I literally have four different features on the same exact app. One's working on an email client. The other one is working on a computer environment, a Linux environment. The other one is doing a landing page update. So I can work on these confidently while still having isolation. It's not native to the agent. This agents.mmd plus the new feature skill allows me to do that.

Any questions, Greg, so far?

Greg: Yeah, I mean it's like crystal clear. I think the way I think about it is if you actually had a team of engineers and you were trying to build an app, you obviously wouldn't be building it all on main and having everyone just be pushing to main and stuff like that. That just doesn't make sense. I think, you know, I'm non-technical and I think you have all of a sudden all these non-technical people starting to build apps and they're running into this. You basically made mention, you know, oh hey man like sometimes it happens that agents overwrite stuff. I mean the truth is 95% of the time if you're building it you're going to have agents kind of mess up and overwrite things. So this is like to me this makes a lot of sense and it's sort of a bigger idea which is how do you structure the way you work with agents to be more like a team versus just, you know, yeah, more like a team.

Ras Mic: Yeah, I mean it's a better name. Team is better than isolate. [laughter] But that's basically what it is.

Greg: Well that's why I'm the marketer and you're the engineer. [laughter]

Ras Mic: Yeah, that's basically what it does. It allows for me to have multiple agents working on different tasks all at the same time without overstepping each other, right? And there's also a cleanup process—once the branch like once the work is merged in the work tree gets deleted all that type of stuff happens. So that's step number one.

Step Two: Build

Number two is the actual building and this I find has this was a skill that I shared originally way back but now it's part of my workflow and I shared it with everyone is code structure. We're going to talk about models soon. But one thing about the models is they are great at doing the work. It just might not be done the best way, right? Especially when writing code.

For example, Claude is, I would say, one of the first models to really write code that I would say, "Huh, like this is better than some of the best engineers I've seen," right? Claude writes really good code. But even Astra, which is the workhorse, most powerful model, my favorite model, some of the code quality decisions it makes—hm. And it's not that the model's not capable. The model is just getting it done and if it could get it done in a sloppy way it'll get it done in a sloppy way.

What the code structure skill does is it writes it in what's called a service layer architecture. Basically it's written in a way where let's say you had you needed human intervention, you hired a developer, very easy for the developer to catch on or you yourself are a developer, very easy for you to catch on. But even for your agents, for them to come back to the code and read the code, they'll be like, "Oh, yeah, it makes sense." I've had GPT-5.6 Sonic write code and it works. It does what it's supposed to do. But then I'll have Claude review the code and Claude will be like, "This is disgusting." Like there's duplications, there's functions all over the place. There's dead code, right? So just because it works doesn't mean it's written well.

This skill gives the agent a guideline on how to write code. So going back to this diagram again, I'm working on a new feature, right? The first thing that happens is isolate. The second thing that happens is the building. And in building, we're using a skill called code structure. Basically in this process when I'm telling the agent, "Oh, build me this landing page, build me this feature." For example, I've been working on this app. One feature that I wanted to build is I wanted a skills repository where I can have different agents of mine connect to this app and store the skills. And I basically told the agent, "Build me that." And as it was writing the code, it kept referencing the code structure skill. So it started to write code in a way that me as a developer I can review. But you know, god forbid I need to hire somebody to review the code. It's not going to be this sloppy cannon where they're confused and they don't know what to do or they overcharge you. It's written in a way for a developer to understand. And I find that if you use another agent that doesn't have context on your codebase, it will understand it very well.

So first we isolate. Second we build, right? And all of these are done in an opinionated way that allow the agent to move fast and to do the thing as best as possibly can be. I think this makes sense, right, Greg?

Greg: Yep.

Ras Mic: Keep going.

Step Three: Prove

So step number three is prove. Here's the thing: agents can't pinky promise, right? So like if you push an agent enough—well, GPT-6 Astra is the reason why it's a big leap in model capability, like it is the least hallucinating model which is fantastic. But like that model aside, most models you can kind of push to like lie or to believe something or sometimes it'll straight up be like, "Oh I actually realized I didn't do this work for you."

So one thing that I have the agent prove is the work that it did. And this is probably my favorite skill.

(capture appears truncated)