Inside the software factory, and what it takes to build one

A software factory is a managed model for producing software with repeatable inputs, standardized tooling, measurable output, and enough retained context to reconstruct how a change was made. Its practical purpose is to make delivery dependable as requests, repositories, and contributors multiply.

"Software factory" names the concept. Factory is the company and product that implements an agent-native version, using software development agents called Droids. The engineering decision is how to connect their work to the team's existing tests, reviews, releases, and production feedback.

From industrial production to a feedback loop

The idea predates coding agents by decades. Robert Bemer was writing about a software factory at General Electric in the late 1960s, as the IEEE Computer Society's record documents. Hitachi opened its Software Works in 1969. Michael Cusumano's 1991 book Japan's Software Factories examines how Japanese firms organized software production around reusable methods and tools.

Factory's published framing extends the delivery process into a continuous feedback loop. In Factory 2.0, Matan Grinberg and Eno Reyes describe bug reports, conversations, customer feedback, and requirements becoming planned changes. Those changes are built, tested, reviewed, secured, and shipped. Monitoring the deployed software supplies the next signals.

Factory names model independence, sovereign intelligence, and continual learning as requirements for that system. Model independence allows model choice to change with the task. Sovereign intelligence concerns control over the system and the knowledge it accumulates, with data placement determined by the deployment. Continual learning connects findings across stages, such as using an incident to improve a test or review instruction.

How to tell a software factory is working

Repeatable inputs and tooling make the feedback loop easier to operate. A bug report needs enough information to reproduce the failure and identify the behavior to preserve. Once an agent prepares a patch, it should face the same tests, security checks, and release controls as a human-authored change.

Measurable output means connecting engineering activity to results. CI and source-control records can show which checks passed and which revision was approved. Factory's Agent Effectiveness connects usage to engineering work. Useful measures distinguish time spent generating a patch from time spent correcting and reviewing it.

Replayability depends on what the team retains. Preserve the starting revision, environment definition, task constraints, effective model configuration, commands, and resulting patch. Factory's audit and monitoring documentation distinguishes administrative audit events from telemetry and session records. OpenTelemetry export alone does not guarantee that every shipped change can be reconstructed, and another model run need not produce an identical patch.

These practices support the published feedback loop. They can be implemented with in-house tooling, a platform, or a combination. Their value is visible when the next incident improves the process instead of requiring the same investigation again.

How the agent-native variant differs

Earlier software factory implementations emphasized repeatable processes and tooling. Build, test, and deployment automation already executed parts of delivery, while engineers usually investigated requests and prepared the code changes. Coding agents extend automation into more of that investigation and implementation work.

Software development agents can investigate the request, edit the code, and run validation within that process. Factory's Missions provide planning and milestone validation for multi-feature work. Smaller tasks can stay in a normal Droid session, with the existing CI and review process deciding whether the patch is ready.

The bottleneck can move. Faster patch creation may expose missing tests, slow environments, or limited review capacity. Agent-native delivery still requires engineering judgment about compatibility, access, and production risk. Increasing the number of sessions will not repair a validation process that cannot distinguish a correct change from a plausible one.

Production examples

Chainguard builds trusted open-source software and handles upstream package changes across repositories. Its case study describes one two-week Droid session spanning six repositories and building 80 packages. That example makes continuity concrete: decisions from earlier package work remain relevant to later builds and reviews.

Groq, an inference infrastructure company, reports 3x faster medium-complexity feature development and 5x faster quick-turn tasks. The published comparison pairs Droid using Kimi K2 on Groq with GPT-5 on Codex and Claude Code for work on groq/openbench. Its broader engineering account includes new-model launches, where short iteration cycles matter.

Empower describes fintech engineering work across incident response, review, and product questions. It reports reductions of up to 40% in incident response time and up to 50% in PR-approval and product-to-engineering Q&A delays. Nav, a financial platform for small businesses, reports doubled feature velocity and 60% less context-switching.

These are customer-reported outcomes from particular workflows. They illustrate different parts of software delivery and do not establish a universal productivity multiplier.

Decide what to build and what to operate

An organization can build its own orchestration, adopt a managed platform, operate customer-hosted services, or combine those with external engineering support. The useful distinction is which decisions and knowledge remain available to the team. Contracts, repository access, documentation, and operating practices affect that outcome as well as product choice.

Start with intake. A report that omits reproduction steps creates investigation work before an agent can fix anything. Planning then depends on current code and constraints. For a migration, that includes which consumers must remain compatible and which generated files must be rebuilt.

Execution needs a working environment and explicit permissions. Review needs checks that exercise the changed behavior, including cases the agent did not anticipate. A larger volume of patches increases the importance of those checks rather than reducing it.

Release and monitoring connect the result to production. A deployment failure should lead to a reproducible test or an improved release condition. An incident should be traceable to the relevant revision and configuration. Capturing that connection takes deliberate integration work, whether the surrounding platform is built or bought.

Factory's deployment guide describes managed, hybrid, regional, and airgapped patterns. Choose the arrangement that permits the required session, inference, and telemetry paths, then assign the services the team must operate. Customer hosting brings responsibilities for updates and recovery as well as control over placement.

Start where feedback can change the next task

Choose a recurring task with an existing reproduction and test command. Have Droid prepare the patch, keep human review and release controls in place, and examine the corrections needed before approval. This exposes a specific improvement to make in the repository or workflow.

If the same mistake recurs, turn the lesson into a test, a maintained instruction, or an enforced check. If setup repeatedly fails, repair the environment before increasing task volume. When a change spans several dependent features, introduce explicit planning and intermediate validation.

The software factory model is useful when its feedback changes how subsequent work is done. Agents can perform more of the investigation and implementation, while engineers remain responsible for the system's constraints and production outcomes.

Further reading

• The architecture of a software factory
• The software factory platforms worth comparing
• How enterprises actually automate software development
• Factory enterprise overview