What is an AI software factory?

An AI software factory is a system that industrializes the delivery of software. A described need enters as a standardized input, AI agents carry out the work of the entire delivery cycle inside a controlled and instrumented path, and a deployed application comes out, owned by the organization that ordered it, with every version traceable to what produced it.

If you read one thing in this guide, read this: what separates two factories is not how fast they produce. It is how far the line runs without human intervention, and who accepts the result at the end.

Definition: the four terms that carry the meaning

Four parts of the opening sentence do the work, and each one excludes something.

Industrializes. The result is repeatable rather than dependent on who happened to do the work. Same input, same path, same controls, comparable result. A skilled person prompting a model until something appears is not industrialized, however good the result.

The entire delivery cycle. Not code generation alone. Scoping, specification, design, build, quality, data, deployment, and the changes that follow. A system that covers one stage augments a role. A factory covers the cycle.

Inside a controlled and instrumented path. Everything that ships passes the same gates, and the line reports on itself. Controls that can be bypassed are not controls, and a line that cannot be measured cannot be improved.

A deployed application you own. The deliverable is production software, backend included, in your repository, on infrastructure you choose. Not a prototype, not a demo, not an application that only runs on the vendor's runtime.

Glossary: the terms used in this guide, in plain language

Example: one internal application followed through the six stages, from the request to the fortieth change

Take an application that exists in almost every organization: the tracking of purchase requests. Today it lives in a spreadsheet, an email thread, and one person who remembers the rules. Here is the same need running through a factory. This is an illustration, not a customer case.

Scoping. The operations manager describes the need: who submits a request, who approves it above which threshold, which supplier information must be attached, and which system holds the final order. The constraints surface here: two approval levels, an internal purchasing policy, personal data in the supplier contacts.

Specification. The need becomes a written specification: four screens, the approval rules by amount and by entity, the data model (request, line item, supplier, approval), who is allowed to see what, and the connection to the ordering system. The operations manager reads it and approves it. Nothing is built before that.

Build. Agents produce the application against the approved specification: screens, business logic, database, access rules, integration, tests. The work runs in an isolated environment, with no access to the production ordering system and no access to live supplier data.

Review. The operations manager opens the running application and submits a real request against test data. The second approval level does not trigger above the delegation threshold. That correction goes back into the specification, not into a ticket queue.

Deployment. The accepted application is deployed on the chosen infrastructure, connected to the company's single sign-on, with the integration now pointing at the real system. Depending on the organization, the deployment is run by the IT team or managed by the factory.

Evolution. Six months later a subsidiary needs a third approval level. The change is verified against the approved specification, so the rules that already worked keep working, and the requests already recorded are carried through the change to the data model instead of being reset.

Two things in that sequence are the whole subject of this guide. The operations manager approved a specification and accepted the result in the running application, without reading code. And the sixth stage is the same cycle as the first, run again, against data that now exists.

Composition: the five layers a factory is built from, from intent to controls

1. Intent

The layer that turns a need into a standardized input: scope, acceptance criteria, a named owner, a target environment, and the specification that binds them together. It states what the software must do, in terms the person who needs it can read and approve.

This layer decides who is allowed to put work on the line, and in what form. It is the most commonly under-built of the five.

2. Context

What the agents are allowed to read and required to respect: the existing codebase, the data model, the systems of record to integrate with, the design system, and the internal standards and policies that constrain any solution.

Context is what separates an application that fits your organization from one that is merely correct. It is accumulated, versioned and reused, not re-supplied by hand on every request.

3. Agents and orchestration

The role spectrum that covers the cycle, typically product, design, analysis, build, quality, data and deployment, with one specialized agent per role. Around them sits the harness that gives each agent its instructions, its permitted actions and its context, and the orchestration that sequences the roles and handles hand-offs, retries and failures.

Orchestration is what makes multi-agent work reproducible instead of emergent, and it is what allows the stages to follow one another with no human relay in between.

4. Execution and infrastructure

Where the work physically happens: an isolated environment per unit of work, provisioning of the resources the application declares (database, queues, object storage), preview environments where behaviour can be observed before anything merges, and the deployment path to the target infrastructure.

Isolation is a security property before it is a convenience: the build should hold no standing access to production systems or live data.

5. Controls

Everything that decides whether output is allowed to ship: automated tests and non-regression checks, security scanning, secret handling and egress policy, access rules (SSO, RBAC), the audit trail recording who approved what and when, and the observability that reports what the deployed application is actually doing.

This is the layer a security reviewer asks about first, and the layer that determines whether volume is an asset or a liability.

Process: what enters and what comes out at each of the six stages, and who decides

The cycle is the same on the first version and on the fortieth change. What differs is that later runs start from something that already exists and has to keep working.

Two remarks on the last row. Evolution is not a phase that comes after the project: it is the same cycle, run again, and it is where most of the lifetime cost of internal software sits. And it is the only stage that has to deal with data that already exists, which is the part most implementations handle worst.

Properties: the four observable tests that separate a factory from a pipeline

Definitions published across the market converge on four properties. They are the practical test of whether a system deserves the name.

A standardized input. Work enters with a scope, acceptance criteria, an owner and a target environment. If work enters as a conversation, there is no line, only a faster conversation.

A single controlled path. Everything that ships passes the same gates, whatever produced it, human or agent. A path that gets bypassed when a deadline approaches is not a control.

Measurable output. Cycle time, defect rate and cost are reported by the line itself rather than estimated afterwards. This is what allows a factory to be improved instead of merely trusted.

Replayability. Any shipped version can be reconstructed from what produced it: its inputs, its specification, the model versions used, the policies in force at the time. This is what makes an audit possible after the fact rather than an exercise in recollection.

One structural point completes the list: a factory is a loop, not a one-way pipeline. What the deployed application reports, in incidents, usage and defects, comes back in as the next input.

Boundaries: the five adjacent categories it is confused with, and where each one stops

Each of these is legitimate, and each stops somewhere specific.

Origins: why the idea did not hold in 2004, worked in defense from 2017, and became possible in 2026

The idea predates AI by twenty years. It was published in 2004 by two Microsoft architects, who argued that software should be produced on repeatable lines rather than assembled through individual effort. It did not hold, for a specific reason: the line was fed with models written in a formal language, every application still had to be assembled by hand from components, and the standardization had to be designed in advance. A line that expensive only pays off by producing many near-identical products, which is exactly what an organization's internal software is not.

Defense programs revived it from 2017, with one change that mattered. Those organizations kept operating what they shipped, so the factory carried the consequences of its own output rather than delivering and walking away.

Three things changed by 2026, and they hold together.

The cost of producing one variant collapsed. Producing an application specific to one organization no longer has to be amortized over many similar ones. The line can produce a single application that fits exactly, which is what removed the 2004 verdict of generic output.

The input no longer has to be formal. The 2004 line was fed with models in a formal language, so only engineers could put work on it. A specification in plain language is now enough to produce from, which changes who is able to feed the line.

Standardization moved from the components to the gates. Instead of constraining what can be built, in advance, by designing the parts, a factory now controls what is allowed to ship, at the gates. That is what makes variety and control compatible for the first time.

Together, those three mean production is no longer the constraint. Which raises the question the next section answers: how far does the line run on its own, and where does someone decide?

Autonomy: what runs with no human intervention, and the two decisions that stay yours

In the standard factory, the human sits inside the loop. An engineer writes the specification, in the vocabulary of the codebase. Engineers unblock the agents between stages. An engineer reads the diff and decides whether it ships. The line is faster, but it stops at every stage waiting for someone, and its throughput stays capped by how much code your engineers can vouch for. The 2026 measurements of review time land exactly there.

An autonomous factory moves the human to the edges of the loop. The six stages follow one another with no human relay: scoping produces the specification, the specification produces the application, the application is tested and checked against what already runs, and deployment follows. Nobody drives the agents, and nobody hands work from one role to the next.

Autonomous does not mean nobody decides. Two decisions stay human, and they are the two that matter.

What goes in. The business owner approves the specification, in plain language, before anything is built.

What comes out. The same person accepts the result inside the running application, not in a diff.

That combination is what makes autonomy acceptable in a regulated organization. Autonomy with no checkpoint is the first fear buyers name, and they are right to name it. Autonomy between two checkpoints held by the business is a different proposition: the work happens on its own, the decisions stay where they belong, and every version points back to a specification someone approved.

One more property makes that hold over time: the specification is kept. The market has begun to say that the specification, not the diff, is the real control surface. That is the right instinct, and it is not yet the practice. In both versions shipping today the specification is an input that disappears once the change ships. That makes it a better prompt, not a contract, and it leaves nothing to check the next change against. Kept, it becomes the reference that new behaviour is verified against, the reason the data already in the application can be carried through a change to the data model, and the artefact that turns the audit trail into a by-product of how the software was produced.

Checklist: whether a factory answers your situation, and the six questions to ask next

It answers your situation if

• The process is durable and business-critical, and it will still matter in three years.
• It runs today on a spreadsheet, an email thread, or an application nobody maintains any more.
• You have no delivery team to put on it, and it will never come ahead of the critical projects in the backlog.
• The software touches sensitive data, or has to clear a security, compliance or procurement review.
• Business teams have already built applications with AI, and nobody can say what those applications do or where they run.
• The need will keep changing. Other versions will follow the first one.

It does not if

• What you need is a throwaway prototype, to be validated and discarded.
• What you want is to make your own developers faster on your own product. That is a coding assistant.
• A packaged product on the market already covers the need properly.
• Nobody on the business side will own the need. A factory needs someone able to approve a specification and accept the result.

The six questions to ask of any option, including an internal build

1. Who accepts the work? If only an engineer reading code can accept it, your delivery capacity is your engineering review capacity.
2. What does the business owner approve, and can they read it? A specification in plain language is a contract. A ticket is not.
3. Is the specification kept after the change ships, and is the next change verified against it?
4. What happens to the data already in the application when the data model changes?
5. Can the build reach your production systems or your live data by default? The safe answer is that it cannot by construction, not that it is switched off by configuration.
6. Where does the code live when it is done, and what does it need in order to keep running?

Deliverable: what you hold when the factory has finished

The deliverable is the whole application, backend included: the screens people use, the logic behind them, the database, the access rules, and the integrations with the systems you already run.

It arrives as standard code in your own Git repository, deployed on the infrastructure you choose, hosted, your cloud or on-premise. You can read it, change it, and keep it without the platform that produced it. Ownership is what separates a factory that supplies you from a platform you depend on.

Questions: the five asked most often, and their short answers

Does it replace developers? No, and that is not where it acts. A factory produces the software end to end, so the demand for internal software stops landing on your developers. They stay on the critical projects, the ones that carry your product and your advantage, instead of being scattered across another approval workflow. In an organization with no developers to put on it, the factory delivers what would otherwise stay in the backlog.

Do you need a technical team to use one? No. The person who owns the need can go the whole way: describe it, approve the specification, accept the result in the application, and have the deployment managed. That is the low floor. The ceiling stays high: if you do have a technical team, it keeps control wherever it wants it, on the target infrastructure, the connected systems, the access rules, and on the code itself, since the code is in your repository.

What is the difference with describing an application in natural language? Natural-language input is now common to every category, so on its own it tells you nothing. The difference is what happens after: whether the whole cycle is covered, whether the controls hold, and whether the result is yours and maintainable.

How fast is the first version, and is that the right question? Speed to a first version has become the least discriminating criterion, because every category is fast at it. The cost sits in the changes that follow.

What happens if you stop? You keep the application and the specifications. Standard code, in your repository, on the infrastructure you chose. It keeps running without the factory that produced it.

Maleus: an autonomous factory, and what that changes against the standard definition

Maleus is an autonomous AI software factory for internal software. A team of AI specialists covers the full delivery cycle, one for each role: product, design, analysis, build, quality, data and deployment. The six stages run without a human relay between them, and the two decisions that matter stay with the person who needs the software.

The build is deterministic and governed by the approved specification, so behaviour holds as the software evolves. Each build runs isolated, with no standing access to your production systems, and every action is recorded. SOC 2-ready and ISO 27001-compatible.