An engineering organization can have coding assistants, agents and several successful demonstrations without having a repeatable way to turn an approved request into software that people can use. The missing work sits between the demonstrations: preparing context, coordinating dependencies, evaluating results and deciding when a change is ready.
The delivery perspective matters here. Working through flow maps, release dependencies and validation routes requires a practical distinction between work being executed, checks passing and a change reaching its users. That distinction is the basis for the operating loop in this article.
Here, an AI Software Factory means a maintained operating model that connects those activities. It includes people, agents, instructions, environments, controls and feedback. The definition is useful only when the organization can point to a working route and explain what it can reliably produce today.
Choose a product of the factory small enough to verify
Begin with a class of change that the organization actually needs. That might be a bounded maintenance change, a recurring integration update or an improvement to a well-understood component. Define the conditions under which the workflow is appropriate and the exceptions that require another route.
A broad request such as “build the next feature” hides several decisions: what the feature should do, how it affects existing contracts, which evidence establishes correctness and who accepts the remaining risk. A useful first workflow makes those decisions visible before attempting to automate them.
Write down the endpoint. An accepted pull request, a healthy deployment and a feature available to the intended users describe different outcomes. Choose the endpoint that answers the business question and preserve the intermediate states needed to diagnose delays.
Build a thin operating loop
A starting model can follow five connected stages. They describe responsibilities to establish, rather than a universal tool architecture:
- Prepare: establish the intended behavior, constraints, relevant context and acceptance evidence.
- Execute: give the selected people and agents appropriate tools, an understood environment and a bounded task.
- Evaluate: examine automated checks, human review, compatibility and unresolved uncertainty.
- Deliver: integrate and release through the applicable route, then verify the chosen endpoint.
- Learn: record what happened, which interventions were needed and what should change before repeating the workflow.
Each transition needs an owner and an observable condition. “The agent says it is done” is a report to examine. It should not silently become permission to merge, deploy or expose a change to customers.
Treat context and environments as maintained assets
An agent needs a way to understand the state of the work, reproduce the relevant environment and find the requirements it is meant to satisfy. Keep setup instructions, constraints and progress records close enough to the workflow that they are checked and maintained.
Anthropic’s engineering account of long-running agents describes one approach using environment setup, explicit feature requirements, progress records and verification between sessions. That is a documented implementation to learn from; it does not establish that the same architecture or autonomy level fits every organization.
Our proposed starting point is a small set of useful materials: an approved task brief, current instructions, an execution record and acceptance evidence. Add machinery when a recurring failure gives it a purpose. An orchestration layer cannot settle an unresolved product choice or maintain knowledge for which nobody is responsible.
Prove the handoffs with one real change
Consider an illustrative change that updates an API and requires a compatible data migration. The workflow must identify the consumer constraints, prepare the change, verify the expected behavior and follow the selected deployment route. If it cannot establish a safe migration or recovery approach, it should surface that decision before proceeding.
The coding stage may complete quickly while the change still waits for a shared environment or a decision from another team. Record that waiting separately from execution. The longest visible job is not automatically the system constraint, and a documented dependency does not prove that synchronized releases are required.
Follow the change through the chosen endpoint. A deployment controller accepting a request is different from the workload becoming healthy. A healthy workload may still require product-specific activation. Keep those distinctions in the record so that a local improvement is not mistaken for an improvement to the whole route.
Make supervision proportionate to the work
Define which actions can proceed automatically within the selected workflow, what evidence must accompany them and when a person must intervene. Access should match the task. Changes to a consequential boundary need a deliberate decision; they should not appear as an accidental side effect of making the workflow easier to run.
Name the people who can stop a run, resolve uncertainty and accept the result. Explain how to identify the changes produced by a run and how recovery will work where recovery is possible. Account for data changes as well as code changes.
These arrangements should reflect the application and the consequences of failure. A workflow for a reversible internal change does not establish readiness for changes with different customer impact or operating constraints.
Measure the cost of getting an accepted result
Track preparation, execution, evaluation, correction and waiting across comparable changes. Include failed and abandoned attempts. Review engineering effort, review effort and operating cost alongside quality and the time needed to reach the endpoint.
The relevant comparison is the work required to obtain an acceptable outcome. Code volume and tool usage can describe activity, but cannot establish that outcome. If the workflow shifts effort from implementation to repeated correction, that shift belongs in the assessment.
Make a decision after the first bounded operating loop: repeat it, adapt it, extend it or stop it. Extending to a different repository, team or release route introduces assumptions that deserve their own validation.
Build the next capability, then reassess
A practical GamePlan identifies the current limit, the next useful capability, its owner and the evidence needed before increasing the commitment. It should also make clear which parts are operational, which are experimental and which remain an ambition.
This gives a founder or technology leader a concrete investment decision. Axelerant’s role is to help diagnose the situation, shape the operating model and guide focused improvement. Implementation work and any software development need an agreed scope; the term “factory” does not imply an autonomous platform or an existing Axelerant software product.
Explore AI Enablement for Engineering. For the narrower rollout question, read Rolling out Claude Tag across engineering teams. If you are still diagnosing the gap between faster coding and delivery, start with More code, same delivery speed.
