Software Factory in Practice: Using AI Agents to Deliver Software Like an Assembly Line

What Is a "Software Factory"

The "Software Factory" concept has been gaining rapid traction in developer circles. Its core idea is to use AI Agents to mass-produce software like a factory assembly line — not the kind of throwaway code you'd expect, but real products that can go live, generate revenue, and create value for users.

In Greg's podcast, guest Ross Mickey (Michael Shmueli) gave a detailed breakdown of the software factory he uses every day. He repeatedly emphasized one key point: a software factory is not a paid product or a special tool you need to buy. It has nothing to do with the model or harness you use. Whether you're on GPT, Claude, Cursor, or Codex, it should work just the same.

"A software factory is more about a person's workflow, skills, and domain knowledge — things that get packaged into specific skills throughout the development process."

In other words, a software factory is fundamentally a structured workflow, and its physical form is nothing more than a few Markdown files. Mickey is candid about this: his entire system consists of just five or six files, the most critical of which is an agents.md file. This file gets injected into every conversation with the Agent to govern how it behaves.

Why It Matters

Model intelligence continues to improve, and top-tier models like GPT are already capable of writing fairly high-quality code. But Mickey points out a counterintuitive reality: a model being able to "get the job done" doesn't mean it's doing it well.

He gave an example: ask a powerful model to write some code, and yes, it functions — but have another model that specializes in code quality review it, and the feedback is often something like "this code is disgusting — it's full of duplication, functions scattered all over the place, and dead code." Models will take the path of least resistance. If they can cut corners, they will.

For non-technical founders, the problem is even worse. Greg, himself non-technical, openly admitted that when ordinary people use Agents to build apps, 95% of the time the Agent will mess things up and overwrite existing files. What the software factory aims to solve is precisely this: "How do you organize the way you collaborate with Agents so it resembles an engineering team, rather than one person going back and forth in a chat window?"

Four Core Steps: Isolate, Build, Prove, Ship

Mickey's entire workflow breaks down into four steps. Greg used a spot-on physical factory analogy to map them out, and the two even coined more intuitive names for each step on the spot.

Step 1: Isolate

This step corresponds to a factory receiving a custom order and opening a dedicated workstation for it — without disrupting the rest of the production line.

Technically, every new feature gets its own fresh git work tree branch pulled from origin main — "never build on main." A work tree is essentially a full copy of the application. The Agent works independently on that copy, then merges it back into the main version when done.

The value here is parallelism. A common mistake people make is asking an Agent to simultaneously update a landing page and optimize an API. The Agent decides the way some pages call the API is terrible, so it deletes and rewrites it — inadvertently wiping out the design changes that were just made. The isolation mechanism allows multiple Agents (even dozens of them) to work at the same time without stepping on each other. Mickey showed four parallel task tabs in his terminal — one building an email client, one working in a Linux environment, one updating a landing page — all safely progressing on the same application.

Git Work Tree is a built-in Git feature that allows multiple branches to be checked out simultaneously into different directories within the same local repository, without needing to clone the entire repo multiple times. Ordinary branch switching (git checkout) means you can only be on one branch at a time, but Work Tree breaks that constraint — each branch gets its own independent working directory and filesystem state, with no interference between them. This is especially critical for parallel AI Agent development: Agent A writes the email module in the feature/email-client directory while Agent B updates the landing page in feature/landing-page, operating on completely isolated file trees. There's no risk of one Agent's writes accidentally overwriting another's work. When merging, each branch simply opens its own Pull Request, and the main branch remains stable and deployable at all times.

Step 2: Build

This is the assembly stage on the line — where the Agent is actually writing code, modifying files, and building structure.

The key here is a skill called code structure, which instructs the Agent to write code following a "service layer architecture." Code written this way is easy for subsequent human engineers, yourself, or a future Agent reading the codebase to quickly understand — it won't turn into an incomprehensible mess. The Agent continuously references this skill during the build phase to ensure output is both fast and well-structured.

