ninja nerdingSteve Sewell's software factory
Steve Sewell's software factory
Most agent workflows start when you type something. This one starts on a timer. Every few hours an agent reads the feedback, errors and issues for Steve Sewell's product, fixes the ones it can reproduce and prove, opens pull requests, answers the reviews and ships. Anything it isn't sure about goes to a person.
Jump to the factory map, the skills, or how to start small.
The video
Just under 18 minutes, posted Sept 23, 2026 on Steve's channel. No sponsor. Every timestamp on this page opens it at that moment.
Nine signals
The whole video in nine boxes. Each links to the part of this page that explains it.
- 012:42
It starts on a timer, not a prompt
Every several hours a scheduled job reads the feedback, errors and issues and picks its own work. Nobody types anything.
How - 024:04
Only fixes it can prove
An agent gets a job only if it can reproduce the problem, fix it, and show the problem is gone. If it can't do all three, no PR.
How - 034:19
Unclear means a person
Every decision point has a written policy. If the policy doesn't clearly say yes, the item waits in one list for a human.
How - 043:01
One rules file sets the limits
A YAML file lists the sources, the timers and ten separate switches like fix, reply and merge. Yes to one is never yes to another.
How - 054:45
Every PR gets a babysitter
The agent that opened a PR answers every review comment and failed check. A second job sweeps the queue and applies your merge rules.
How - 069:57
Overseers catch what slips
A watchdog nudges work that just stopped. A weekly lookback finds the bugs that keep coming back and goes after the shared cause.
How - 076:18
A second laptop, always on
Not the cloud. A spare machine with his real keys and logins, so the agent can check its fixes. It messages him when it's stuck.
How - 088:35
Cheap model for volume, strong model for judgment
A cheaper model does the bulk of the work. A stronger model from another lab watches the hard threads and checks them.
How - 0914:29
He ran it by hand first
For months. His first step for you: a dry run of collect that changes nothing, then argue with it until its list is right.
How
Software that fixes itself, within limits
Feedback and telemetry come in. Better software comes out. People stay able to step in at any point. 0:35
The loop
Collect what users and monitors are telling you. Fix what can be fixed. Open a PR. Review it. Ship it. The shipped code produces new feedback, and the loop goes round again.
The filter
Only one kind of work goes to agents: verifiably fixable. The agent can reproduce the problem, make a fix, and show the problem is gone. If it can't do all three, it doesn't get to open a PR. 4:04
The exit
Every decision point has a written policy. When the policy doesn't clearly say yes, the item is set aside for a human. That one rule is what keeps the loop from wrecking the code. 4:19
DozensPRs merged a day
His number for agent-made pull requests on his open source project. Nobody has audited it.
$200a month
The ChatGPT Pro plan he runs the factory on. He says he doesn't hit its limits.
2laptops
One he works on. One beside it that runs the loops day and night and messages him when it's stuck.
9factory skills
Plus one YAML file of rules. All in his public repo, all marked experimental.
What it's pointed at: agent-native, Builder's open source framework, and the apps built on it (design, slides, mail, calendar, analytics). He says most of his own time now goes to tuning the factory, not writing the code. His phrase for the job: a scientist watching an organism. 12:22
Words on this page
Thirteen terms, in plain words. Skip this if you already run coding agents on a real repo.
- Codex and Claude Code
- The coding agents he runs the factory in. Each has its own scheduled tasks, and those timers are what start every factory job.
- Skill
- A file of plain-language instructions, called SKILL.md, that your agent loads when asked. You run one by typing its name after a slash, like /factory-collect.
- Pull request (PR)
- A proposed change to the code, opened so it can be reviewed and checked before it joins the main version. Comments and checks happen on the PR.
- Worktree
- A separate working copy of the same Git repo. Each job gets a fresh one, so two agents never trip over each other's changes.
- CI
- Short for continuous integration: the automatic checks, like tests, that run on every PR. Green means they passed.
- Merge and main
- Main is the shared, official version of the code. Merging a PR folds its change into main. His beta site always matches main.
- Sentry
- An error-tracking service. It records errors from the live product, and here it's one of the sources the factory reads.
- Telemetry
- Numbers the running product reports about itself, like uptime, slow responses and errors. The factory reads it alongside user feedback.
- YAML
- A plain-text format for settings. The factory's rules file is written in it, so you, or the agent, can edit the rules directly.
- Source map
- A file that links the code running in the product back to the lines you wrote, so an error points at one line in your source.
- Monorepo
- One repository holding all of a project's code. His tip: a factory pointed at one repo has one place to look, one set of checks and one main branch.
- Regression test
- A test that checks an old bug hasn't come back. The lookback adds one at the spot where it fixes a shared cause.
- Tokens
- The units AI models count and charge in. Browser checks use a lot of them, which is why he runs the volume on a cheaper model.
The factory map
Four lanes. A timer starts the jobs. Six stations do the work. People catch what the rules don't cover. Three overseers watch for work that stalled or keeps coming back. Click any box, or pick a ticket and follow it through.
On a timer starts each job below
The lineagents do the work, 01 to 06
People anything a policy doesn't clearly allow
Overseers watch the line and push work back onto it
◇ = a rule decides · darker box = a person decides · red = the box you're reading
Follow one ticket
The straight run: an error comes in and a fix ships with nobody typing. 9 steps. Press Start and watch which box lights up.
Station 2 of 6
Watch at 2:36Collect
Reads each source to the last page and sorts every item: real bug, repeat, feature request, opinion, duplicate, not ours, not enough to go on. It checks whether the same thing was reported before. If one detail is missing it can ask one question, then look for the answer on a later run.
◇ The gate
Fix policy: can an agent reproduce this, fix it, and prove the fix?
Yes: A clear defect in code this repo owns goes to Fix and verify.
No: Unclear, risky or a product call. It's set aside for a person.
When it runs
Every several hours. On his screen the task is called “Review latest feedback and ship”.
Where the work goes next
Passes the gate: fix it. Doesn't: a person.
What runs when
Collect feedback and ship/factory-collect
Every several hours
He says it. On screen: a custom schedule, next run in 5 hours.
Babysit a PR/factory-babysit-pr
Every 2 minutes, one task per open PR
On screen: six babysit-pr tasks.
Watchdog/factory-watchdog
About four times a day
He says it. On screen: “Ship thread watchdog”, every 5 minutes.
Production deploy
Once a day
He says it. His deploy pipeline, not a skill.
These are his timings on his machine. Yours go in the rules file, and you check them in your agent's scheduled tasks. 2:42
The skills
All in BuilderIO/skills. Nine are named factory-something and run the loop. Two more are helpers he uses beside it. Each is a SKILL.md your agent loads when asked. Most of them you never type: a timer runs them.
- /factorySet upThe setup interview. It writes the YAML rules file, shows which sources your agent can really read, and creates the scheduled jobs.
- /factory-collectThe lineReads every source you listed, sorts each item, and fixes the ones your policy allows.
- /factory-shipThe lineCarries a finished change from worktree to merged: checks, PR, feedback, merge gates, close-out.
- /factory-babysit-prThe lineFollows one pull request until it's merged, closed or stuck. Deals with every review comment and every failed check.
- /factory-review-prsThe lineSweeps the whole queue of open PRs and decides, by your rules, which can merge and which wait for a person.
- /factory-human-digestPeopleOne read-only list of everything that's waiting on a person.
- /factory-watchdogOverseersFinds work that was allowed, started, and then just stopped. Speaks up only when there's a real next step.
- /factory-recoverOverseersRestarts runs that were cut off by a crash, a restart or a sleeping laptop, if it's still safe to.
- /factory-lookbackOverseersReads weeks of signals at once to find the problems that keep coming back, then goes after the shared cause.
- /agent-watchdogHelpersA second agent, on a different model, that watches one thread, does its own investigation, and compares.
- /efficient-frontierHelpersA reminder to the expensive model: keep the judgment, hand the heavy reading and testing to cheap helpers.
/factory
Set up · Before anything runs
The setup interview. It writes the YAML rules file, shows which sources your agent can really read, and creates the scheduled jobs.
When to use it
- ·First, once per project.
- ·Again whenever you add a source, change a rule or change a timer.
How you run it
Type /factory in the project and answer its questions.
What it does, in order
- 1Reads .agent-factory/config.yaml if it exists and keeps what you already chose.
- 2Lists the tools in this agent that can read things: Slack, GitHub, Sentry, whatever you've connected. It can't connect new ones.
- 3Asks you to set each permission on its own: fix, reply, close, review, approve, publish, merge, deploy, recover, notify.
- 4Takes optional extra instructions per skill, in plain language.
- 5Picks timers, time zone and how worktrees are made.
- 6Writes the file. No keys or tokens go in it.
- 7If you ask, creates one scheduled job per workflow, then reads each back to confirm what was saved.
Its limits: Grants nothing by itself. Anything you leave unset means hold.
Watch out: A schedule written in YAML is a request, not a job. Open your agent's scheduled tasks and check it's there.
/factory-collect
The line · Station 02, and the fix in 03
Reads every source you listed, sorts each item, and fixes the ones your policy allows.
When to use it
- ·On a timer, every several hours. This is the job that feeds the line.
- ·By hand as your very first run, as a dry run that changes nothing.
How you run it
/factory-collect, or let the timer run it. For a first try add: dry run, change nothing.
What it does, in order
- 1Matches each source in the config to the tool and exact channel, repo or project.
- 2Reads the whole time range, every page. Records counts. Keeps “empty”, “couldn't read” and “cut short” apart.
- 3Sorts each item: verified defect, repeated symptom, feature request, opinion, duplicate, out of scope, needs more evidence. Groups related reports.
- 4Fixes only when the fix policy allows it and the repo is in scope. Proves the change with your checks and a real reproduction.
- 5If one missing detail blocks it and replies are allowed, asks one targeted question. Later runs look for the answer and sort the report again.
- 6Reports coverage per source, and for each item: links, type, evidence, what it did, and what a person still has to decide.
Its limits: Fixing, replying and closing each have their own rule. Collect never opens, approves or merges a PR on its own say.
Watch out: A failed read isn't an empty inbox. If Sentry was unreachable, the report must say so.
/factory-ship
The line · Stations 03 and 06
Carries a finished change from worktree to merged: checks, PR, feedback, merge gates, close-out.
When to use it
- ·After a fix is verified and your policy lets the agent publish it.
- ·His main timer pairs it with collect: “Review latest feedback and ship”.
How you run it
/factory-ship on a finished change, or “ship this” inside a factory thread.
What it does, in order
- 1Confirms what it owns: the repo, its own worktree, the branch, and exactly which changes belong to this task.
- 2Runs the formatter, tests and release checks. Says which ones it skipped.
- 3Opens or updates the PR, if publishing is on, with your title, body and label rules.
- 4Works through review comments in one tidy update, then reruns the checks that matter.
- 5Merges only under the merge rule, and only if nothing changed on the PR since the checks passed.
- 6Confirms the merge is on main. Checks the deploy only if you configured that. Closes issues when their proof point is reached.
Its limits: Editing code doesn't allow a PR. A PR doesn't allow a merge. A merge doesn't allow a deploy.
Watch out: Merged isn't live. The skill treats “it's deployed and working” as a separate thing to prove.
/factory-babysit-pr
The line · Station 04
Follows one pull request until it's merged, closed or stuck. Deals with every review comment and every failed check.
When to use it
- ·The moment an agent opens a PR. One babysitter per PR.
- ·On his machine each is a saved task that runs every 2 minutes.
How you run it
/factory-babysit-pr with the PR link. In the video the agent that opens the PR starts this itself.
What it does, in order
- 1Confirms it's the right PR, that someone really asked for this work, and which files and risks are in bounds.
- 2Reads the PR's full live state: commits, checks, reviews, open threads, whether it can merge. Anything it can't read counts as unknown, not clean.
- 3Takes each new comment and compares it with the actual diff. Fixes what's real and in scope. Skips redesigns and tidy-ups nobody asked for.
- 4Reruns checks after every fix, then reads the PR again. A new commit throws out old check results.
- 5Applies each permission separately: fix, push, reply, approve, merge, and an optional wait with no changes before merging.
- 6Stops when the PR is merged, closed, or blocked on a person. Reports what it did and what it's waiting for.
Its limits: A PR number, a label or a green check is not permission. Each action needs its own rule.
Watch out: It comments as you. From Codex or Claude Code, replies go out under your GitHub account. He adds a line saying a bot wrote it.
/factory-review-prs
The line · Station 05
Sweeps the whole queue of open PRs and decides, by your rules, which can merge and which wait for a person.
When to use it
- ·On a timer, every few hours.
- ·By hand once a day while you're still learning to trust it.
How you run it
/factory-review-prs, or leave it on the timer.
What it does, in order
- 1Reads live state. Skips drafts, PRs outside your filters, and PRs it already reviewed.
- 2Inspects the diff, linked issues, checks, comment threads, the author and the exact latest commit. Treats bot findings as leads, not verdicts.
- 3Reports real problems with file, line, impact and a concrete fix. If there are none, it says so and doesn't invent one.
- 4Applies review, reply, approve and merge as four separate decisions.
- 5Re-reads the PR right before any approval or merge. If the commit changed, it starts over.
Its limits: Approve and merge are both off until you write the conditions for each.
Watch out: One green check or a bot's thumbs-up isn't a pass. The skill says so in as many words.
/factory-human-digest
People · The human lane
One read-only list of everything that's waiting on a person.
When to use it
- ·Weekly in the example config.
- ·Whenever you sit down to clear your queue.
- ·Narrow it in plain words: “PRs only, last 30 days, detailed.”
How you run it
/factory-human-digest, optionally with a filter.
What it does, in order
- 1Sets the scope. Default: every configured source, the last 7 days, medium detail.
- 2Reads every source and repo for that window, all pages.
- 3Pulls out what needs you: PRs awaiting review or a merge call, reports held for detail or risk, answers nobody re-sorted yet, work that stalled.
- 4Groups items by the underlying problem, not by similar words. Keeps every link. Counts reports and affected people separately.
- 5Reports what it covered first, then the themes, then the decision list.
Its limits: It takes no action at all. No reply, approval, merge, close or ping.
Watch out: To act on a decision, run the skill that owns that action. The digest won't do it for you.
He doesn't name this one in the video. He says the human items are batched by a separate automation, and it isn't in the skill list on his screen. It's in the repo as of Sept 30.
/factory-watchdog
Overseers · Watching the line
Finds work that was allowed, started, and then just stopped. Speaks up only when there's a real next step.
When to use it
- ·About four times a day, on a timer.
- ·As soon as you're running enough threads that you can't remember which ones finished.
How you run it
Leave it on the timer. It needs no input.
What it does, in order
- 1Finds candidate threads and reads enough of each to confirm what was asked and whether it was later cancelled.
- 2Skips anything active, deliberately waiting, done, cancelled or unclear.
- 3For stopped work, finds its PR, branch or worktree and checks live: still open, same commit.
- 4Sends a reminder only if your notify rule allows it and a concrete next step is due.
- 5Never repeats an unchanged reminder. If nothing meaningful changed, it reports that and stays silent.
Its limits: It nudges. It doesn't take over. Merge and cleanup stay with the thread that owns the work.
Watch out: A task title or a green check doesn't prove the work was authorized. It has to read the original request.
/factory-recover
Overseers · Watching the line
Restarts runs that were cut off by a crash, a restart or a sleeping laptop, if it's still safe to.
When to use it
- ·After your agent app restarts or the machine sleeps mid-job.
- ·On a timer only if your agent can reliably tell which runs were interrupted.
How you run it
/factory-recover after a restart.
What it does, in order
- 1Finds interrupted runs and reads the original request plus later messages, not only the title.
- 2Skips runs that are active, cancelled, paused on purpose, blocked on a person, finished or unclear.
- 3Confirms the worktree still belongs to that run. Never resets, cleans or stashes someone else's work.
- 4Rechecks the outside world before retrying. Doesn't repeat a reply, merge or deploy that already happened.
- 5If the original permission no longer covers the next step, leaves it stopped and says what decision is needed.
Its limits: Off by default. It can't revive cancelled work or grant itself anything new.
Watch out: Don't schedule it until you've watched it pick the right runs by hand.
Not named in the video. It sits beside the watchdog on his diagram.
/factory-lookback
Overseers · Watching the weeks
Reads weeks of signals at once to find the problems that keep coming back, then goes after the shared cause.
When to use it
- ·Once a week for him. Run it by hand first.
- ·When you suspect the factory keeps “fixing” the same thing.
How you run it
/factory-lookback, with a window if you want one.
What it does, in order
- 1Confirms the sources, the window and what to compare it with: say, the last 30 days against the 30 before.
- 2Reads the full range: feedback, telemetry, errors, repeat CI failures, and earlier fixes marked shipped.
- 3Groups records by what's actually failing and where, not by wording.
- 4Traces each group back to earlier fixes. Did the symptom return after a fix was claimed?
- 5Reproduces a current case and finds where the failing paths meet. One fix there beats a pile of patches.
- 6If the rule allows a fix: the smallest change at the cause, a regression test, then a second look at the same signals afterward.
Its limits: A pattern is a reason to investigate, not permission to change code. The example config sets fixes to manual.
Watch out: A merge or a “fixed” label doesn't prove the reports stopped. Look at the signal again later.
He hands this job to a bigger model such as Opus or Fable, which sends cheaper helpers to do the reading.
/agent-watchdog
Helpers · Beside one hard thread
A second agent, on a different model, that watches one thread, does its own investigation, and compares.
When to use it
- ·Work you already know is hard or deep.
- ·Any time you'd want a second opinion before trusting an agent's “done”.
How you run it
In the thread list: right-click, copy deep link. Then in another agent: /agent-watchdog and paste the link.
What it does, in order
- 1Picks a mode from how you ask: watch only, audit, audit and fix, or compare two agents.
- 2Opens whatever you gave it: a thread link, a session ID, a PR, a branch.
- 3Rebuilds the assignment: the original request, the limits, what “done” should mean, and what the agent claims.
- 4Investigates the same problem itself, before leaning on the other agent's conclusions.
- 5Checks the claims against the diff, tests, CI and screenshots.
- 6Reports gaps and next directions. Makes narrow fixes only if you said it could.
Its limits: If you didn't say it may fix things, it only audits.
Watch out: He calls this “factory watchdog” out loud. What he types is /agent-watchdog. They're different skills.
/efficient-frontier
Helpers · Inside any expensive model
A reminder to the expensive model: keep the judgment, hand the heavy reading and testing to cheap helpers.
When to use it
- ·When a big model runs a lookback or a watchdog and the work splits into independent pieces.
- ·Skip it for small jobs, or when one blocker has to be looked at directly.
How you run it
/efficient-frontier at the top of a big job.
What it does, in order
- 1Names what only the big model should decide: priorities, risk, the final review.
- 2Names what can be handed off: scans, log reading, browser checks, narrow edits.
- 3Starts parallel helpers, each with a self-contained brief: goal, scope, how to verify, when to stop.
- 4Asks for short returns: findings, files changed, commands run, what's still risky.
- 5Reviews everything centrally and reopens the important files itself before calling it done.
Its limits: None. It changes how the work is split, not what's allowed.
Watch out: No two helpers on the same files at once. And it doesn't always save money, only when work can run in parallel.
efficient-fable in the same repo is the same idea written for Fable.
The rules file
One YAML file at .agent-factory/config.yaml. Every factory skill reads it before doing anything. It lists your sources, your timers and what the agent is allowed to do. 3:01
A small example, in our words
# .agent-factory/config.yaml
version: 1
timezone: America/Chicago
repositories:
- id: app
provider: github
remote: you/your-app
worktree:
mode: fresh-per-run
base: origin/main
sources:
- id: errors
provider: sentry
scope: your-org/your-app
- id: issues
provider: github
scope: you/your-app
workflows:
collect:
enabled: true
schedule: every 4 hours
sources: [errors, issues]
implement:
mode: criteria
allow: [verified defects in owned code]
stop: [security-sensitive changes, unclear product intent]
reply:
mode: never
close:
mode: never
lookback:
enabled: true
schedule: weekly
window: last 30 days
compare_with: previous 30 days
sources: [errors, issues]
implement:
mode: manual
human-digest:
enabled: true
schedule: weekly
window: last 7 days
skill_prompts:
factory-collect: |
In any reply, say you are a bot. Ask for the URL and the time.Reading it
- repositoriesWhich repos the factory may touch. fresh-per-run asks for a clean worktree for every job.
- sourcesWhere signals come from. Each needs a tool your agent already has. Writing “sentry” here doesn't connect Sentry.
- workflowsOne block per job: on or off, how often, which sources, and its rules.
- implementThe fix policy. “allow” lists what the agent may fix. “stop” lists what always goes to a person.
- reply · closeSeparate switches. Here the agent may fix bugs but may not post replies or close issues.
- skill_promptsExtra plain-language instructions for one skill. They add guidance. They can't grant a permission.
Ten separate switches
Each of these is its own decision. Saying yes to one never says yes to another. Allowed to fix a bug doesn't mean allowed to reply to the reporter, or to merge.
- fix
- reply
- close
- review
- approve
- publish
- merge
- deploy
- recover
- notify
Four settings for each
- neverDon't do this. Ever.
- manualWait for a person to do it or say yes.
- criteriaDo it only if every “allow” condition holds and no “stop” condition does.
- after-fix / after-mergeWait for that proof point, then do it.
Two things the file can't do. It can't connect a tool your agent doesn't already have. And it isn't checked by any program: the skills read it the way a person reads a policy. Missing, unclear or unreadable always means hold for a person. The full list of fields is in the configuration reference.
Where it runs
A spare laptop, a cheap model for the volume, an expensive model for the judgment.
- 01On a laptop, not in the cloud
He went back and forth and landed here. To verify a fix the agent needs his real setup: env files, keys, logged-in browser sessions, sometimes a Mac app. When it gets stuck he can look at a screen and type a one-time code.
- 02A second laptop, always on
It sits beside him and runs the loops day and night. When it's blocked it sends him a Telegram message. His main laptop stays fast because the browsers and builds run on the other one. A Mac mini would do. It needs plenty of memory.
- 03Driven from the first one
In Codex he uses remote projects, so threads he starts on his main laptop run on the second. In Claude Code he connects over SSH, which only works for him on the same network.
- 04A cheap model for volume
The factory runs on GPT-6 Luna at max settings in Codex. He says it's a fraction of the price of Opus and good enough once the skills force it to verify. Browser checks burn tokens, so price matters at this scale.
- 05An expensive model for judgment
Opus or Fable watches the hard threads and runs the lookback. A different model from a different lab checking the cheap one's work is the point.
Start small
He ran all of this by hand for months before he automated any of it. His advice is to do the same. You need a repo, one coding agent, and at least one source it can read, like GitHub issues. 14:29
- 01
Install the skills
Run the installer in your project and pick the Factory group. It installs instructions only. No integrations, no keys, no timers.
npx @agent-native/skills@latest add
- 02
Run collect by hand, as a dry run
Type /factory-collect and tell it to change nothing. Read what it thinks it should fix. This is his step zero.
- 03
Argue with it until the list is right
The config is a YAML file, so the agent can edit its own rules. Tell it what it got wrong and have it update the prompts and policy. Repeat until you'd have picked the same items.
- 04
Let it fix a few, in worktrees
Clear errors only, high confidence only, your normal human review on every PR. Have it open the PRs and babysit them. Watch how it answers feedback, and check that a person's comment beats a bot's.
- 05
Put it on a timer when you feel like a robot
He ran collect every morning and review every afternoon by hand. When he noticed he was only clicking buttons, he scheduled them. Your main laptop is fine for this.
- 06
Months later: a dedicated machine
Only once the volume is real. Then add the watchdog, and run lookbacks by hand before you schedule those too.
FakeNerd starter · your first dry run
/factory-collect Dry run. Read .agent-factory/config.yaml and every source in it. For each item you find, give me: the link, what kind of item it is, the evidence, and whether the fix policy would allow a fix. Then three lists: what you would fix, what you would ask the reporter, and what you would leave for me. Change nothing. No edits, no replies, no PRs. If you can't read a source, say so. Don't call it empty.
His four tips
- One monorepo
A factory pointed at one repo has one place to look, one set of checks and one main branch.
- Good inputs first
The factory is only as good as what it reads. Telemetry, a real feedback channel, errors tied to source lines with source maps. Slow end-to-end tests and agents that test beta on a schedule can file issues too.
- Beta and production, apart
Beta follows main and his own team uses it. Production is cut once a day. Agents merge all day, so a daily cut is what makes a rollback simple.
- Start small
One source, clear error messages, high confidence only, humans still reviewing. Shift the balance later.
Next to the other factories
FakeNerd has two more pages with this name: Ras Mic's and Zach Lloyd's. All three say software factory. They start in different places.
What starts work
Steve Sewell: A timer. Jobs read feedback and errors and pick their own work.
Ras Mic: You. One prompt per feature, one tab each.
Zach Lloyd: Triggers. A labeled issue, a schedule, a monitor alert.
Where it runs
Steve Sewell: A second laptop that's always on, with his real keys and logins.
Ras Mic: Your machine, in whatever agent you already use.
Zach Lloyd: The cloud. Agents in sandboxes.
What you install
Steve Sewell: Nine factory skills, one YAML rules file, and the scheduler your agent already has.
Ras Mic: Seven skill folders and one AGENTS.md.
Zach Lloyd: A factory definition, agents, triggers, and the infrastructure under them.
Who checks it
Steve Sewell: The agent's own reproduction, a review bot, a second review agent. A bigger model on the hard ones.
Ras Mic: The agent's own proof, then Greptile, then you.
Zach Lloyd: A review agent and a verify station, then a person.
Where people step in
Steve Sewell: Wherever a rule doesn't clearly say yes. Small verified fixes can merge with nobody looking.
Ras Mic: Twice: you ask, you merge.
Zach Lloyd: Three gates inside a loop that feeds itself.
Good for
Steve Sewell: A live product with real users and telemetry, and a long tail of small fixes.
Ras Mic: One builder shipping many features on one repo.
Zach Lloyd: A team that wants issues to become PRs with nobody starting each one.
Ras Mic's line builds the features you ask for. Steve's loop finds its own work, but only the kind it can prove. They fit together: one for new things, one for the long tail of fixes. Zach's is the version where the whole thing lives in the cloud.
FakeNerd's take
The rules file is the product
Each skill is a page of instructions. What's new is that fix, reply, approve, merge and deploy are ten separate switches, and anything unclear means stop. That's what makes leaving it alone overnight thinkable.
“Verifiable” does the heavy lifting
The factory only takes what an agent can reproduce, fix and re-check. Most of a backlog isn't that. A feature request isn't. A taste call isn't. Expect it to clear the small stuff and hand you the rest.
The repo is more careful than the video
On camera: dozens of merged PRs a day. In the files: everything is marked experimental, and replies, approvals, merges and deploys are off until you write the conditions. Start where the files start.
No signals, no factory
If you have no error tracking, no feedback channel and no tests, collect has nothing to read and nothing to verify against. Build those first. He says the same.
It acts as you
Comments and PRs go out under your account. The second laptop holds your keys and your logged-in browser. That's an unattended agent with your access. Decide what that machine can reach before you walk away from it.
His numbers are his
Dozens of PRs a day, a $200 plan, a cheap model as good as an expensive one: those are his claims about his setup. He's also the CEO of Builder.io, showing Builder's own open source project. The skills are free and MIT licensed.
Attribution
- Build an agentic software factory: deep dive, Steve (Builder.io), Sept 23, 2026. The loop, the timings, the two-laptop setup, the models and the tips are from this video, in our words. Task names, schedules and model names marked “on screen” are read from the video frames.
- BuilderIO/skills, MIT licensed, read Oct 1, 2026 (4,509 stars). What each skill does comes from its SKILL.md, the factory guide and the configuration reference, summarized in our words. The factory skills are marked experimental and may change.
- agent-native (agent-native.com) is the Builder.io project his factory works on.
- The four-lane map, the four tickets, the example rules file, the starter prompt, the comparison and the takes are FakeNerd's. Not sponsored by anyone on this page.