Build a Software Factory That Actually Works

Direct Answer

A software factory is a repeatable path from a task to a reviewed change, with enough isolation and evidence that several coding agents can work without turning every result into a forensic exercise. In Greg Isenberg's course with Ras Mic, also known as Michael Shimeles, that path has four stages: isolate, build, prove, and ship.

The useful idea is not “run fifteen agents.” It is that every agent receives the same operating method. A new task gets its own branch and worktree. Architecture guidance shapes the implementation. Tests and before-and-after evidence show whether behavior changed. A pull request then enters an independent review loop before a person decides whether to merge it.

Watch the Full Software Factory Course

Credit and evidence note: the workflow and demonstrations come from Greg Isenberg's full course with Michael Shimeles, published on 14 September 2026. The current public skills, workflow wording, privacy cautions, and review requirements were checked against Michael's repository on 15 September 2026. Claims about running fifteen features and individual performance gains are creator-reported examples.

What a Software Factory Actually Is

Michael defines the factory as a workflow, a set of skills, and domain knowledge packaged in Markdown. That definition separates the operating system from the model and the coding interface. The same repository-level process can guide Claude Code, Cursor, Codex, or another agent capable of using Git, tests, a browser, and review tools.

The public repository currently contains an AGENTS.md template and focused skills for new features, code structure, evidence-driven testing, before-and-after capture, Greptile review loops, and copy cleanup. The file is short enough to inspect, version, and change with the codebase.

The Four-Stage Loop

Each stage exists because model capability alone does not create an accountable development process. A strong model can still edit the wrong branch, follow a weak architecture, test only the happy path, or persuade itself that a screenshot proves more than it does.

1. Isolate Every Task

The new-feature skill starts work from origin/main in a fresh Git worktree. A worktree gives one repository another checked-out working directory tied to its own branch. Several agents can therefore edit separate filesystem trees instead of touching one shared checkout.

This prevents a common failure: one agent rewrites files that another agent is actively changing. It does not guarantee conflict-free integration. Two branches may still change the same function, schema, dependency, lockfile, or interface. The conflict appears later during rebase or merge.

• Use one branch and one worktree per task and agent.
• Check open pull requests and uncommitted changes for overlapping files before work begins.
• Assign ownership for database migrations, lockfiles, generated code, and shared configuration.
• Give each worktree its own ports, test data, queues, and temporary storage where needed.
• Keep the worktree until its pull request is merged or closed.

2. Build to Explicit Architecture

Michael's code-structure skill guides agents toward a service-layer architecture. Boundaries or actions coordinate why and when work occurs, while services own reusable implementation logic through explicit inputs and structured returns.

The broader principle matters more than one architecture style: encode the rules that a fresh agent cannot reliably infer. A mature repository may prefer vertical slices, domain modules, functional cores, ports and adapters, or framework-native patterns. The factory should teach the local choice and show examples from the codebase.

A build stage needs more than a style preference. It should define permitted dependencies, authentication boundaries, data ownership, error behavior, accessibility expectations, migration rules, performance budgets, and exact commands for linting, tests, types, and builds.

1. Read the task, repository instructions, and nearby implementation.
2. State the files and contracts likely to change.
3. Implement the smallest complete behavior.
4. Run repository checks and inspect the diff.
5. Remove unrelated edits and generated noise.
6. Stop when an unresolved product or security decision requires a person.

3. Prove the Behavior Changed

The evidence-driven-testing skill requires the broken or previous state to be captured before implementation, then the working state after it. Visible changes may use screenshots or recordings. Invisible changes need measured output, such as test results, response pairs, query plans, or performance numbers.

In the course, Michael shows a page moving from about 815 milliseconds to roughly 60 milliseconds. That is useful project evidence, not a universal performance result. A credible comparison holds the environment, route, data, cache state, sample size, and measurement method steady. One fast run is weaker than a distribution across repeated runs.

Evidence should correspond to the ticket's definition of done. A polished recording can prove that one flow worked once; it cannot establish security, absence of regressions, or production readiness on its own.