Service Layer Architecture is a common backend code organization pattern. The core idea is to separate business logic from route handlers (Controller/Route Handler) and data access layers (Repository/ORM), centralizing it in dedicated "Service" modules. The typical layered structure looks like this: the routing layer only handles receiving requests and returning responses, the service layer encapsulates all business rules and processes, and the data layer only handles database reads and writes. The value of this structure is that changes to any one layer don't cascade and pollute the others. Functions have single responsibilities and are easy to unit test, and new developers (or Agents re-reading the code) can quickly locate where the logic lives. By contrast, "spaghetti code" mixes SQL queries, business logic, and HTTP responses inside the same function. As features pile up, this rapidly degrades into an unmaintainable mess — and it's exactly the kind of code AI Agents tend to produce when given no structural constraints.

Step 3: Prove

This is quality control. Mickey says this is his favorite step, because "Agents can't pinky promise" — many models, when pushed, will lie, or even claim "I actually didn't do that part."

Proof relies on two skills. The first is "evidence-driven testing": if the machine supports it, the Agent records the buggy state before a fix and the working state after. The second is "before & after": generating screenshots before and after for every PR.

In one PR Mickey showed, the Agent built an admin email page, first taking a screenshot to prove the page didn't exist before, then taking one to show the finished result. Performance optimizations work the same way — he brought a page load time down from 815 milliseconds (what he called "the original sin of web development") to 61 milliseconds, with the Agent providing the before-and-after numbers as evidence.

The best part is the automatic feedback loop: if the Agent looks at the "after" screenshot and realizes the feature isn't actually done, it will go back to the Build step on its own and keep working — no human nudging required. Greg described flipping through the before-and-after comparisons as being "like swiping through Instagram Stories," instantly understandable even for non-technical people.

Step 4: Ship

After passing quality control, the product is ready to leave the factory.

This step brings in a third-party code review Agent (Mickey uses Greptile, and also mentions CodeRabbit and Macroscope). A skill called grep loop is triggered automatically: the review Agent assigns the PR a confidence score (1–5) and leaves feedback.

In the example Mickey showed, the initial score was 3/5, flagging issues like pagination problems and missing menu spacing. The Agent automatically loops back through Build → Prove → Ship, addresses the feedback, resubmits, and waits for a new score. 3 becomes 4, 4 gets one more fix, and eventually it hits 5/5. Only at that point does a human step in to take the final action — clicking merge to bring the changes back into the main branch.

AI code review tools like Greptile and CodeRabbit work by automatically fetching the diff (code changes) when a Pull Request is created or updated, analyzing potential bugs, security vulnerabilities, performance issues, and style violations using a large language model that understands the full context of the codebase, and posting comments directly on specific lines of the PR. Unlike traditional static analysis tools (like ESLint or SonarQube), these tools can understand business intent — for example, identifying that "the new pagination logic has a race condition with the existing caching strategy," rather than just flagging syntax errors. The key role of Mickey's scoring mechanism (1–5) in the workflow is to convert "subjective code quality judgment" into a numeric target that an Agent can mechanically act on — if the score is below the threshold, it triggers a rebuild loop. This embeds code quality control into the automated pipeline, eliminating the need for manual line-by-line review.

The Essence of a Software Factory: Workflow, Not Product

Throughout the entire process, Mickey made a point of noting: at no point did they discuss which model or framework to use. A software factory is entirely workflow, skills, and a bit of domain knowledge.

"A software factory really is just a bunch of Markdown files. It's not a product, not a special harness, and not something a company has pre-built for you."

He compared how Agents operate to traditional engineering processes in an organization: a junior engineer writes a feature, opens a PR, attaches tests, and a senior engineer reviews it. The difference now is that this entire mechanism runs on machines.

On the topic of code review tools, Greg added a practical recommendation: if you're seriously building software for real users, plugging in a code review Agent like Greptile or CodeRabbit is essentially a must. Many of these tools offer free tiers more than sufficient for solo developers — there's no reason not to use them.

For founders and indie developers, the significance of this approach is that it elevates "collaborating with AI to write code" from a random, error-prone back-and-forth conversation into a reproducible, reliable, parallelizable production line. You no longer need to read every line of code. Instead, you act as an "Agent manager," using before-and-after comparisons and review scores to judge whether the output meets the bar.