AI software factory tools in 2026: buy one, assemble one, or have one built

tldr: An AI software factory takes a ticket to a reviewed pull request with no human in the middle. There are four ways to get one: buy a platform, assemble it from parts, self-host the stack, or have one built and operated inside your environment. Ramp and Uber built theirs with platform teams. Here is what each route costs in engineering time.

What an AI software factory is made of

Every product in this category runs the same five-stage loop, so it is the most useful way to organise the tooling.

1. Intake. Work arrives as a ticket, spec, or logged bug rather than as a prompt typed into an editor.

2. Isolation. A sandbox spins up, clones the repositories, and is destroyed when the run ends.

3. Implementation. A coding agent does the work inside that sandbox.

4. Verification. The run executes the repository's own checks, and for user-facing changes drives a real browser.

5. The pull request. One PR per changed repository, with the diff and the evidence attached. A human reviews and merges.

We covered the category argument and who is claiming what in a separate piece on the AI software factory. This one is about the parts.

One disambiguation before the tools. If you arrived here from a government or defence context, "software factory" there still means the 2010s DevSecOps meaning: accredited platforms and teams like Kessel Run and Platform One, with golden pipelines and continuous authority to operate. Humans still write the software in those. Same name, different architecture, and the rest of this article is about the agent-era sense.

The teams who built their own

Two things are worth knowing before you evaluate anything, because they establish that this works and what it costs.

Ramp built an internal background coding agent called Inspect. Their engineering post states that ~30% of all pull requests merged to their frontend and backend repos are written by Inspect. The architecture is worth reading directly: each session runs in a sandboxed VM on Modal "with everything an engineer would have locally: Vite, Postgres, Temporal, the works," from repository images pre-built every 30 minutes, with filesystem snapshots to freeze and restore state.

Uber built Minion, an agent platform wired into their monorepo. Their published figures via The Pragmatic Engineer put 92% of Uber devs using agents monthly and 11% of pull requests opened by agents. The detailed Minion numbers sit behind that newsletter's paywall, so treat anything more specific you see quoted elsewhere with suspicion.

Neither company bought this. There was nothing to buy. Both assigned platform teams to build agent infrastructure: sandboxing, credential handling, and review workflow. It worked, which is the useful part. The software factory model is proven. What the two cases also establish is the price of the proof: a platform team.

Keep that in mind through the next three sections, because the tiers below are mostly a question of who does that work.

Tier 1: buy a platform

The turnkey option. Every claim in this table is the vendor's own, taken from their site, and none of it is independently measured.

There is also a lighter version of this tier hiding inside subscriptions you may already pay for. GitHub Copilot's coding agent has been generally available since September 2025: assign an issue to Copilot and it works in a cloud environment and returns a draft pull request, with a Linear integration added since. Jules, Google's asynchronous coding agent, reached general availability at I/O 2026 and runs the same shape, task in, cloud VM, plan, PR out. Cursor runs background agents in its cloud as well. None of these carries the verification or credential plumbing of the dedicated platforms, but if the question is whether the ticket-to-PR loop fits your team at all, the cheapest experiment is one you already own.

What you are buying from the dedicated platforms is the plumbing between the five stages. What you are not buying is the integration into your stack: your repositories, your CI, your ticketing conventions, your compliance posture. That work stays with you, and on a large codebase it is not small.

Tier 2: assemble it from parts

This is what Ramp and Uber did, and every layer of it is now purchasable separately. If you already pay for a coding agent and a CI provider, you are further along than you think.

Intake

Linear, Jira, GitHub Issues, or a Slack channel. There is no specialist tool here, and that is the point: the queue you already run is the queue the factory reads. The engineering work is in the trigger, deciding which labels or states hand a ticket to an agent.

Isolation

The agent sandbox is the layer teams underestimate, and the one Ramp singles out in their own writeup.

A note on sourcing. Most of the head-to-head comparisons of these providers that rank on search are published by Northflank, which is one of the providers in the table. Their posts are useful and also not neutral. The specific isolation technology each uses (microVMs, gVisor, containers) is claimed more precisely in those comparisons than in the providers' own documentation, so verify against primary docs before you make a security decision on it.

