AI software factory: from worktree to reviewed delivery

Why it matters

Running several coding agents creates a new constraint: someone still has to decide whether their changes are ready. If every pull request requires you to reconstruct the task, launch the application and investigate what the agent actually checked, faster code generation can leave you with a longer review queue.

In his conversation with Greg Isenberg, Ras Mic describes a software factory built around four stages: isolate, build, prove and ship. The useful mechanism is the requirement to produce evidence before moving forward. When verification or review exposes a problem, the agent returns to the implementation instead of handing you an unfinished result described as complete.

My test for this approach would be the amount of work required to accept a change confidently. Parallel execution matters when the resulting work remains easy to assess. The workflow below adds acceptance criteria, a limit on automated revision rounds and an integration check so that the demonstration can become a manageable development habit.

Key points

• 15:09 Completion needs observable evidence. Mic asks agents to capture the behavior before and after a change. This gives the reviewer something concrete to inspect. The evidence must match the claim: an interface recording can demonstrate an interaction, while a business rule also needs its outputs checked.
• 05:22 Each task gets a separate working directory. Git worktrees keep agents from editing the same checkout during execution. That separation makes concurrent work easier to manage, while integration still requires attention when the branches come back together.
• 12:24 Working code needs a maintainable structure. Mic supplies architectural guidance intended to make generated code understandable to a developer who joins later. The transferable practice is to state the project's conventions clearly and review whether the implementation follows them.
• 22:11 External review drives another implementation pass. Greptile examines the pull request and the agent addresses its findings before requesting another review. Mic also names CodeRabbit and Macroscope as alternatives. This introduces a second assessment beyond the agent that produced the change.
• 25:26 The reported concurrency relies on the review process. Mic says he has worked on 15 features at once, stepping in to merge after his review threshold is met. That is an account of his workflow; the useful concurrency limit for another project depends on how much finished work its reviewer can absorb.
• 29:13 The process lives in written instructions. Mic's implementation uses Markdown files to describe the workflow. Those instructions make the method easier to carry between tools, provided the execution environment can perform the required checks and capture the results.

How to apply

Give your AI software factory one small order

Start with a change you can evaluate in a few minutes. Consider a report whose CSV export ignores the selected date range. Write the acceptance criteria before assigning the task: exported rows must match the dates, amounts must remain correct, and the file must contain only records available to the current user.

For a product serving Brazilian customers, include accented names and realistic currency values in the fixtures. Specify the delimiter and decimal format expected by the receiving system. These are suggested implementation details, extending the video's method into a task with a clear finish line.

This also gives the agent a bounded scope. Improving the whole reporting system is difficult to review; correcting one export behavior provides a result you can compare against known inputs.

Create a separate checkout for the task

For a repository that already has an origin/main branch, the following example creates a task branch and its working directory:

git fetch origin
git worktree add -b fix/export-date-range ../app-export origin/main
git worktree list

Run the agent inside ../app-export. Worktrees provide multiple working directories attached to one repository. The official Git worktree documentation covers the command and its options.

When running two application instances, assign separate ports and inspect shared resources. Two agents using the same test database can interfere with each other's results despite having separate files. I would complete the first task through review before adding a second concurrent assignment.

Write the route from assignment to review

Use the instruction file your tool recognizes. If it supports AGENTS.md, put the workflow and the project's actual commands there. Replace “test thoroughly” with specific instructions for launching the application, running the relevant checks and attaching their output.

A starting sequence can require the agent to:

1. Reproduce the issue using known test data.
2. Implement the change using existing project conventions.
3. Run checks appropriate to the affected behavior.
4. Capture results and identify anything left unverified.
5. Open the pull request and address review findings.

Ras Mic's official repository contains his skills and a workflow template. Read it as a reference for instructions that fit your application. Architectural guidance earns its place when it makes the resulting code easier to understand and change.

Match each claim to a useful artifact

A recording of someone clicking Export demonstrates only part of the CSV task. The reviewer also needs to assess the file that was produced.

| Acceptance criterion | Useful evidence | | --- | --- | | Apply the selected dates | Known input records compared with exported rows | | Preserve monetary values | Checked totals and formatting examples | | Enforce access boundaries | Results from users with different permissions | | Keep the interaction usable | A recording of filtering and downloading |

Ask the pull request to identify the tested commit, commands and results. If the environment cannot verify a requirement, keep it visible as an unresolved item. A reviewer can then perform a targeted manual check instead of investigating the entire feature again.

For a performance task, establish the workload and measurement conditions before implementation. Compare repeated measurements under equivalent conditions. A single favorable response time gives you much less information than a reproducible comparison.

Put a budget around the revision loop

The official Greploop skill coordinates repeated review and correction until its requirements are met. I would initially allow three automated revision rounds. At that point, an unresolved task should return to a person with the remaining issue and a record of the attempts.

That limit is an operating choice for a first implementation. It keeps an ambiguous requirement or persistent disagreement from consuming an unlimited number of runs.

Treat the review score as one input to your decision. A 5/5 score does not independently demonstrate that every product requirement has been satisfied. Read the findings alongside the acceptance criteria and test evidence.

Before merging, verify the change against the current target branch. Separate worktrees do not remove the possibility of merge conflicts; the Git merge documentation describes how Git handles them. Also check behavior after integration: changes can merge cleanly as text while interacting incorrectly at runtime.

Scale according to the cost of acceptance

For the first five deliveries, record agent and review costs, human review time, and corrections needed after merging. Divide the total cost by accepted changes, including spending on abandoned attempts.

Increase concurrency when those figures show that additional work remains manageable. If finished pull requests accumulate, improve the task definitions or evidence requirements before assigning another feature. The practical payoff is a delivery that takes less investigation to approve.