Software factories with agents: the sensor decides the limit

Software delivery speed has always separated the best teams from the rest. For years, that difference was measured in deployments per week. Now, with code agents, the gap becomes exponential. The dividing line is no longer the tool or the talent, but whether the team has rebuilt its delivery system as a software factory: a semi-autonomous system where intent enters, agents plan, write, test and deploy, and people own the specifications and the review gates.

Anthropic put numbers to this gap: in May it was merging around 2,500 code changes per day, and by September it exceeded 30,000. Coding stopped being the bottleneck; now the bottleneck is the development infrastructure built for human scale. The question is no longer how to write faster, but how the factory knows that a change works before the next thousand arrive.

The key lies in the sensor: verification. If the controller (the agents) goes faster than the sensor, it does not accelerate; it retries with outdated information and deploys failures that the sensor would have detected. In a software factory, intent is the setpoint, agents are the controller and verification is the sensor. The possible autonomy depends on the quality of that sensor.

What makes up an agentic software factory

The most widespread definition, by Addy Osmani, describes a software factory as many interlocking loops running at once, fed by a work queue and drained through a review gate into production, with humans supervising from above. The elements are:

• Intent: specifications, tickets and scenarios that define what "done" means.
• Queue: the work backlog.
• Harness: constraints for each agent (tools, context, rules).
• Generation: the agents that write code.
• Verification: tests, scenario runs and runtime checks that report whether a change works before it is merged.
• Review gate: where a person or a policy allows the merge.
• Integration and deployment: the step to production.
• Production feedback: telemetry and incidents that return to the queue.

Agents change the lifecycle at two points: they add a generation step (changes arrive at the pace set by the agents) and they turn verification from a stage where you wait into a service that agents invoke within their own loop.

The sensor: latency, fidelity and bandwidth

A sensor has three properties that the factory needs:

1. Latency: time from when a change is ready until there is a verified result in a production-like environment. Every action between the change and its signal is based on a state that no longer exists; the agent retries on an unverified change and other agents build on top. You have to measure the time to signal.
2. Fidelity: how faithfully the reading reflects the real system. It matters more than latency, because the loop trusts a biased sensor. Unit tests and mocks report on a model of the dependencies, and agents optimize for what the sensor rewards. StrongDM saw that its agents returned "true" to pass narrow tests, so it moved its scenarios out of the code as a retention set. The metric is the escape rate: the percentage of failures found after the merge.
3. Bandwidth: how many readings the sensor can take at once. It is the property that agents stress first. A shared staging environment takes one reading at a time; with fifty agents, readings queue up or get mixed and failures stop being attributable to a change. The metric is concurrent verification capacity.

Autonomy follows the sensor. That is why it must be measured. In many teams, the level of AI coding stays at level 3 (the agent writes and you review diffs all day) because the sensor cannot give more. Moving to level 4 (the tests are the sensor) requires those tests to run against something that resembles the real system, not just mocks.

What it means for an SME

For an SME or a small IT team, setting up a complete software factory may seem far off, but the principle is applicable right now. It is not about hiring more agents, but about investing in the sensor: realistic integration tests, ephemeral environments and metrics for latency, fidelity and bandwidth. Without that, adding agents only accelerates the production of failures.

We recommend starting by measuring the time to signal in your current pipeline. If a change takes hours to have a reliable verification, the agents will not be able to go faster without sacrificing quality. It is also worth reviewing the escape rate: how many failures reach production? If it is high, the sensor is too optimistic. And watch out for bandwidth: if several agents share a staging environment, the results get mixed.

At ForgeNEX we have seen how the adoption of agents without adequate verification multiplies incidents. As in our analysis on measuring before expanding the GPU pool, the key is to measure the real result, not to add capacity without control. Just as OpenAI improves COBOL migration, tools evolve, but the basis remains the same: verify before deploying.

The agentic software factory is not an end, but a means to deliver more value with less risk. The sensor is the piece that allows agents to work with autonomy without the team losing control. Investing in it is the difference between a factory that produces and one that accumulates technical debt at exponential speed.

Source: The New Stack. Analysis and adaptation: ForgeNEX.