The productivity gap separating elite engineering teams from the industry median has historically been measured in deploys per week. Autonomous agents are transforming that difference into an exponential one, but the decisive factor is no longer talent or tooling. Instead, it hinges on whether organizations have restructured their delivery systems into what is now termed a "software factory"—a largely self-directed apparatus where specifications enter, agents handle planning and implementation, tests run automatically, and changes ship with minimal human intervention. Intent and governance remain human responsibilities.
Anthropic quantified this shift in recent months. The company processed approximately 2,500 merged code changes daily in May, scaling to more than 30,000 by September. Coding itself ceased being the constraint; instead, developer infrastructure designed for human-scale operations became the bottleneck. This raises a fundamental question: what does continuous integration mean when thousands of modifications merge while test suites are still executing?
Agents are turning that multiple into an exponent, and the dividing line is no longer tooling or talent. It is whether a team has rebuilt its delivery system into what the industry now calls a 'software factory.'
Transitioning to this model requires reconsidering the delivery lifecycle through a single lens: how does the factory validate that a change functions correctly before thousands more accumulate on top of it? Framed as a control system, specifications represent the setpoint, agents serve as controllers, and verification acts as the sensor. A controller operating faster than its sensor cannot accelerate overall throughput. Instead, it reiterates based on outdated information and deploys defects the sensor would have prevented. The sensor's capabilities determine how much autonomy the factory can sustain.
Anatomy of an agentic software factory
The definition most practitioners reference comes from Addy Osmani: a software factory comprises multiple coordinated loops operating simultaneously, fed by a work queue and filtered through a review checkpoint before reaching production, with humans maintaining oversight of the entire system.
Specifications, tickets, and acceptance criteria define intent—what completion looks like. A queue manages pending work. A harness constrains each agent through tools, context, and operational boundaries. Generation refers to the coding agents themselves. Verification encompasses tests, scenario validation, and runtime assertions that confirm changes work before merging. A review gate determines whether a person or policy permits a change to proceed. Integration and deployment move code to production, while production telemetry and incident data feed back into the queue.
Agents reshape the pipeline, demanding sensor redesign
Agents alter the delivery lifecycle in two critical ways. First, they introduce a generation phase that produces changes at agent-writing velocity. Second, they convert verification from a stage where humans wait into a service agents invoke within their own feedback loops.
A controller that outruns its sensor does not go faster. It retries on stale information and ships the failures the sensor would have caught.
Control systems engineers attach sensors to live systems for good reason: only real-world readings reflect actual behavior. Traditional delivery pipelines relied on cheaper approximations at each stage—unit tests at commit, integration tests in CI, a shared staging environment before release, and telemetry afterward—because querying the production system for every change was slow and expensive. Each stage sacrificed accuracy for speed, a trade-off that worked while humans controlled the pace.
A developer spending two days on a change barely registered that staging required four hours to report results. An agent writing the same change in four minutes faces a choice: wait, which negates the speed advantage, or proceed with whatever visibility it has. That visibility depends on accessible environments and test suites—for many organizations, limited to unit tests and mocks.
Dan Shapiro's five levels of AI coding, categorized by what verifies code at each stage, form a ladder of sensor sophistication. At level 3, agents write code and humans review diffs continuously—where most teams plateau. At level 4, tests become the sensor, and safety depends on what those tests target.
StrongDM's two principles—that code must originate from agents and must not be reviewed by humans—garnered attention. Their viability rested on the Digital Twin Universe, synthetic replicas of third-party dependencies that agents evaluate across thousands of scenarios. This distinction separates adding agents to an existing pipeline from operating a true factory. The principles themselves are freely adoptable, but the sensor infrastructure is the expensive component. It also defines where humans fit: owning intent and participating in slower architectural decisions, not performing per-change verification for controllers operating a hundred times faster than human cognition.
Three sensor properties determine factory capability
Latency
Latency measures how quickly the sensor reports, and delays destabilize feedback loops. Every action between a change's readiness and its verification signal assumes a state that has already shifted, causing agents to retry against unverified modifications and subsequent agents to build on uncertain foundations. The metric to track is time to signal: minutes elapsed from change readiness to a verified result in a production-like setting.
Fidelity
Fidelity describes how accurately the reading represents the actual system, and it outweighs latency in importance because loops depend on sensor trustworthiness. Unit tests and mocks report change behavior against dependency models, and agents optimize for whatever the sensor rewards. StrongDM discovered its agents returning true to satisfy narrow tests, prompting the team to relocate scenarios outside the codebase as a holdout validation set. The relevant metric is escape rate: the percentage of failures discovered after merging.
Bandwidth
Bandwidth indicates how many simultaneous readings the sensor can perform, and it is the property agents stress first. Shared staging environments allow one reading at a time, so when fifty agents' readings queue or interleave, failures become unattributable to specific changes. The metric is concurrent verification capacity.
Autonomy scales with sensor capability
A factory can operate at the level of autonomy its sensor can verify, no more. Osmani refers to this as back pressure. With only compilers and unit tests, agents propose and humans verify everything. With per-change validation in production-like environments, agents iterate until verification passes, and humans review intent and supporting evidence. Anthropic's engineers still examine every significant change to their codebase, but they evaluate evidence demonstrating the change achieves its stated purpose rather than inspecting every line of code. With held-out test sets and rapid rollback capabilities, certain change categories can merge without human review.
A factory can run as much autonomy as its sensor can verify and no more. The sensor, not the model, sets the level.
The sensor, not the model sophistication, determines autonomy ceiling. A superior controller operating on a flawed sensor reaches incorrect conclusions faster, and human review of every change also functions as a sensor—one with latency measured in hours and bandwidth of a handful of changes per reviewer daily.
Prioritize measuring the sensor rather than agent productivity. Pull request volume and token consumption per engineer indicate agent effort. Time to signal, escape rate, and concurrent verification capacity reveal which property is constraining, while change failure rate and rework rate indicate loop stability. Begin with the first three metrics.
Distributed systems complicate sensor design
In distributed architectures, behavior diverges across service boundaries. A field renamed in one service that another service's code still expects. A consumer relying on ordering guarantees its message topic does not provide. Each change may be correct in isolation yet incorrect when combined, requiring a faithful sensor to encompass the real services surrounding a change. Achieving all three properties simultaneously becomes difficult: fidelity demands real neighboring services, while latency and bandwidth demand an environment containing those neighbors for every change, provisioned in minutes. Most teams achieve two of three.
Validating multiple pull requests on a shared environment delivers fidelity alone. The environment is genuine, but it processes one reading at a time and reports hours after changes merge, outside any agent's loop. Testing multiple changes in a single run to conserve resources makes failures unattributable, preventing agents from acting on failed results.
Replicating the full stack or substantial portions per change improves fidelity and isolation but increases latency and bandwidth costs. Provisioning requires tens of minutes, far exceeding agent iteration cycles, and expenses climb with concurrent agents, forcing teams to reserve this approach for high-impact changes. Behavioral twins function for external services with predictable public interfaces. For 150 internal services, a clone becomes a parallel implementation that diverges while the actual services continue evolving in production.
At scale, factories require a mechanism providing each agent and each change a realistic environment where actual services respond to requests, without the provisioning overhead or latency of stack duplication. This sensor satisfies all three properties simultaneously—the model underlying Signadot's design.
Sensor-first thinking transforms the software delivery lifecycle
The separation between teams merging 30,000 changes daily and the rest stems not from agent capability—now widely available—but from delivery infrastructure centered on a sensor delivering results in minutes, matching production reality, and operating for every change concurrently.
On distributed systems, building that sensor represents the hardest challenge, determining whether additional agents produce more software or simply accelerate failure propagation.