The process model of an AI software factory in four zoom levels: from customer request to operations, and at which point humans set the pace.
With coding agents, writing code hardly takes any time anymore. This changes the software development lifecycle (= SDLC) more than it seems at first glance: when writing code hardly takes any time, everything else becomes the bottleneck. Requirements, decisions, reviews and acceptance still run at human pace. Whoever only speeds up the coding just moves the jam to the next point in the chain.
Since Andrej Karpathy popularised the term Agentic Engineering in February 20261, many people talk about agents that write code. Far fewer talk about what happens before and after: Where does the requirement come from? Who makes the architecture decision? And what happens to what operations learns about the software?
This article outlines the process model we use at Storm Reply to build software with agents, in four zoom levels: from the overall cycle through the engineering loop down to the individual systems a ticket passes through. For each level it names who does the work: a human, an agent or automation.
Zoom level 1: Three cycles instead of one pipeline
The term software factory is older than most developers working with agents today. In 1969 Hitachi became the first company to call a software organisation a “factory”, meaning the standardised, repeatable production of software with industrial methods2. A factory thinks in runs. Software, however, is never finished, which is why at the top level our model consists of three cycles that touch each other.
The customer cycle starts with idea and kickoff and runs through workshops and requirement engineering to business and operational requirements. At its end are review, acceptance and approval, followed by go-live and handover. Customer, product lead and project manager sit at the table here, and an agent already works alongside them, for example by structuring workshop results and asking back wherever a requirement still leaves room for interpretation.
The engineering cycle on the right turns the requirements into a shipped feature. It is what most people mean when they talk about an AI software factory. Zoom level 2 shows it in more detail.
The operations cycle on the left takes the new release into the production environment, including setup and configuration. Then come monitoring and operations, optimisation and reporting, and review and adaptation. Operations team, automation and agent work together here.
Two places where the cycles touch are decisive. The first is the grey zone in the middle that customer and development share: requirements go in, acceptances come out. The second is the dashed line at the top, the learning loop. What operations learns about the software comes back into the customer cycle as a new requirement.
Two examples show the range. In the simple case someone reports a menu icon in the wrong place. The customer cycle shrinks to one sentence, and the operations cycle does not notice the change at all. In the demanding case monitoring shows, for example, that a function responds too slowly under load. Via the learning loop this becomes a new requirement that runs through all three cycles: workshop, architecture decision, implementation, acceptance, rollout. The path is the same in both cases, only the scope differs.
What matters: an AI software factory is not a faster coding agent but a cycle in which every step has someone accountable for it.
Zoom level 2: The engineering cycle at two speeds
Zooming into the right-hand cycle shows that it consists of two nested loops that run at very different speeds.
The outer loop starts with the feature set for development, which customer and developer define together. Then come design and architecture decisions, agentic coding, test and evaluation of the whole feature set, deployment to the staging environment and finally review and acceptance in the zone shared with the customer. This loop is paced by humans. It runs as fast as people make decisions and accept results.
The inner loop, the agentic loop (= fast iteration of coding, deployment and test), runs between agentic coding, deployment to a development environment and test and evaluation of the single feature. Agent, developer and automation work here, and it turns in minutes. A bug that a test or a review agent finds here is fixed before a human even looks at the result.
The difference between the two loops is the core of the model. An agent may fail in the inner loop as often as it likes, because every failed attempt only affects the development environment and no customer. The outer loop, on the other hand, it never leaves alone. Henning Teek, who designed the architecture of our platform, puts it in one sentence:
“Human interaction with a software factory should be as little as possible, but as much as necessary to get good quality.”
Zoom level 3a: Design and architecture as a decision cascade
In Figure 2 the step “design and architecture decisions” looks like one box among many. Enlarge it and it becomes a cascade of four kinds of decisions.
The cascade starts with the business and operational requirement and runs through architecture decisions, technical decisions, security decisions and performance decisions. Only at its end is there something a coding agent can work with: technical requirements.
Why this phase stays paced by humans is in the graphic itself. These are four different kinds of decisions, and in a real project they often have four different owners: the architect, the development team, security and operations. An agent can prepare each of these decisions, compare options and find contradictions. Making them is the job of someone who answers for the consequences.
A simple example shows how concrete such a decision is. A business requirement reads: administrators should be able to connect a messenger. The security decision that goes with it reads: the messenger's access token is never returned to the browser. No coding agent introduces this rule on its own, because it is not in any business requirement. It has to come out of the cascade before the first line of code is written.
Zoom level 3b: Agentic coding, and the review comes before the code
The “agentic coding” step is not a single operation either, but a loop of its own.
From the technical requirement the agent first writes the specification and implementation plan. Then comes a step many teams skip: a review by the developer before a single line of code exists. Only then does the agent implement. Code review by developer and automation follows. If it finds something, the job goes back to implementation along the dashed line as a refinement. If it is satisfied, the change is deployed to the development environment.
The early review is the lever. An error in the specification costs five minutes of reading at review time. The same error in finished code costs a full implementation run, a code review and a refinement, and in the worst case nobody notices it because the code looks clean. That is why specification and plan belong in the repository as files of their own, where they are reviewed together with the code instead of disappearing as an attachment in a chat.
Zoom level 4: The technical run through five systems
At the lowest level the circular shape disappears. Here it shows which systems a single ticket actually passes through.
The five swimlanes (= lanes, one per system involved) are ticketing system, source code repository, coding agent, CI/CD system and development environment. The agent takes the technical requirement from the ticket and the current state from the repository. From these it develops the specification and the implementation plan together with the developer. Both go as Markdown files into a first pull request, where the developer reviews them. Only then does the agent write the code and open the second pull request.
From here the CI/CD pipeline takes over without humans: dependency analysis, dynamic and static code analysis, building the artefact, deployment to a new version of the development environment. There the developer tests and validates. If errors occur, the path leads back to the technical requirement in the ticket. If none occur, the ticket is closed automatically.
One detail of this graphic I consider more important than all others: the way back on errors leads into the ticket, not into a chat session. The ticket therefore remains the one place that says what is to be built and why the first attempt was not enough. If you fix errors in a chat, after three rounds you have working software and no record of why it looks the way it does.
Where the model does not hold
The four zoom levels are an ordering scheme, not a stopwatch. Above all, the boundaries between inner and outer loop are not clear-cut in practice. A small bug runs almost entirely through zoom level 4, and the decision cascade of zoom level 3a shrinks to nothing. For a new product, on the other hand, the cascade alone can take weeks before the first agent starts.
The roles shift as well. The icons in the graphics show who works on a step, not how much. In requirement engineering an agent can already take over a large part of the follow-up questions today, yet the decision about the requirement is still made by a human. Whoever introduces the model will negotiate for every step where the boundary lies, and that boundary will move with every model release. It also means that work shifts: away from writing code, towards specifying and reviewing. People who love programming lose something here, and that should be said openly.
For a throwaway prototype the whole model is too heavy. An agent on an isolated machine is enough there, and the outer loop can be skipped. For software that goes into production, that does not apply.
The recommendation is still clear: introduce it from the bottom up. First zoom level 4, meaning tickets that start agents in isolated environments and a pipeline that checks every pull request. Then zoom level 3b with the review of the specification before the code. Only when both of these hold is it worth bringing agents into the customer and operations cycles.
If you want to know what this path would look like in your organisation, just message me.