Implementation

The agent that writes the code. Claude Code, Codex, and Grok cover the commercial end, and if you want to see how the first two differ in practice, FactoryKit's learn library compares Claude Code and Codex from the vantage point of running both in production. On the open-source end sit Aider, Cline, OpenCode, OpenHands, and Goose, the Apache 2.0 agent Block built and has since moved to the Linux Foundation.

The useful design decision here is not which agent to pick but whether to pick one at all. Models leapfrog each other on a timescale of weeks, and a factory that hard-codes one agent inherits that model's bad quarter.

Verification

The stage that separates a factory from an agent left running overnight, and the one most assembled stacks skip.

Running the repository's existing checks is the floor: lint, types, unit tests, whatever CI already does. The gap is everything a reviewer actually worries about, which is whether a user-facing change still works. Playwright is the standard browser automation layer. Passmark is an open-source Playwright library for AI browser regression testing, with caching, auto-healing, and multi-model verification of assertions, which is the piece that makes browser QA survive a codebase that changes daily.

Green unit tests do not tell a reviewer whether the page a user sees still renders. Browser evidence does, and it is the part an assembled stack has to add deliberately.

Credentials

Infisical, Doppler, or HashiCorp Vault will hold secrets. The architectural question matters more than the tool: does the agent ever hold a credential at all, or does something outside the sandbox attach them to outbound requests?

An agent with repository write access and a model key is a service with unusual reach and unpredictable behaviour. The coding agent security primer in FactoryKit's learn library covers the threat model, and the short version is that scoping matters more than sandboxing.

Orchestration

Retries, long-running runs, and state that survives a process restart. Temporal is the common answer, and notably it appears inside Ramp's sandbox image as well.

What assembling actually costs

Every component above is available and most are good. The work is not in choosing them, it is in the joins: trigger logic, credential brokering, snapshot management, retry policy, and the review surface. That is a platform engineering project, it does not finish when the first run succeeds, and Ramp and Uber are the evidence for its scale rather than an argument against doing it.

Tier 3: self-host the whole stack

For teams whose code cannot go to a third party at all, whether for regulatory reasons or contractual ones.

For a self-hosted coding agent there are real open-source options: Aider, Cline, and OpenCode run against your own model keys, Goose runs entirely on your machine, and OpenHands ships an enterprise Kubernetes deployment. The isolation layer means running Firecracker, gVisor, or Kata Containers yourself rather than buying a sandbox service. Verification and orchestration are unchanged, since Playwright, Passmark, and Temporal are self-hostable already.

What you gain is that nothing leaves your network. What you pay is that you now operate a microVM fleet in addition to everything in tier 2. This is the most expensive route in engineering time and the only viable one for some buyers.

Tier 4: have one built by forward-deployed engineers

The fourth route is the one the category rarely names, and it is a different axis from the first three rather than a fourth product.

A forward-deployed engineer is an engineer who embeds with a customer to deploy and adapt a product inside the customer's own environment, rather than supporting it from the outside. Applied to this category, it means the vendor's engineers install the factory on your infrastructure, run it against your backlog, and hand it over.

In tiers 1, 2, and 3, the integration work belongs to the customer. A turnkey platform still has to be wired into your repositories and conventions. Assembling means building those joins. Self-hosting means building them and running the infrastructure underneath. At enterprise scale that integration is not the last mile, it is most of the project: which repos, which CI, which ticketing conventions, which compliance regime, where credentials are allowed to live. A platform ships the generic majority of a factory. The part that decides whether it gets used is specific to the buyer, and that is the part an embedded engineer builds.

The forward-deployed model moves both the integration and the operating burden to the vendor, inside the customer's environment, with custom builds part of the engagement rather than a roadmap item. This is what a software factory as a service properly means, and it is the difference between buying a factory and having one installed.

Three properties make the model work for enterprises in a way the other tiers cannot. The factory runs in your cloud or fully on premises, so the data objection that disqualifies tier 1 for regulated buyers does not arise. The backlog is being cleared while the factory is being built, which no tier 2 project can offer, since those spend their first quarter shipping nothing but infrastructure. And the engagement is designed to end: the vendor's engineers hand the controls to your team and stay on maintenance, so what you own at the end is a factory, not a dependency on the people who built it.

