Summary: Firecrawl’s software-factory survey argues that intake, isolation, tools, verification, and merge gates must precede agent scale because generation can grow faster than review capacity. Published examples include Sentry scoring issue actionability, Stripe’s roughly 500 internal tools, Spotify rejecting about 25% of agent sessions, and Faire requiring two human reviews.
Nine pull requests went out from a phone at 35,000 feet on January 6, 2026, opened by Stephen Toub; seven of them merged. He works on dotnet/runtime, and the conclusion he recorded afterward, in Firecrawl’s writeup of the pattern, pulls no punches: good judgment plus a phone is now enough for one person to manufacture pull requests faster than a team can read them.
Which is the entire problem. Whether agents can write code is settled; what remains open is how a team absorbs what they produce. Firecrawl’s guide lands on an answer — a software factory — and adds that the agent is the cheap part of it.
Five Stages, Each With a Gate
An AI software factory, in Firecrawl’s description, is the machinery wrapped around a coding agent: a queue feeds work in, agents execute in isolated workspaces, checks run on their own, and a person stands at a merge gate that is deliberately explicit. Companies may name the pieces differently, but the published examples all settle on one skeleton — intake, isolation, tools, verification, merge.
| Stage | What it decides | Published example |
|---|---|---|
| Intake | Which work is worth starting | Sentry’s Seer scores issues for actionability before anything else |
| Isolation | Where the agent runs without colliding | Stripe boots pre-warmed devboxes in about 10 seconds |
| Tools | What the agent can reach | Stripe’s Toolshed exposes roughly 500 internal tools over MCP |
| Verification | Whether the change is right | Spotify’s LLM judge vetoes about 25% of agent sessions |
| Merge gate | Who is accountable | Faire requires two human reviews on agent-authored PRs |
Tooling matters less than order. Every gate exists to stop work that should not advance, and the costliest stages are stacked at the far end. Firecrawl states the asymmetry as the design constraint itself: generation grows with spend, review does not.
Where Intake Fails Open
Most of the waste is manufactured at intake. Assign an agent to every open issue and the queue wins; the published versions all filter before they dispatch. Firecrawl raises a second intake question that almost nobody asks: has this already been fixed upstream?
With Stripe reporting 1,300 merged agent PRs a week, burning agent sessions on problems that are already solved is exactly the waste a factory is meant to remove. Firecrawl’s developer index answers that question, and the part worth copying concerns failure modes rather than features. Scope a search to a repository and the response carries a repos block with an indexed flag; an indexed repo with zero matches and a repo that was never indexed both come back HTTP 200 with success: true.
A gate phrased as “if no results, spawn an agent” therefore treats “nobody reported this” and “we have no coverage here” identically, and passes both cases along. Take a false in repos[0].indexed as an unknown instead of a clean result, hand it to a person or a retry, and one line of code buys you a search box that behaves like a gate.
Isolation as a Cost Ladder
Two agents sharing a working directory is the quickest way to lose a day. Firecrawl orders three models by ascending cost: git worktrees, which separate files and branch but leave ports, databases, and deps shared; containers, which add deps and network isolation while still sharing host resources; and cloud sandboxes, which isolate everything including concurrency.
Start with worktrees, which stay adequate up to roughly the fourth concurrent agent. Worth more than any tooling pick is the structural note Firecrawl takes from Anthropic’s managed agents architecture: three parts, namely a stateless brain, disposable hands, and a durable append-only session log. Build the log even if you build nothing else, because the log is the one piece that lets everything else be thrown away.
The same instinct appears in what a hosted sandboxed shell changes for agentic tools: the shell is not the point — what counts is that a failed run leaves no damage behind and concurrent runs cannot trample each other.
Where the Evidence Points
Ten months of Microsoft data on dotnet/runtime, cited by Firecrawl, gives agent PRs of 1 to 50 changed lines a 76 to 80% success rate, while performance work lands at 54.5%. The published summary rates the coding agent as strong on well-specified changes, strong at investigating issues, and comparatively weak at architecting solutions.
Intake, not prompt engineering, is where that finding belongs. A size filter plus an explicit “agent-ready” label is not bureaucracy — it is how the fleet stays inside the band where it actually works.
One further signal: Spotify’s Fleetshift went live in 2023, a full two years before any agent existed to put inside it. The gating came first.
A Practical Starting Sequence
The sequence Firecrawl’s examples imply is unglamorous. Settle on a single intake rule and a single merge gate before scaling anything; write the session log; and teach the dedup check to separate “no coverage” from “no matches” — without that distinction you are not running a gate, only a machine that outruns your ability to absorb what it makes.
The honest limitation: essentially every item here is published architecture, and it comes from large engineering organizations that each run a dedicated platform team. The supplied material never addresses what the smallest workable version would be for a team of five people, and that is the one most readers would need.