What is an AI software factory?

The term covers different levels of automation

A team may use a factory to prepare pull requests for engineers. Another may delegate much more of the acceptance process. Both need a precise account of what the agents are authorized to do. Calling a product a software factory tells you little about who owns its final decisions.

StrongDM describes a deliberately ambitious version: agents work from specifications and scenarios without human code review. Vercel describes a broader development system with defined work, checks, and review. These are different operating choices within the same emerging category. See StrongDM's account and Vercel's definition.

Before comparing vendors, finish this sentence for your own team: our factory can take a task as far as ____, after which ____ decides what happens. A draft PR and a production release require different permissions, evidence, and recovery procedures.

Start with a recurring piece of work

Consider an illustrative maintenance queue: dependency updates that need a small API adjustment. Today, an engineer checks the release notes, reproduces a failing build, explains the repository setup to an agent, and reviews its patch. A factory can retain the setup and delivery procedure so the engineer does less of that coordination on the next update.

The request should identify the dependency and the intended version. The environment should install from the repository's lockfile. The task should name the affected behavior and which checks establish compatibility. If the update requires a product decision, such as removing an API your customers use, the agent needs an owner to ask.

An unsuccessful attempt can still be useful. A reproducible incompatibility report with the offending call site may save the maintainer time. Preserve that result as an investigation instead of encouraging the agent to force every task into a completed PR.

Which responsibilities belong in the factory?

A coding agent makes and checks changes using the tools available to it. CI runs the checks configured by the repository. The factory coordinates the work around those capabilities. Use these questions to find the gaps in your current process.

You can implement a small factory with scripts and existing services. The need for a platform grows when several people share repositories, agents, tools, and an expanding queue. A central work record then helps people answer questions without finding whoever wrote the original prompt.

Evaluate a platform with one of your own tasks

Choose a recent task whose expected result you already understand. Give each candidate the same starting revision and brief. Keep the first attempt small enough that a maintainer can inspect every changed file. Record the setup time as well as the time spent correcting the agent and reviewing its result.

Interrupt one run and inspect recovery. Does the platform show the branch that already exists? Can you tell whether a new instruction was received and whether the agent acted on it? Ask another teammate to find the result without a private explanation from the person who started the task.

Compare the cost of an accepted change, including failed attempts and reviewer effort. A fast first draft can become expensive if it takes several rounds to establish what was tested. Our coding agent cost guide explains how to keep those measurements separate.

Where the approach earns its overhead

Repeated bug fixes, bounded features, and routine maintenance are useful starting points when you can reproduce the behavior and name the checks. Work with unresolved product requirements needs investigation before implementation. An inaccessible test system also limits how much evidence an agent can return, regardless of the platform.

Keep the queue smaller than the team's review capacity. Ten open proposals are unfinished work until someone accepts them. If review is already the constraint, improve task scope and the quality of evidence before increasing agent concurrency.

How Uno fits a team's development process

Uno provides a shared workspace for repositories, sessions, rules, skills, and integrations. A session keeps an objective and its work together so teammates can follow progress and inspect outputs. Repository rules describe conventions; skills describe repeatable procedures. The workspace guide explains that shared context.

Start with a task you would be comfortable assigning to a contributor. Define the result, supply the reproduction, and state the checks. Review the proposed change through your team's normal release process. The first trial should show how much coordination Uno removes and which decisions your engineers still need to make.