What a software factory is

Giving a coding agent a ticket does not tell it which tests matter, whether it may publish the change, or what to do when a requirement is missing. Someone still has to connect those steps. A software factory makes that process part of the system rather than leaving a developer to move every result from one tool to the next.

The agent writes code; the factory connects the work#

A software change starts with a request. The team works out what should happen, changes the code, runs tests, reviews the result and releases it. Issue trackers, source control and build systems already support much of this work. DORA’s continuous-delivery guidance explains why testing, integration and release practices matter beyond writing the code.

AI agents can take on some of these tasks. An agent might read the relevant code, investigate a bug, implement an agreed fix or review a proposed change. The factory determines how that work starts, what information and tools the agent receives, and what must happen before the next step begins.

Here, software factory means this connected way of producing software, not a particular AI product. A coding tool is one part of it. The factory also has to handle work that is waiting for a test, a decision or another attempt.

The complete process includes release and feedback, but an initial automated workflow can stop earlier. For example, it can return a tested pull request—a proposed code change—for a person to accept. The existing release process then takes over. Calling it a factory does not grant the agents permission to merge or deploy.

Decide what to build, then check whether it helped#

There are two different reasons to send work back. The implementation may be wrong, or the team may not yet know what the software should do. This guide uses two connected loops to show that difference. They are a teaching model, not a required architecture.

Show the full-size diagram, and pan Back to the phone layout

Consider a simplified upload example. A file exactly at the stated size limit is rejected. If the agreed rule says the limit is inclusive, a test can expose the bug and the agent can correct the comparison. If nobody has decided whether the limit counts the file alone or the whole request, the agent needs an answer before it can write the right test.

Feedback after release can start another task. A user might report that the new export works but is too slow for a large report. The team investigates and decides what to change. A report is a reason to investigate, not permission for an agent to choose and release its own fix.

Failures can also reveal a problem in the factory itself. Perhaps the agent repeatedly misses boundary cases because the test instructions omit them. A maintainer can add a suitable check and compare the results on known examples. Saving logs helps with that investigation; saving logs alone does not improve the next run.

What the factory needs to keep track of#

For each task, the factory needs the request, the relevant project rules and the starting code version. These tell the agent what to change and what must keep working. Repository access alone is not enough: the agent still has to find the useful files and decisions. Preparing the information an agent sees explains that part.

The agent then needs a place to work and tools it is allowed to use. It might be able to edit files and run tests in a temporary workspace without being able to change production. The software that gives it those tools and restrictions is often called a harness.

The factory saves the changed code and the actual test results. It records which code version was tested, whether review is complete and what is waiting. After an interruption, it should be possible to continue from the saved work instead of starting again or accidentally opening a second pull request.

It also needs rules for failures. A failed test may allow another coding attempt. A missing requirement needs a question. A cancelled task must stop making new changes. The guide to retries and stopping explains how to distinguish those cases.

None of this requires a separate service for every responsibility. Reuse the issue tracker, test pipeline and release tools you already have. Add custom software only for the parts they do not handle.

Follow a change from request to handover#

In a supervised workflow, planning first checks the request against the code and recorded decisions. It produces a short plan: the intended behaviour, the code likely to change and the tests that should show the change works. A genuinely unanswered question goes to a person instead of becoming an assumption.

With permission to continue, development makes the change and runs the required checks. Review then examines that version against the request and the test results. If review finds a defect, development can correct it and rerun the affected checks. The workflow limits the time, spending and number of attempts rather than retrying forever.

The interactive walkthrough shows this kind of handover between steps. It is an illustrative design, not a recording of a running factory.

Show the full-size diagram, and pan Back to the phone layout

BackNext stepWalk the runRestart1 of 14

Creating a pull request is not the same as finishing the work. Some automated checks only run after the pull request exists. The factory must wait for those results before presenting the change as ready for acceptance. If the code changes again, earlier results may no longer cover it.

At handover, the reviewer should receive the proposed change, the checks that actually ran and any remaining manual work. A person accepting the pull request is a separate step from merging it, deploying it and checking the deployed version. Keep those states separate rather than calling all of them “done”.

Decide which steps need a person#

A factory does not have to automate every step for every task. A team can ask for a plan only, request an independent review, or allow a task to continue through implementation and review. These are useful choices, not levels every team must climb.

A spelling correction and a database migration that deletes records may both have tiny code changes. Their consequences are not alike. Decide who must approve each action by what it can affect and how a mistake can be corrected, not by the size of the diff.

Keep planning proportionate too. A local fix may need a few sentences. A change to a shared interface needs more discussion. Asking someone to review a plan that duplicates every line of the eventual code can create extra work rather than prevent it. Where factory automation stops explains these limits and the maintenance work that tests alone cannot judge.

When separate agents help#

An agent that checks whether a ticket is ready does not need permission to merge code. An agent that edits code does not need access to production. Separating those jobs can make their permissions and instructions easier to manage.

Separation also creates a handover. The next agent needs the actual requirement, the current code and the relevant results—not just the previous agent’s claim that everything worked. Two agents can make the same mistake, particularly if they inherit the same wrong assumption. Naming one “reviewer” does not solve that problem.

Anthropic’s agent-design guidance recommends starting with the simplest approach that works. Add another agent when the separate task, information or permissions justify it. Several agents are not a requirement for calling the overall process a factory.

Start with one kind of task#

Choose a small change with a result you can check. For example, replace one deprecated API call while keeping the documented behaviour. Record how the existing code behaves, provide a non-production workspace and decide which checks must pass. Run the task through to a reviewable proposal with the changed code and test reports.

Then deliberately try a missing requirement, a test that already failed before the change and an unavailable dependency. Does the factory ask the right question? Can it explain which check did not run? Can a developer recover the saved work without becoming an administrator?

Test restarting an interrupted task too. It should not overwrite a developer’s newer work or publish a duplicate pull request. These cases tell you more about unattended use than repeatedly showing the same successful demo.

Broader task coverage, more simultaneous workers and permission to release are separate decisions. A workflow that handles one of them well has not yet demonstrated the others.

Measure the time spent on the whole task#

A fast coding step is useful only if it helps the whole task. Include the time people spend preparing requirements, answering questions, reviewing code and correcting mistakes. Count failed and abandoned runs as well as successful ones.

Define the result before comparing numbers. “A branch was created”, “tests passed”, “a reviewer accepted it” and “users received the change” are different outcomes. Report which one you measured.

Compare similar work with and without the factory. A demo built from scratch with invented data cannot establish the expected saving in an existing application with compatibility requirements. Keep track of cost and defects as well as elapsed time. The measurement guide shows how to make that comparison.

Questions people also ask

3 QUESTIONS

▸ Is a software factory a replacement for CI/CD?

No. CI/CD is the automated work that builds, tests and prepares or releases code. A factory can use those tools and also connect the work before and after them, such as investigating a ticket, writing a change, asking for a decision and handing the result to a reviewer.

▸ Do I need several agents or a new orchestrator?

No. Start with an existing workflow and one agent when that is enough. Separate agents can help when tasks need different information or permissions. Add software to manage waiting and restarts when the tools you already use cannot handle those cases.

▸ Can one factory use different levels of autonomy?

Yes. You might allow a spelling correction to proceed automatically while requiring a person to approve a database migration. Set the rules for each kind of task, including the required checks and who handles a failure. One successful task is not permission to automate every other task.