Startup Ideas host Greg Isenberg gets engineer Ras Mic to open his actual agents.md file and walk through the isolate-build-prove-ship loop he runs on real pull requests.
Posted
6 days ago
Duration
Format
Interview
educational
Views
128.2K
1.3K likes
57 · 43
Big Idea
The argument in one line.
A software factory is a four-step markdown workflow, isolate, build, prove, ship, that keeps AI coding agents from overwriting each other and forces them to prove their work before it ships.
Who This Is For
Read if. Skip if.
READ IF YOU ARE…
You're already using Claude Code, Cursor, Codex or a similar coding agent and keep running into it overwriting or deleting your own files.
You run more than one AI coding project or feature at a time and want a way to stop agents from stepping on each other.
You manage a non-technical founder or a small team shipping AI-built software and need a way to trust a pull request without reading the raw code.
You want a repeatable AI-assisted development process that survives switching models or coding tools.
SKIP IF…
You only ever run one small feature at a time in a single agent session, this workflow adds process you don't need yet.
You're looking for a specific paid product to buy, this is a description of a personal five-file markdown workflow, not a tool you install.
TL;DR
The full version, fast.
Ras Mic returns to the Startup Ideas podcast to explain 'software factory,' a term going viral online. His version is model- and tool-agnostic: five or six markdown files that give any coding agent a repeatable workflow. Isolate starts every feature in its own git work tree so parallel agents never overwrite each other. Build enforces a service layer coding style a human can actually read. Prove makes the agent record a before-and-after video, screenshot, or measured number, sending itself back to build if the after state falls short. Ship runs the pull request through a code-review tool like Greptile, looping build-prove-ship until the confidence score hits five out of five before a human merges. The result: one person running up to 15 features in parallel.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Cold open on the 'software factory' phrase, a Brex sponsor read, then Greg reintroduces guest Ras Mic and frames what the episode will teach.
02:17 – 03:44
02 · Software Factory Definition
Ras Mic defines a software factory as a model- and harness-agnostic workflow, packed into skills, built from someone's process and domain knowledge rather than a specific tool.
03:44 – 05:23
03 · Why the Software Factory Matters
As model intelligence keeps rising, a structured workflow is what lets someone use that intelligence systematically instead of typing back and forth in a chat window.
05:23 – 11:34
04 · Step 1: Isolate With Git Work Trees
The 'new feature' skill starts every task in a fresh git work tree so parallel agents never conflict; Ras Mic diagrams it live and shows four terminal tabs each building a different feature.
11:34 – 14:48
05 · Step 2: Build With the Code Structure Skill
A code structure skill pushes the agent to write in a service layer architecture so the output stays readable to a human developer or a fresh agent later.
14:48 – 22:25
06 · Step 3: Prove With Evidence-Driven Testing
Two skills, evidence-driven testing and before-and-after, force the agent to record a broken state and a working state as video, screenshots, or numbers, using a real admin-email PR and a page-speed fix as examples.
22:25 – 26:52
07 · Step 4: Ship With Grep Loop and Greptile
The Greploop skill sends the PR to Greptile for a confidence score; a low score routes the agent back through build and prove until it reaches five out of five and a human merges.
26:52 – 29:21
08 · The Physical Factory Analogy
Greg maps the four steps onto a physical factory: isolate is a custom order's own station, build is the assembly line, prove is quality control, ship is going out the door.
29:21 – 30:02
09 · A Software Factory Is Markdown Files
Ras Mic closes the loop: a software factory isn't a product or a proprietary harness, it's a handful of markdown files anyone can write.
30:02 – 31:29
10 · Closing Thoughts
A closing pitch for using some form of automated code review regardless of which system you build, then sign-off and follow links.
Atomic Insights
Lines worth screenshotting.
A software factory is a workflow encoded in markdown files, not a specific AI model or coding tool, so it keeps working no matter which model or harness you switch to.
Most agents.md files fail because they restate facts the agent can already read from the codebase instead of describing the workflow the agent doesn't already know.
Running multiple coding agents on the same branch, not the agents' intelligence, is the biggest cause of one agent deleting or overwriting another agent's work.
A git work tree gives each agent its own isolated copy of the app, so two agents can build unrelated features at the same time without conflicts.
AI models will get a coding task done, but left unguided they will get it done in a sloppy, hard-to-maintain way.
A code structure skill that enforces a service layer architecture keeps AI-written code readable to a human developer or a completely different agent later.
AI coding agents can be pushed into claiming a fix works when it doesn't, so proof has to be a video, screenshot, or measured number, not the agent's word.
When an agent's own after-screenshot shows a feature isn't actually finished, a well-built workflow sends it back to the build step automatically, with no human intervention.
For invisible changes like performance work, a before/after number is the proof: one page's load time went from 815 milliseconds to about 61 in one recorded example.
A third-party code review tool that returns a numeric confidence score turns 'looks good to me' into a real quality gate an agent can be looped against until it passes.
One operator running this four-step loop reported working up to 15 features in parallel across multiple agents, reviewing the visual proof instead of the raw code.
The four steps of a software factory map onto a physical assembly line: isolate is a custom order's own station, build is the assembly line, proving is quality control, shipping is going out the door.
Treating an AI coding setup like a small engineering team, with isolated workspaces and a review gate, is offered as the fix for the 'the agent deleted my files' complaint common on social media.
The entire system described here runs on five or six markdown files, with no paid product or platform required to build one yourself.
Takeaway
The four markdown files that make AI agents trustworthy
AGENT WORKFLOW
A software factory is a four-step markdown workflow, isolate, build, prove, ship, that keeps parallel AI coding agents from overwriting each other and forces every pull request to prove itself before a human merges.
02Software Factory Definition
A software factory is defined as a workflow, a set of skills, and domain knowledge packed into markdown files, not a specific model or harness.
The whole system fits in five or six markdown files that plug into any AI coding tool.
03Why the Software Factory Matters
As model intelligence keeps rising, a structured workflow is what lets you use that intelligence systematically instead of typing back and forth in a chat window.
The skills behind this workflow are shared for free, with the request that people understand the process before copying it.
04Step 1: Isolate With Git Work Trees
A 'new feature' skill starts every task in a fresh git work tree branched from the main codebase, so agents work in isolated copies instead of the live version.
Working multiple agents on the same branch, not model quality, is described as the real cause of agents deleting or overwriting each other's files.
Isolating each feature lets one operator run several agents in parallel, shown here as four terminal tabs each building a different feature on the same app.
05Step 2: Build With the Code Structure Skill
A code structure skill pushes agents to write in a service layer architecture so the result stays readable to a hired developer or a different agent later.
Even strong models will get a task 'done' in a technically-working but disorganized way unless a style guideline forces better structure.
06Step 3: Prove With Evidence-Driven Testing
Evidence-driven testing has the agent record a broken before-state and a working after-state, as video, screenshots, or numbers, instead of taking the agent's word that a fix worked.
When the after-proof shows the fix isn't actually finished, the workflow sends the agent back to the build step automatically, with no manual prompting.
For invisible changes like page speed, the proof is a measured before/after number, one example given: a page went from 815 milliseconds to about 61.
07Step 4: Ship With Grep Loop and Greptile
A 'grep loop' skill sends every pull request to a third-party code review tool, in this case Greptile, which returns a numeric confidence score.
A low score routes the agent back through build and prove automatically until the score reaches five out of five, at which point a human clicks merge.
This review step is presented as the one most builders skip, and the one most worth adopting even outside this exact four-step system.
08The Physical Factory Analogy
The four steps map onto a physical factory: isolate is a custom order getting its own station, build is the assembly line, prove is quality control, ship is the loading dock.
Framing AI-agent management as running a small factory, rather than chatting with a single assistant, is offered as the mental model that makes the workflow click.
09A Software Factory Is Markdown Files
The entire software factory is, in the end, just five or six markdown files, not a paid product, a proprietary harness, or a specific model.
That framing is offered as a caution against startups marketing 'software factory' as something you have to buy rather than something you can write yourself.
Glossary
Terms worth knowing.
Software factory
A repeatable coding workflow, stored as a handful of markdown files, that tells an AI coding agent how to isolate, build, prove, and ship a feature so the process works with any AI model or tool.
agents.md
A single markdown file automatically added to every message sent to a coding agent, used here to store a repeatable process instead of facts the agent could already read from the codebase.
Work tree
A separate working copy of a codebase, branched from the main line of code, that lets one agent build a feature without touching files another agent is changing at the same time.
Service layer architecture
A way of organizing code into clearly separated layers so a human developer, or a different AI agent with no prior context, can open the codebase later and understand it quickly.
Evidence-driven testing
A workflow rule that has an agent record a broken 'before' state and a working 'after' state, as video, screenshots, or measured numbers, so a fix is proven rather than just claimed.
Before-and-after skill
A fallback proof method for when full evidence-driven testing isn't possible, requiring the agent to capture a before screenshot and an after screenshot inside the pull request itself.
Greptile
A third-party AI code review tool that reads a pull request and returns a confidence score, letting a team gate merges on a quality bar instead of trusting the coding agent's own judgment.
Greploop
A skill that automatically sends a finished pull request to a code review tool like Greptile, and if the score comes back low, routes the agent back to the build step until the score improves.
“There's some sort of structure and speed and conveyor belt nature that allows me to ship as quick as possible without losing quality.”
crisp definition line, works as a title-card hook→ TikTok hook↗ Tweet quote
15:00
“You know, agents can't pinky promise, right?”
funny one-liner that also teaches the real lesson behind the prove step→ IG reel cold open↗ Tweet quote
21:20
“815 milliseconds. This is a sin in web development.”
concrete number plus a strong opinion, easy to caption→ newsletter pull-quote↗ Tweet quote
21:50
“I can just merge away and live my best life and go outside and touch grass.”
relatable payoff line for non-technical founders reviewing AI-built PRs→ TikTok hook↗ Tweet quote
29:30
“A software factory is literally just a bunch of markdown files.”
counterintuitive reveal that undercuts the hype around the term→ IG reel cold open↗ Tweet quote
The Script
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
17px
metaphoranalogy
What are software factories and why is it going viral? I mean, 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 Ross Mike, 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 slash solutions slash startups. Link in the description.
Mickey, welcome back to the pod. By the end of this episode, what are people going to learn? 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. 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 Ross Mike guy, I don't like software factories. I don't like what he's saying.
They can pass. 100%. 100%.
With the term software factory, there's been a lot of like startups who've 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. 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, Cloud 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 long bloated Michael Shumalis translate definition of software factory. I haven't lost anyone, hopefully, Greg.
That was perfect. OK, so understood. But like, why does that matter?
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, 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 .md file. And for everyone who might not be aware what an agents .md file is, it's basically this one document, this one markdown file that's injected into the system prompt. Sorry, not in the system prompt.
That's injected into the agent chat every time you communicate with an agent. So every time I say hi, if there's an agents .md file, before the hi is sent, the agents .md file is sent. And what's cool about this file is I can sort of dictate.
how I want the agent to act. And we actually did a video not too long ago, Greg, where I talked about most people's agent .md file is useless because they were telling the agent .md file what the code looked like and already information that's in the code base that the agent can 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.
The first step is isolating. There's a skill called new feature. And this is what it does.
It says every new feature starts in the fresh Git work tree branched from origin main. So agents can work in parallel without conflicts. Never build on me.
And if you know when Michael is on Greg's channel, there's always diagrams. We're about to draw. 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. And what this basically means is you can think of Greg and Mike's app. You can think of Greg's and Mike app, like the journey being, you know, we started here, we started prompting here, and this is when we launched the production.
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 and overwrote this file. What this first step isolate does is the following.
I'm going to show via diagram. So 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 myagents .md 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 he has 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, Greg, 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, parallelly, without having an agent overstep on an 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 .md file. And when Greg is done or when I'm done, and I'll explain like the workflow for this, but just to close the loop. 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 and i can maybe show here if i show you my terminal if you notice there's four tabs of bezel 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 .md plus the new feature skill allows me to do that. I'll pause here. Any questions, Greg, so far?
Yeah, I mean, it's like crystal clear. I think it's the way I think about it is if you actually had a team. of engineers and you are trying to build an app.
You obviously wouldn't be building it all on main and having everyone just being 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 know, you basically made mention, you're kind of like. sometimes it happens that agents overwrite stuff. The truth is 95 % of the time you're going to have agents kind of mess up and overwrite things.
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 Yeah, no, just more like a team. Yeah, I mean, it's a better name.
Team is better than isolate. I might take the team. That's why I'm the marketer and you're the engineer.
But yeah, that's basically what it is, right? Isolate sounds like some sort of whey protein that I'm going to enjoy. So if you guys check the link, there will be a name update very soon.
But that's basically what this 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 I won't get into. Like 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.
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. There's, for example, Fable 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?
Like Fable writes really good code. But even Astra, which is Workhorse's most powerful model, my favorite model, some of the code quality decisions it makes is, 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. It writes it in what's called a service layer architecture.
Won't bore everyone, but basically it's written in a way where let's say 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 Sol write code, and it works. It does what it's supposed to do. But then I'll have Fable review the code and Fable 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 and I'm going to I hope people are seeing the.
factory nature of it the second thing that happens is the building and in building we're using a skill called code structure and basically in this process when i'm telling the agent oh build me uh this landing page build me uh this feature uh for example i've been working on this app and the one feature that i wanted build is i wanted a skills like 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 the slob canon 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 code base, it will understand it very well. So first we.
isolate excuse the bad name 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 great yep keep going so step number three is prove here's the thing um you know agents can't pinky promise right so If you push an agent enough, well, GPT -6 Astra is the reason why it's a big leap in model capability.
It is the least hallucinating model, which is fantastic. But that model aside, most models you can kind of push to 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 do is to prove the work that it did. And this is probably my favorite skill. There's two skills involved in this, evidence -driven testing.
And basically what evidence -driven testing does, if your machine has the capability to do it, it will literally record the before state, meaning before the feature, or let's say you're trying to fix a bug, it will record the bug in action. And what it will do after is after it's done fixing, it will record a working version after.
Right. So this is what evidence driven testing does. It proves that the fix actually was made because you'll be surprised.
Sometimes the agent will write the code and it'll think it worked, but it didn't test it or improve that it worked. And it just told you to work. So I need to make sure that the agent actually prove this work.
But let's say let's say your machine does not have the capability to do that. There's another skill called before and after. And I can actually let me pull up.
a PR to show this, Greg, because I think it is better show you than I tell you. This is a PR my agent made. I didn't make this.
The agent made this. And I wanted it to create an admin email page and connect to an email service that I made. Look at what it did.
It showed me a before state where the page didn't exist. It didn't. And it shows me the after state.
right so for every feature that i'm building every pr that i'm doing i am getting a before state and after state and the reason why this helps this helps me like i'll be honest i'm not reading all my code nowadays like i might like okay did this uh like let's see like barely it's a skim it's a skim situation i'll be honest the skims have even become less and less now But a lot of the things that I'm doing now is I'm working on the front end where I make sure that it's following my code structure skill and I make sure I'm getting before and after screenshots.
Right. I can even pull up. Let me pull up another example.
Here's a more prominent example where I was working on a specific computer feature where I wanted to give my agent a computer and it just didn't work. The first run didn't work. I didn't even have like my software factory set up.
I was working on a different machine and it pushed the code and it didn't work. As you can see, nothing's going on. I told my agent it didn't work.
Use the skills, use the factory. And this is the after screenshot with it actually using the app. Right.
So these skills, the prove and the before and after force the agent to give me. factual, like a before and after proof, whether it's a video or it's screenshots. And there are times where it'll do the before, but then it'll do the after and it'll be like, oh, I just looked at the after screenshot or the after video and I didn't really finish the feature.
So go back to what? It'll go back to building, right? This is the factory nature of it.
I didn't have to tell it, oh, yeah, you failed your before and after. Go finish. The skills are written in a way where the agent knows, OK, the before and after criteria hasn't been met.
I have to go continue on building. Right. So this gives me a visual representation of the work that's been done.
It makes reviewing, especially if you're a non -technical person, it makes reviewing easier because, you know, I just look at some screenshots or a video. Right. So in the building process, at some point, I'll have a PR where I get to see before and after.
And even though I might not understand all this mumbo jumbo. It will show me visual proof that the work's been done. Now, I already hear somebody asking, what if the proof is not visual?
And there's actually a PR. I'll show someone performance. I think it's this one.
Okay, so I wanted to do another example here. I wanted to do a performance update. Meaning for one of the apps I was building, the clicks weren't snappy enough.
Like you can see now everything is snappy. It's loading fast. That wasn't the case.
So I told the agent, fix it. And it did. And it did end up giving me screenshots.
But let's say this was like something that it couldn't give me screenshots for. It will write test and then it'll give me the results. In this case, it checked the speed at which the page was loading before.
In this case, one of the pages, 815 milliseconds. This is a sin in web development. Like this cannot happen.
And mind you, this was written by GPT 5 .6 Sol, right? Great model, but it got it down to 60, 817, 61. So I have, again, actual proof by the agent that it's done what it said it did in the review process.
I'll pause right there. Anything I've missed so far, Greg, or does it? So, you know.
If you're trying to build a software factory, trust obviously is going to be a big part of that. And I think what you're saying is, hey, if you're going to have all these agents building features, building apps, we need to be able to trust the things that it's going to create. So what you're saying is, here are a couple skills that allow you as the agent manager, where in this case...
Mickey, you're like, you are the agent manager, right? You're not deep in the code anymore. You're kind of just looking at what's happening.
And what's cool about the before and after visual stuff is it's kind of good for millennials and Gen Z or people on Instagram stories or Snap stories, stuff like that. It's almost like you're just like clicking through story to story. Yes, yes, no.
Like it's bite size. Basically, that's literally it. right there, right?
It's allowing me to build trust with the agent because, and what's funny is like you said earlier, it kind of clicked in my head. This is what like normal organizations used to do with their engineers, right? It's like you build a feature and then there was someone whose job, like a senior engineer, whose job was to review your work and you would have this PR with this description and it would show, okay, basically this is the work that I've done and this is the test that I've written, right?
It's basically the same thing, except now we're doing it with machines. Like that's essentially it. And an example of the video, this is me using Cursor Cloud Agents.
It says proof of improvement. And like this is a video of the agent at work using the app, right? So this allows me to your point, like Instagram, TikTok, I can watch this and see, all right, okay, the agent actually built this and it works.
This makes it easy for me. to not have to read code and I can just merge away and live my best life and go outside and touch grass. So there's that.
Now we have one final step, which is the ship step. Now, the ship step I mentioned before and after, but there's this skill called Greploop, which uses a third -party service named Greptile, which is a code review agent. Now, you don't need to use a code review agent, but if you're really serious about building software and it's going to be used by users, I highly suggest using some code review agent.
Greptile is my favorite. Code Rabbit, Macroscope, there's tons of good ones out there. But me using Greptile, they have this skill called Greploop.
And basically what this does, and I think I'll show it. with this pr greptile leaves these summaries and then it gives feedback for example this was the initial feedback it gave um on the pr there was some issue with you know pagination right here some menu space wasn't preserved so it gave this feedback meaning the agent that wrote the code missed these things and that's fine it happens right even humans miss these things right But what happens is Greptile not only gives feedback, it gives a confidence score.
Now, this is a five out of five because after the feedback was given, if you see my name and then this line over here, the feedback was addressed. My agent addressed the feedback. But before the feedback was addressed, this score was a three out of five.
What that tells my agent is that there are things that it missed and it needs to look at it. What the greploop skill does, and by the way, this happens automatically. Someone doesn't have to write greploop.
The agent will do it automatically. What it does is as follows. It says it opens the PR with the before and after proof embedded in the description.
Whenever the change has a visible surface, measured numbers or output pairs, when it doesn't, it'll give you numbers, right? Or screenshot. And then look what the agent does.
It runs greploop or greploop apps. The difference is greploop apps, if your file change was like 10 ,000 lines plus, that skill activates and you don't have to worry. The agent does it itself.
But look what it does. It says, Greptile reports five out of five until resolved comments finished by presenting PRURL.
Basically, what this means is the agent will take the feedback it got. It will go back to build. So check this out.
Let's say we're at the point. Let me write this down. We're at the point.
We're at build. We're at ship, right? And it's now running greploop.
When I get a feedback score, a confidence score, and it's three out of five. What now happens, remember we were talking about loops. This is actually a good loop.
What happens is this goes back to building. Now the agent goes back to step two. It starts to build.
After it builds, what does it do? It proves and then it shifts. And here's what happens.
Automatically, the agent will wait for a new score. Greptel then gives us a four out of five. We caught some things, but there's one final thing we missed.
Go back to building. Right. It builds.
It proves. And guess what it does, Greg? It ships.
And now I have a five out of five. When I have a five out of five, what's left now is for me to merge. And I think maybe I have an open PR right here so I can show you what that looks like.
What's left for me is to just click merge. When I click merge, what happens is this is finally back in the main copy of the app, of the main version of the app. And I did this while working on 15 either simultaneous features, 15 different features with different agents, sub -agents, all that type of stuff.
What this allows, and this is the factory nature, it allows for an agent to have an isolated instance where it can work on its own. It has guidelines on how to build. It has a methodology to prove its work.
And then it has an external service proving its work, checking its work. And if its work is not up to standard, it has to continue in a loop working until that standard is met. Once I get a five out of five, this is when I enter the picture.
This is what a software factory is. Notice we didn't talk about model. We didn't talk about harness.
It's all workflows, skills, and a little bit of domain knowledge, right? Not everybody works the same. This is how I work.
But I found great results. With this, I'll pause right here, Greg. Let me know what I need to further explain or add on.
What's clicking in my head is just really this physical factory analogy for a software factory. So just to summarize, I'm going to tell you how I'm seeing it and I want your thoughts. So the isolate piece and the step one.
That's like a factory taking a custom order and giving it its own station so it doesn't mess with the rest of production. You called it a work tree in software. It's a branch, a work tree, an isolated environment, but that's the basic concept.
Number two, build. Build is the assembly line. The agent is actually like...
cutting and welding and assembling and wiring the product. Obviously in software, you're not doing that. You're writing code, you're changing files, you're adding structure to things.
You're actually creating something that's real in a software sense. Step three is... the proving step, which is basically a fancy way of saying quality control.
Before anything leaves the factory, someone has to test it. You're not just going to create a product and not have people test it. Does it turn on?
Does it fit? Does it break under pressure? All the things.
I'm picturing a car factory or something like that. In software, you can run tests like... Well, you can run tests, you can preview it, you can do logs and the screenshots you showed.
And then lastly, the shipping piece, it's basically like once it passes quality control, it's going out the door. But there's going to be some things that you have to let, you're going to have to merge it, you're going to have to deploy the PR, you're going to have to do release notes, you're going to have to... give feedback back to the product team because maybe it doesn't pass quality control and then you have to do that loop again, right?
Exactly. I think I might actually rename everything I've written to what you said because now I'm realizing, oh yeah, my names are terrible. That's exactly how this works.
Cool. So basically what we're doing here is we're taking a factory. And we're making it a software factory.
Basically. So, and this is why like I've seen it get not to knock people, startups and products and stuff like that. Like a software factory is not a product.
It's not a special harness. It's not a like, oh, this company built a software. No, a software factory is literally just a bunch of markdown files.
And this is also another insane thing off topic, maybe a different video is some startups are now an agent with a couple of markdown files. We've really entered that time so I hope this made sense for everyone and it excites everyone. I'm very excited with the time we're in right now because a lot of things are possible now.
100%. This is insane that you're actually able to do this. It's cool that people like you are sharing this because I think it's worthwhile.
I want to just do one quick note on greploop or any code. review software. I think if you're serious, no affiliation with GrepLoop or anything like that, but I think if you're serious about creating software, having some code review software is pretty, I don't understand why you wouldn't use a GrepLoop, a CodeRabbit, one of these tools.
we in business and i know because a lot of business people are watching you know we take the service we provide and all that stuff seriously but it seems like with building software like we just don't care right and if you have people who are going to use your app like i don't know like there's a level of like empathy i have for the user on the other side and you know like a lot of these like startups because they've raised bajillions of dollars like they have a lot of free tiers like you know You can cycle through free tiers and use a bunch of this stuff for free, right?
So I highly encourage if you're building something that you're serious, you're passionate about, I would use a code review agent of any kind. Yeah, cool. Thanks for coming on.
Thanks for sharing the sauce. I'll include links for where to follow Mickey on the internet, on YouTube, all those places, his software that he's creating to go give him a follow. dude i'll see you next time i appreciate you greg as always thank you everyone for showing love and watching and yeah we'll see you in the next one
The Hook
The bait, then the rug-pull.
The video opens on the question everyone's been asking about a phrase suddenly everywhere online: what is a 'software factory,' and is it actually useful or just a rebrand? Ras Mic answers by pulling up his own markdown files and walking through a real pull request end to end.
Frameworks
Named ideas worth stealing.
05:23model
Isolate, Build, Prove, Ship
Isolate
Build
Prove
Ship
The four-step loop that structures the whole software factory: isolate a feature in its own git work tree, build it under a code structure skill, prove it worked with recorded before/after evidence, then ship it through an automated code-review loop before a human merges.
Steal forany workflow running more than one AI coding agent against the same codebase
CTA Breakdown
How they asked for the click.
VERBAL ASK
00:53product
“Get Your Complete Financial OS at Brex”
Standard mid-roll sponsor read delivered as a personal endorsement ("my company's been on Brex for a year and a half") right after the cold open, before the interview proper begins.
Add Modern Creator as a preferred source and Google shows you more of our breakdowns in Search, Top Stories, and AI Overviews. It only changes what you see, and you can undo it in your Google settings anytime.
Add to Preferred SourcesOpens your Google source preferences with us pre-loaded. Tick the box and you're done.
A two-person breakdown of OpenAI's top-tier model that skips the game demos and goes straight to code audits, nine money-making agent prompts, and a Raspberry Pi speaker built and shipped in about 30 minutes.
Greg Isenberg's nine-part framework for turning Claude Code into a 24/7 AI employee, walked through live on a real med-spa idea, from workspace and memory files to scheduled routines and parallel agent sessions.
A Digg founder walks through the full pipeline of a personal Techmeme-clone he built alone — from RSS to vector clusters to an editorial gravity engine.
Greg Isenberg sits down with designer Meng To to unpack DESIGN.md — Google's open-sourced markdown spec for portable design systems — and how a one-file blueprint plus a library of named 'skills' replaces template-shopping for vibe coders.
00:27
00:53
01:16
01:35
01:56
02:49
03:11
03:33
04:21
04:45
05:10
05:57
06:20
06:44
07:07
07:30
07:53
08:16
08:40
09:03
09:26
09:49
10:36
10:59
11:22
11:46
12:10
12:34
12:58
13:45
14:11
14:35
15:00
15:26
15:51
16:16
16:42
16:59
17:33
17:57
18:23
19:14
19:29
20:05
20:30
20:56
21:21
21:46
22:03
22:37
22:56
23:25
23:49
24:14
24:38
25:29
25:51
26:15
26:39
26:55
27:54
28:18
28:43
28:56
29:41
29:51
30:19
30:33
31:08
22:52
48:10
48:09
56:25
1:04:40
51:02