Firecrawl Publishes Blueprint for an AI Software Factory Where Agents Open, Review and Merge Their Own PRs

Firecrawl has published a description of how it runs an internal system it calls an AI software factory, in which coding agents write changes, inspect each other's work and merge pull requests with minimal human involvement. The company, best known for converting websites into structured data for AI systems, laid out the setup on its blog. The write-up is less a product announcement than a public account of how one engineering team has arranged its tooling.

The design rests on splitting the work rather than trusting a single assistant to both write and approve code. Different agents handle different stages of the pull request lifecycle, each with its own prompt, context window and permissions. One agent drafts a change, another checks it against the repository's conventions, and a later stage handles integration. Firecrawl's contribution is wiring those steps into one continuous loop instead of leaving them as disconnected tools.

That staged approach has become common among teams running agentic coding software. Engineering organizations increasingly separate generation, verification and merging so that no single model signs off on its own output. The reasoning is practical: a model that reviews its sibling's code has an obvious incentive to approve it, and the review step is where most automated pipelines are weakest. Merge rights matter even more, because that is the moment an automated change reaches production.

The harder problem in this kind of pipeline is trust, not code generation. Teams that hand merge authority to software typically lean on tests, lint rules, branch protections and limits on how large a diff can be, reserving human sign-off for changes that touch sensitive paths. Firecrawl's post is useful mainly for showing which guardrails a working team actually depends on, rather than describing the concept in the abstract. Absent from the write-up so far are the numbers that would make the case: how many pull requests the agents merge, how often a human overrides them, and what fails when they do.

Firecrawl's internal tooling carries some weight because the company ships developer infrastructure itself, so its choices are a worked example rather than a thought experiment. The blog post arrived alongside a discussion thread where readers began picking at the details, though early response was modest. Engineering leads weighing similar setups will want the operational data before ceding merge rights, and that evidence is the piece still missing.