4. Ship Through an Independent Review Loop

The ship stage assembles the pull request, includes before-and-after proof, and invokes the Greploop skill. Greptile reviews the change, the agent addresses findings, and the loop continues until the configured target is met. Michael's public template requires a Greptile score of 5/5 with zero unresolved comments before presenting the PR URL.

That threshold is a workflow gate, not a guarantee. Automated reviewers can miss design mistakes, misunderstand product intent, or agree with code produced by another model. Repository checks, domain review, security review, and a human merge decision remain separate gates.

The course mentions CodeRabbit and Macroscope as alternatives. The correct reviewer is the one your team can evaluate, configure, and monitor. For high-risk changes, use a genuinely independent method: another model, static analysis, security tooling, or a person with relevant expertise.

Why Five or Six Markdown Files Can Be Enough

Markdown makes the factory portable, inspectable, and version-controlled. A team can review the workflow in the same pull request as the code, trace when a rule changed, and adapt it across model providers. The instructions remain company assets instead of disappearing into one person's chat history.

Small files also force useful separation. The repository-wide AGENTS.md should define sequence, hard boundaries, and local commands. A skill should explain one repeated operation. Ticket content should hold the task-specific outcome. Tests should encode behavior. Mixing all four into one giant instruction file makes maintenance and debugging harder.

Controls for Parallel Agents

Michael reports running as many as fifteen features in parallel and reviewing visual proof instead of reading every line first. That is an experienced operator's current workflow, not a sensible starting target for every team. The bottleneck moves from typing code to defining tasks, managing shared dependencies, validating evidence, reviewing changes, and integrating branches.

• Dependency map: identify tickets that must run sequentially.
• Scope check: flag overlapping files and contracts before agents start.
• Resource namespace: give each task isolated ports, fixtures, databases, and queues.
• Permission tiers: keep production deploys, credentials, destructive migrations, and merges human-owned.
• Evidence contract: define what must be captured before implementation begins.
• Merge order: rebase and retest each branch against the latest approved base.
• Capacity limit: never start more work than people and systems can review.

A factory's throughput is accepted, stable changes per week. Agent sessions, pull requests opened, lines generated, or a review score can support that measure, but none of them replace it.

Build a Starter Factory in One Afternoon

1. Choose one repository. Use a project with tests, a working local setup, and no urgent production incident.
2. Write the factory contract. Add the four stages, exact check commands, forbidden actions, and escalation rules to AGENTS.md.
3. Create one task skill. Start with worktree creation, branch naming, scope inspection, and cleanup.
4. Define one evidence pattern. Use a visible UI defect or a small API behavior with a repeatable before state.
5. Add one independent review. Use existing CI plus a second reviewer or approved automated review tool.
6. Run two non-overlapping tasks. Measure intervention, correction, test failure, review time, and merge conflict rate.
7. Improve the instructions. Turn repeated corrections into narrow rules, examples, or tests.

Do not begin by copying every skill. Start with the failure your team actually experiences. If agents overwrite work, build isolation first. If they ship plausible but broken interfaces, build proof first. If implementations are unreadable, encode architecture and review rules.

A Factory Scorecard That Measures Accepted Work

Video Chapters

Verdict

Michael Shimeles's factory works as a useful minimum because it turns agent coding into a visible production line with named gates. Isolation reduces accidental interference. Architecture guidance protects maintainability. Evidence makes behavior inspectable. Review loops give the agent a reason to revisit weak work before a person spends attention on it.

The factory still needs human ownership. Worktrees cannot resolve product ambiguity. Screenshots cannot prove every requirement. A third-party score cannot authorize a merge. The durable advantage is the process encoded in the repository and improved after every failure, not the number of agents running at once.

Sources and Links

• Greg Isenberg and Michael Shimeles: Building a Software Factory that actually works
• Michael Shimeles's public software-factory skills
• Public AGENTS.md workflow template
• Official Git worktree documentation
• Vercel Labs before-and-after skill
• Greptile agent skills
• Greptile official site