FactoryKit, which is built by the team behind this publication, runs exactly this model: its forward-deployed engineers drive the factory on the customer's backlog for the first one to three months while it is built on their infrastructure, then hand it over and stay on maintenance under subscription. The architecture underneath:

• Each task runs in an isolated cloud sandbox. No local development environment is involved.

• The coding agent is chosen per task: Claude Code, Codex, or Grok.

• The agent never holds a real credential. Credentials are brokered into outbound traffic in transit, scoped per repository.

• The agent never touches git. The platform commits, pushes, and opens one pull request per changed repository, so a multi-repo task returns coordinated PRs instead of one tangled diff.

• Every user-facing change is regression tested in a real browser with Passmark, and the session recording is attached to the pull request.

• Linear is connected today: label an issue, and the factory picks it up and answers on the ticket with a PR.

The recording is the part that is hard to picture from a bullet, so here is what actually lands on the pull request: the browser QA session for the change, attached to the PR a reviewer opens.

The limits. Standard web applications are the sweet spot and mobile is not supported. It is GitHub only, so GitLab teams are out for now. FactoryKit's own numbers put simple tasks at about five minutes, moderate ones at ten to fifteen, and complex ones at twenty to thirty. And a vague task produces a vague PR, which is the constraint every product in this category shares and few will print.

Which route are you actually on

Most teams evaluating tier 1 are actually choosing between tiers 1 and 4, and most teams evaluating tier 2 are underestimating it by a quarter.

What none of them can tell you

No vendor in this category publishes a first-attempt merge rate. Not Devin, not Factory, not 8090, not FactoryKit. There is no cross-vendor benchmark for ticket-to-merged-PR reliability, which means every claim on this page, including ours, is unmeasured against a shared standard.

So evaluate on evidence per run, not on claims. Three questions do most of the work:

1. What arrives attached to the pull request? Check results, a browser recording, a diff review, or just an assertion that it worked.

2. Where do credentials live during a run? If the answer is inside the sandbox with the agent, keep asking.

3. What does a failed run cost? Retries bill at full token price, so cost per finished task is the number to track, not cost per run.

FAQ

What is the difference between an AI software factory and a coding agent?

Where the human stands. A coding agent needs you in the session, steering, which is the whole experience of running Claude Code or Codex in your terminal. A factory wants you at exactly one point: reviewing the pull request. The agent is a component of the factory, not a substitute for it, which is why tier 2 above treats it as one layer of five.

Can I build one from tools I already pay for?

Yes, and that is what tier 2 is. If you already have a coding agent subscription, a CI provider, and a ticket tracker, you have three of the five stages. What you are missing is isolation, credential brokering, and the joins between them. Ramp and Uber both built exactly this, so it is a proven path with a known price.

What does an AI software factory cost to run?

Two meters. The platform, which depending on the tier is priced per seat, per usage, or as an engagement. And the model tokens underneath, which scale with parallelism and with retries, since a run that fails its checks and fixes itself pays for every attempt. A factory that needs three attempts per ticket costs triple its demo.

Is a DoD software factory the same thing?

No. Kessel Run, Platform One, and the other accredited Department of Defense software factories are DevSecOps platforms: golden pipelines, hardened containers, continuous authority to operate. They industrialise delivery and compliance, and humans still write the code. The two meanings share a name and an ancestor, not an architecture.

What is a forward-deployed engineer?

A forward-deployed engineer (FDE) is an engineer who embeds with a customer to deploy and adapt a product inside the customer's own environment, rather than supporting it from the outside. The model comes from Palantir and has spread through enterprise AI companies because integration, not software, is where their deployments succeed or fail. In this category, FDE-led means the factory is installed on your infrastructure, run on your real backlog, and handed to your team.

Do I need a sandbox, or is CI enough?

CI runs your checks against a diff that already exists. A factory needs somewhere for an agent to work before the diff exists: to install dependencies, run the app, break things, and try again. That is a different requirement, and running it on CI infrastructure means giving a non-deterministic process the credentials and network access your CI holds.