OMX Helsinki — S&P 500 — DAX — NASDAQ 100 — STOXX 600 — EUR/USD — EUR/SEK — BTC/USD — ETH/USD — Euribor 3M — Euribor 12M —
Software Factory: How Founders Ship AI Code Fast
Startups and entrepreneurship

Software Factory: How Founders Ship AI Code Fast

Heidi Aalto AI 16.09.2026 6 min read
Share article

Inside the four-step system that turns AI coding agents into a reliable production line

Somewhere between “chat with an AI until it writes code” and “run a real engineering team” sits a method most founders have never heard named. Ras Mic calls it a software factory, and when he shared his screen on Greg Isenberg’s podcast, the term stopped sounding like branding and started sounding like a system. In his framing, a software factory is nothing more than a workflow, a set of skills, and domain knowledge, packed into five or six markdown files — small enough to read in an afternoon, portable enough to run with any model and any harness.

That distinction matters more than it sounds. Most people typing into an AI coding assistant are having a conversation. Mic is running a software factory — a repeatable line that turns a rough feature request into a shipped, verified pull request, over and over, without him rewriting the instructions every time.

What a Software Factory Actually Is

A Workflow, Not a Product

Mic is explicit that a software factory is a method, not something he sells. The core document is a single agents.md file, loaded into the agent’s context ahead of every message. Most builders fill that file with facts the model could already pull straight out of the codebase — file structure, naming conventions, tech stack. Mic fills his with the workflow instead, on the logic that the missing ingredient was never information. It was process.

That’s also why the factory outlives any single model. Mic names GPT-6 Astra as his current workhorse and the model with the lowest hallucination rate he’s tested. But the point of the system is that when a better model ships next quarter, the factory doesn’t need to be rebuilt — only the engine underneath it changes.

The Four Steps: Isolate, Build, Prove, Ship

The factory breaks into four stages, each backed by its own skill.

Isolate: One Git Work Tree Per Feature

Every new feature starts in a fresh git work tree branched from origin main. A work tree behaves like an independent copy of the app, so two agents can work at the same time without touching each other’s files. On the call, Mic showed four terminal tabs running four separate features against the same codebase — and in his own daily use, he pushes that up to 15 features running in parallel.

Build: A Skill That Enforces Readable Code

Left alone, models get the job done, but often in a sloppy way. Mic’s build step applies a code-structure skill that pushes the agent toward a service-layer architecture, the kind a human developer could open cold and actually understand. The goal isn’t a clever solution. It’s a codebase that a hired engineer, or a different agent six months later, can still read.

Prove: Evidence Before Anything Ships

This is the stage that separates a software factory from a chat window that occasionally produces working code. Two skills — evidence-driven testing and before-and-after — record the broken state, do the work, then record the working state, and embed both directly in the pull request. If the “after” doesn’t actually show the fix, the agent sends itself back to the build step on its own, no extra prompt required.

For work where success isn’t visually obvious, like performance tuning, the proof becomes a number instead of a screenshot: one page Mic showed went from 815 milliseconds down to roughly 61. That kind of evidence echoes a point made in why proof beats pitching — a before-and-after number convinces faster than any amount of talking, whether the audience is a customer, an investor, or just yourself at 11 p.m. wondering if the fix actually worked.

Ship: A Loop That Keeps Score

The final skill sends the pull request to Greptile, a third-party code review agent, which returns feedback and a confidence score out of five. A score of three, for example, sends the agent back into the build step to fix what was flagged, then back through review — a loop that repeats until the code earns a full five out of five. Mic reviews the visual proof and the score rather than reading raw diffs line by line.

Why the Timing Matters for Founders

None of this works without agents capable of following multi-step instructions unsupervised, which is a recent capability. It also leans on a context window large enough to hold several markdown files, the surrounding codebase, and the current task without losing the thread — the same shift covered in this look at how bigger context windows are changing what AI agents can handle. A software factory is really a bet that model intelligence keeps climbing, and that founders who already have the conveyor belt built will capture more of each improvement than the ones still typing prompts one at a time.

That has a knock-on effect worth naming honestly. A workflow that runs 15 features in parallel and merges only what passes review starts to look less like a personal productivity trick and more like a small engineering org compressed into one person’s terminal. It’s worth reading alongside the wider debate over what AI-assisted output means for who owns the work and who gets paid for it, because a software factory doesn’t just write code faster. It changes how many people are needed to run the process at all.

What Founders Can Take From This

You don’t need Mic’s exact skill files to borrow the underlying idea. Three things are worth stealing regardless of your stack: separate every feature into its own isolated environment so agents can’t collide, insist on visible proof — screenshots, video, or numbers — before anything is called done, and build a review loop that sends work back automatically instead of trusting a single pass.

The physical factory analogy holds up well: structure and a conveyor belt beat one very talented person eyeballing every part by hand. Mic’s biggest claim, watched in full, is a simple one — a software factory is markdown files, not magic. Which means it’s copyable by anyone willing to write down the process instead of skipping straight to the prompt.

A software factory is markdown files, not magic.

Structure and a conveyor belt beat one very talented person eyeballing every part by hand.

Sources

Heidi Aalto AI

Author

Heidi Aalto AI

Startup reporter

In the startup world, every idea is a potential breakthrough.

heidi@innohub.fi

Innohub TV

Watch this content also on Innohub TV

We picked clips from Innohub TV that continue the same topic.

Open Innohub TV
Open the AI assistant chat. The chat loads only when you open it.