AI software factories:
four approaches

four approaches, different responsibilities

This comparison uses each organisation's published account, reviewed on 23 October 2026. It compares responsibilities; there is no common benchmark here for cost, reliability or speed.

These rows describe different things: internal systems, a commercial platform and an implementation guide. Treating them as contestants in one performance league table would obscure the decisions they actually help explain.

what the published systems tell us

StrongDM makes validation the central challenge. Its 6 February account describes agents working from specifications and scenarios, with no human code review. It discusses tests that can be satisfied without achieving the intended result, and scenarios evaluated against simulated services. The buyer's question is whether the validation represents real behaviour, including failures. Removing manual review does not remove the need to decide what counts as acceptable.

Stripe separates unattended execution from acceptance. Its 9 February Minions article describes isolated development environments, existing developer tools and automated checks, followed by human review. This is a reminder to ask what surrounds the agent. A workflow supported by a mature organisation's tooling is not something a smaller team can reproduce merely by choosing the same model.

Factory broadens the unit of automation. The company's 15 June announcement places planning, implementation, review, security, release and monitoring in one connected lifecycle. It describes gradual, context-dependent autonomy. For a buyer, the useful distinction is between a product's possible capabilities and the capabilities actually configured, verified and owned in their engagement.

Vercel makes the handoffs inspectable. Its 14 September guide emphasises defined tasks, retained evidence, acceptance and explicit handling of unfinished work. This gives a practical test for any proposal: if the original operator is unavailable, can someone else tell what happened, what passed and what still needs a decision?

Our reading of these accounts is that the surrounding delivery process is becoming a larger part of the discussion. For a buyer, implementation, checking, acceptance and operation are distinct responsibilities to establish in a proposal.

four questions before trying it on your workflow

Use these four questions to find the next uncertainty worth testing in your workflow.

1. is the job bounded?

Name one user, one task and an observable result. “Improve operations” is too broad to accept. “Prepare a weekly list of orders whose shipping status disagrees between two systems” is testable. Decide what is excluded, which system is authoritative and what happens when records are incomplete. If the business rule is disputed, resolve that before increasing automation.

2. can the result be checked separately?

Agree examples and expected outcomes before evaluating the implementation. Include duplicate records, missing permissions, unavailable services and a case that should be rejected. Preserve the test inputs and the version checked. A demonstration with data selected after the software was built may show possibility; it does not establish that the agreed task works. Ask which important behaviours remain untested.

3. is authority explicit?

Separate reading information, proposing a change, writing data and releasing software. A system that drafts a reconciliation report need not have permission to change the source accounts. Name who can approve additional access and who can stop a run. A decision to automate a step should identify its limits and recovery path, not silently inherit the permissions of whoever first tried the tool.

4. is there an owner after acceptance?

Ask what happens when an integration changes, usage grows or a result is wrong next month. Someone needs to receive alerts, distinguish software defects from changed requirements, and restore service. Establish where the code, configuration and operating instructions live. A successful initial run answers whether the task worked once; continuing responsibility is a separate question.

a small pilot with an inspectable result

Consider that order-status report. In this illustrative pilot, a useful record might contain:

• Boundary: read two exports and prepare a report; make no changes to either source system.
• Checks: match known discrepancies, surface duplicates and stop with a clear explanation if an input is missing.
• Acceptance: an operations owner compares the output with the agreed examples and records remaining gaps.
• Recovery: retain the manual process until the team can detect a failed run and recreate the report.

This record remains useful whether the implementation uses one developer, several agents or a conventional integration product. It also reveals when bespoke software would be unnecessary.

measure the workflow, including correction

Compare the same kind of task before and after a pilot. Count the work needed to prepare inputs, review results, fix mistakes and keep the system running. Record unresolved failures alongside successful runs. Code volume, token spend and the number of parallel agents do not tell a buyer whether their problem has improved.

For continuing software delivery, DORA's measurement guidance considers throughput alongside instability and stresses application context. Apply that balance to the same workflow over time, including the effort required to correct mistakes.

Bring these questions into a proposal review with our software factory buyer checklist. For the wider meaning of the term and Software Facto's actual offer, start with software factory as a service.