An AI software factory is a repeatable development system in which agents perform defined work and pass their results through checks and review. It connects incoming requests to evidence that a team can use to accept a change. People decide what work matters and how much authority the system receives.
Vercel's software factory guides describe one implementation of this approach. The broader idea is useful whenever you want an agent's work to follow a process that another person can inspect and operate.
Copy link to headingWhat changes when you move beyond individual coding sessions?
In an individual session, you often carry the missing context. You choose the issue, explain the repository, notice a failed command, and decide what the agent should do next. That can be an effective way to work. When you want to make the process repeatable, start by choosing a suitable first task.
A factory requires you to make those handoffs explicit. An incoming task needs enough information to begin. A failed check needs a defined response. A reviewer needs to know which revision the agent tested and whether the requested behavior changed.
The distinction concerns the surrounding process. Running several agents at once tells you how much work is in progress. It doesn't tell you how the work gets accepted or what happens when an agent cannot finish.
Consider a recurring documentation correction. You could ask an agent to fix each report yourself. A factory workflow would also define which reports qualify, which documentation checks must pass, and where the resulting proposal goes for review. The correction remains small. The process becomes reusable.
Copy link to headingHow do coding agents, CI/CD, and a factory fit together?
You can keep the coding agent and delivery pipeline you already use. The design question is how work passes between them without relying on a person to reconstruct the task at every handoff.
For the documentation example, a useful division of responsibilities would look like this:
These are responsibilities, not a requirement to buy separate tools. A script may be enough to coordinate an initial workflow. As the system grows, the important test is whether someone can inspect a task and understand why it moved forward or stopped.
Be specific about the end of the automated path. If an agent opens a branch and CI checks it, the next step still needs an owner. A factory design should identify that owner and provide the information needed to act.
Copy link to headingWhat does the system need to keep track of?
Use this checklist when designing a factory. These responsibilities can live in separate services or in a smaller application; the table is a design aid, not a required architecture.
Give unfinished work an explicit state. An agent that cannot reproduce a report should be able to return an investigation with a named gap. Otherwise, pressure to reach a completed state can obscure the difference between a checked result and a plausible guess.
Copy link to headingHow might a bug report move through a factory?
Imagine a report that an export omits rows when a filter is active. This is a hypothetical workflow, not a description of a particular product.
The first step checks whether the report names the filter and includes data that demonstrates the problem. If it doesn't, the task waits for clarification. An investigation then runs the reported behavior against a recorded revision and saves the result.
Once the expected behavior is clear, an implementation step proposes a patch. Verification repeats the failing case and checks nearby behavior, such as an export with no filter. A reviewer receives the patch with the observations needed to assess it.
The reviewer can accept the change, request another attempt, or reject the approach. Those decisions should remain visible in the work record. If the report described intended behavior, a useful outcome may instead be an explanation for the reporter.
This example doesn't require an agent for each sentence in the process. Separate work where the distinction helps you inspect results or control access.
Copy link to headingWhat does a working example look like?
The AI SDK team's August 2026 account describes starting with issue classification and adding specialized agents. Early agents ran through a local CLI before the system moved to managed infrastructure. GitHub webhooks feed queued work; agents execute in sandboxes, and maintainers review results through a monitoring UI. Humans retain merge authority.
For your own design, draw the path a task takes after the initial prompt. Mark where it waits and where a person needs to intervene. That exercise helps distinguish a useful automated task from the additional coordination needed to operate it repeatedly.
That internal system is a separate example from Foreman, the public software factory built on eve. The Foreman guide is the implementation starting point for readers who want to build with the template.
Copy link to headingWhat should happen when a run stops halfway through?
Design recovery alongside the successful path. Suppose the agent pushes a documentation fix, but its process stops before it records the branch. Starting the entire task again could create another proposal for the same report.
Give the task a stable identifier and record completed actions as they happen. On a retry, check for existing output before creating more. Preserve the revision associated with a test result so a resumed run doesn't attach an old pass to a newer patch.
Also distinguish a retryable failure from a request for judgment. A temporary service error may justify another attempt within the run budget. Conflicting requirements need an owner to resolve them. Retrying the same ambiguous instruction consumes resources without answering the missing question.
These are proposed operating practices. Choose the implementation that fits your workload, and make the recovery state visible to the people responsible for the queue.
Copy link to headingWhere does the factory's responsibility end?
A factory needs an explicit endpoint for each workflow. A draft pull request, an accepted patch, and a successful production rollout are different outcomes. If your workflow stops at a proposal, describe it that way.
Keep existing delivery controls visible. A passing build can provide useful evidence, but it doesn't determine whether the requested behavior is desirable. Deployment can succeed while a customer still encounters the original problem.
Full autonomy is a design choice, with consequences for verification and authority. It isn't a prerequisite for using the factory approach. Start by deciding which decisions require a person and which actions the system can perform under an established policy.
Copy link to headingFrequently asked questions
Copy link to headingIs a software factory the same as a coding agent?
A coding agent performs development tasks using the tools and context it receives. A software factory also defines how tasks arrive, how results get checked, and how completed work reaches an acceptance decision.
Copy link to headingDoes a software factory replace CI?
No. Keep CI checks as part of the evidence used to assess a proposed change. The factory also needs to interpret failures and route work that requires another attempt or human attention.
Copy link to headingDoes a software factory have to merge code automatically?
Automatic merging is optional. You can design a workflow that ends with a reviewable proposal and reserves acceptance for a maintainer.
Copy link to headingMust every development stage be automated?
You can introduce automation for a bounded part of development and expand from there. Define the handoff to the next person or system before adding more stages.