How Software Factories Work

Software factories organize AI agents into repeatable development workflows that turn work items into changes ready for review. The workflow defines how agents investigate a request, implement a change, check the result, and hand decisions back to people. eve provides a framework for coordinating those agents and preserving their progress.

Writing code is one part of delivering a change. Someone also has to establish whether a reported problem exists, decide what should change, run checks, and review the result. As work accumulates, managing those steps can become a bottleneck even when agents handle implementation.

Software factories automate the handoffs between these activities. Each stage produces a result the next stage can use, so a reviewer receives the original request, the proposed change, and evidence from checks together. The AI SDK team's software factory applies this approach to work such as bug fixes, documentation updates, and backports.

Software factories fit work with a repeatable process and an outcome your team can evaluate. Examples include:

• Investigating bug reports with reproducible failures and regression tests.
• Implementing well-defined changes that follow established repository conventions.
• Preparing maintenance changes, such as backports, for review.

The useful starting point is a workflow your team already understands. Clear acceptance criteria, reliable checks, and people who can review the output give the factory a basis for deciding whether work should advance.

Exploratory work still needs close human direction. If a request leaves product behavior or a public API undecided, the factory needs a clarification or approval step. Automating implementation before resolving those questions can produce changes that pass tests but solve the wrong problem.

The stages depend on the repository and the work it receives. The following sequence illustrates how a factory can carry evidence from a request to a reviewable change:

For example, an issue might claim that an API accepts invalid input. Investigation can reproduce the failure before implementation starts. If the API already rejects that input, the workflow can return its findings without changing code. Asking for clarification or stopping an unsupported request are useful outcomes alongside producing a pull request.

The team defines which actions a factory may take and which require a person. Those rules can permit an agent to prepare a branch while reserving changes to public behavior or release decisions for human approval.

Independent review gives the reviewer a separate opportunity to inspect the code and its evidence. The review stage needs the actual diff and acceptance criteria, rather than relying on the implementation agent's account of its work. People still judge whether the requested behavior belongs in the product and whether the evidence supports shipping it.

Running a factory also means maintaining its checks and agent instructions. Recurring failures can reveal missing context, unreliable checks, or work that needs a different approval rule.

eve's agent project structure separates an orchestrator from the agents that perform specific tasks. The orchestrator coordinates work, while subagents run with their own instructions, tools, and conversation state.

Several eve capabilities support the workflow:

Foreman, the eve software factory template, is one implementation of this pattern. It routes GitHub and Linear work through classifier, analyst, implementer, and reviewer agents. Its workflow ends with a reviewed draft pull request; a person decides when to mark it ready and merge it.

These resources put the concepts into practice: