AI software factories: How autonomous coding works

An AI software factory is an automated software delivery system that accepts a product requirements document, breaks it into implementation tasks, generates code, validates changes, and moves approved work toward deployment with minimal human intervention. Also called a dark factory, it represents the highest practical level of autonomy for coding agents: humans set direction while agents make many of the smaller engineering decisions. The goal is not to remove engineering judgment from every project. It is to make selected work, especially prototypes and bounded features, faster to explore and ship. A shared agent-first control plane gives this workflow persistent tasks, acceptance criteria, tests, and accountability.

At a Glance

AI software factories automate the path from a product plan to working software, but autonomy must match the risk of the work.

• Definition: A software factory coordinates coding agents across planning, implementation, review, testing, and deployment.
• Best current fit: Prototypes, proof-of-concepts, product spikes, and clearly bounded application work.
• Core constraint: Reliability depends more on the harness, tests, permissions, and feedback loops than on a single model prompt.
• Human role: Humans still define intent, set quality gates, decide autonomy levels, and own production accountability.
• Operational need: Agents need durable project context rather than disconnected prompts and ephemeral chat history.
  

What is an AI software factory?

An AI software factory is a workflow that turns high-level product intent into deployed code by assigning coding agents a sequence of planning, implementation, validation, and release tasks. Instead of manually directing every ticket, engineers define the outcome and supervise the process through policy, tests, and approval boundaries.

The term dark factory describes the same general idea. The name emphasizes that work can continue without a person inspecting every line of code or handling each handoff. A requirements document enters the system. The system decomposes it into tasks, builds changes, reviews pull requests, validates behavior, merges work, and may deploy it.

This is not simply an autocomplete tool with a longer prompt. It is an operating model for agentic development. The system needs a task queue, repository access, tool permissions, test execution, source control workflows, deployment paths, and durable state about what has already happened.

Dan Shapiro’s five-level model of AI coding autonomy provides a useful way to understand the distinction. Lower autonomy levels keep the engineer closely involved in every implementation decision. The factory model moves closer to a destination-driven approach, where humans specify the destination but agents navigate the detailed route.

Where do AI software factories work well today?

AI software factories are most credible today for work with a limited blast radius, clear acceptance criteria, inexpensive iteration, and strong automated validation. They are particularly useful for prototypes and exploratory builds, where quickly testing an idea matters more than perfect architecture on the first attempt.

A useful starting point is a proof-of-concept that would otherwise consume several days of engineering time. For example, a team might want to test a retrieval-based support assistant, a lightweight internal dashboard, a new onboarding flow, or a data integration. The factory can produce a working version that exposes product and technical questions early.

This approach has three practical advantages:

• Lower cost of exploration: Teams can test more ideas without treating each one as a full production commitment.
• Faster feedback: A deployed prototype gives product and engineering teams something concrete to evaluate.
• Reusable process improvements: Every failed build, flaky test, and incorrect handoff reveals a weakness in the agent harness that can be improved.

The important caveat is that a prototype is not evidence that every application can run unattended. A low-risk chat application, for example, does not prove the same workflow is safe for payment systems, complex migrations, security-sensitive infrastructure, or high-consequence customer data.

What makes a software factory reliable enough to use?

Reliability comes from a disciplined execution harness, not blind trust in a coding agent. Clear plans, scoped permissions, structured tasks, automated tests, code review rules, deployment controls, and observable failures make autonomous work safer and more repeatable.

Models, coding harnesses, and orchestration workflows are improving in parallel. But a stronger model does not eliminate the need for engineering controls. If the factory can make changes without a person catching every small error, then the system must catch and contain those errors itself.

Start with explicit product intent

A product requirements document should describe the user problem, required behavior, constraints, non-goals, and measurable acceptance criteria. Vague direction creates vague implementation. If an engineer could not tell whether a task is complete, a coding agent will struggle with it too.

Decompose work into independently testable tasks

Tasks should have a bounded purpose, known dependencies, and a definition of done. This makes it easier for agents to work in parallel or sequence work correctly. It also gives the system a way to identify blocked work instead of repeatedly attempting an impossible task.

Make verification part of the workflow

Tests cannot be an afterthought when agents are producing changes at speed. Unit, integration, and end-to-end tests should tie back to the acceptance criteria they prove. CI/CD results need to be recorded with the relevant branch, commit, and pull request, so a green result actually means something traceable.

Use constrained deployment paths

Not every successful build should go directly to production. A factory can first deploy to a preview or staging environment, validate expected behavior, and require an explicit release gate for higher-risk systems. The appropriate gate depends on the cost of being wrong.

Official workflow tooling also matters. The AI Software Factory repository describes an early alpha implementation that installs an opinionated setup through a coding-agent prompt and uses Archon workflows underneath. Its alpha status is a reminder that early systems should be treated as experiments, not an excuse to skip engineering safeguards.

Give agents work with a definition of done.

A shared control plane can connect tasks, acceptance criteria, tests, CI results, and human gates, so agents operate against project state instead of an isolated prompt.

Explore agent-first project workflows

How should teams choose the right autonomy level?

Teams should choose autonomy based on reversibility, system complexity, data sensitivity, and validation quality. High autonomy fits inexpensive-to-reverse work with clear automated checks, while critical changes require stronger guardrails and more direct human review.

Autonomy is not a binary choice. A team can use the same coding agents in multiple modes:

• Assistive: An agent suggests code while an engineer makes all decisions and commits changes.
• Supervised: An agent implements a scoped issue, while a human plans, reviews, and approves release.
• Workflow-driven: Agents pick up structured tasks, execute tests, open pull requests, and progress only through defined quality gates.
• Highly autonomous: A factory handles an end-to-end flow for bounded work, with intervention reserved for exceptions or release controls.

The supervised and workflow-driven modes are often the most useful place to start. They expose the real operational problems, such as missing context, weak acceptance criteria, unreliable tests, and unclear ownership, without requiring a leap to unattended production deployment.

Do not confuse automation volume with engineering maturity. An organization that generates many branches but cannot connect changes to requirements, tests, and accountable owners has created a faster way to lose context.

How do you build a practical software factory workflow?

A practical software factory begins with one repeatable delivery path, not a giant autonomous platform. Define a narrow type of work, make its inputs and quality gates explicit, run it repeatedly, and improve the harness from observed failures before expanding scope.

1. Select one workload. Choose a low-risk class of work, such as internal tooling prototypes, small web features, or product experiments.
2. Write structured requirements. Include user outcomes, acceptance criteria, constraints, non-goals, dependencies, and test expectations.
3. Create a task graph. Split the work into small, testable implementation units with clear ordering and ownership.
4. Give agents scoped tools. Limit repository, environment, and deployment access to what each task actually requires.
5. Run automated checks. Require builds, tests, linting, and other deterministic validations before changes advance.
6. Capture results and failures. Record generated plans, commits, test output, review findings, and deployment outcomes.
7. Improve the harness. Fix recurring failure modes in prompts, task templates, test coverage, tool permissions, or routing rules.

One way to run this in Levr’s agentic workflow is to define the intent as an issue with structured acceptance criteria, allow a coding agent to work against that shared object, require tests and workflow gates before completion, and keep human approval available at the appropriate boundary. The task, proof, and activity trail remain connected as the work moves.

What mistakes can derail an autonomous coding workflow?

The most common failures are not dramatic model failures. They are ordinary software delivery problems amplified by speed: ambiguous requirements, weak tests, excessive permissions, invisible agent actions, and treating a prototype workflow as production-ready before it has earned that trust.

Starting with an overly broad goal

“Build a complete application” is not a useful first factory task. It hides unresolved product decisions, integration risks, and quality expectations. Start with a narrow deliverable whose output can be inspected and tested.

Using one prompt as the whole system

A long system prompt may help guide behavior, but it cannot replace tasks, state management, tests, source control, and release policy. Prompts are instructions. A software factory is an operational system around those instructions.

Giving agents unrestricted production access

Broad credentials make early demos easy but turn small mistakes into expensive incidents. Apply least privilege. Separate read access from write access. Use sandboxed environments for unfamiliar code paths, external inputs, and experimental integrations.

Measuring output instead of outcomes

More generated code, more pull requests, or more completed tickets do not prove a factory is working. Track whether the system produces correct behavior, maintains test health, avoids regressions, and reduces cycle time for work that actually matters.

Skipping the feedback loop

A factory improves when failures become reusable lessons. Treat each bad plan, broken deployment, or failed validation as evidence about the harness. If failures disappear into chat logs or disconnected tools, the system cannot compound learning.

Why does shared project context matter for coding agents?

Shared project context gives coding agents the information needed to make coherent decisions across tasks, runs, and contributors. It reduces repeated prompting, prevents plan drift, and makes it possible to connect implementation choices to the requirements, tests, reviews, and outcomes that justify them.

Prompt-only workflows tend to fragment quickly. One agent receives a feature request. Another agent sees a partial codebase. A third receives a failed test output without understanding the original intent. Each interaction may be useful alone, but the system lacks a durable operational memory.

For engineering managers, the problem is equally practical: when humans and agents both contribute, the team needs to know what changed, why it changed, what validation ran, and whether work is blocked. That requires more than a transcript of agent activity.

Levr supports this model through projects and issues that agents and humans can both update, structured acceptance criteria, workflow gates, native test records, and attributed activity history. Its agent-first features allow teams to mix coding agents while keeping work connected to the same shared project state.

Technical Deep Dive FAQ

What is an AI software factory?

An AI software factory is a coordinated software delivery system where coding agents receive product intent, break it into tasks, write code, run validations, and move changes through a controlled release process. The term describes the workflow around agents, not just the model itself. A factory needs requirements, task management, repositories, automated testing, source control, deployment controls, and records of what happened. Humans remain responsible for the operating rules, quality standard, and level of autonomy granted to the system.

What is a dark factory in software development?

A dark factory is another name for a highly autonomous AI software factory. It refers to a setup where software can progress from a high-level requirements document to shipped code without a person manually reviewing every implementation decision. It does not mean that responsible teams have no oversight. In a mature dark factory, humans set the direction, define permissions and quality gates, review exceptions, and choose which projects can safely use higher levels of autonomy.

Can an AI software factory deploy code to production?

Yes, a factory can be designed to deploy code to production, but that should be a deliberate policy decision rather than the default for every project. The safest initial use cases have strong automated tests, limited consequences if they fail, and easy rollback paths. Production deployments should depend on explicit conditions, such as passing CI/CD checks, approved environment rules, and release gates. High-risk changes involving security, payments, sensitive data, or migrations generally need more human review.

How is an AI software factory different from a coding assistant?

A coding assistant usually helps with a local task, such as generating a function, explaining code, or proposing a patch. An AI software factory coordinates the full delivery lifecycle around those capabilities. It turns requirements into sequenced work, stores progress, assigns tools, opens and validates changes, and potentially deploys results. The difference is orchestration and accountability. A factory needs to know not only what code was generated, but also which requirement it satisfies, which tests verified it, and who approved it.

What should a PRD include for coding agents?

A product requirements document for coding agents should state the user problem, expected behavior, acceptance criteria, constraints, non-goals, dependencies, and expected validation. Requirements should be specific enough that a person could determine whether the work is complete without guessing. Good acceptance criteria also provide a bridge to tests. For example, instead of requesting “better search,” specify supported query behavior, expected empty states, access rules, performance constraints, and what must not change in the existing workflow.

Do AI software factories need automated tests?

Yes. Automated tests are central to reliable autonomous development because they provide repeatable evidence that a change meets expected behavior. A coding agent can generate code quickly, but speed without verification simply produces uncertainty faster. Teams should connect tests to acceptance criteria and record results against the relevant commit or pull request. Tests do not catch every problem, so they should work alongside review gates, constrained deployments, observability, and rollback plans.

How do you prevent coding agents from making unsafe changes?

Prevent unsafe changes by limiting what an agent can access and by enforcing deterministic gates before it can advance work. Apply least-privilege credentials, separate environments, restrict write access, and sandbox untrusted or experimental execution. Require build and test results before merge, and use explicit approval boundaries for sensitive actions. Keep an attributable activity trail for agent actions, tool use, commits, and test results. Security comes from structural constraints, not from assuming a prompt will always be followed.

Can multiple coding agents work on the same project?

Multiple coding agents can work on the same project when tasks are scoped, dependencies are visible, and changes flow through a shared source-control and project-management process. Parallelism is valuable when tasks are independent, such as implementing separate components or researching isolated options. It becomes risky when agents modify overlapping files or make incompatible architectural assumptions. A shared task graph, clear ownership, repository conventions, test gates, and conflict handling are necessary to coordinate the work effectively.

How should engineering managers measure AI software factory performance?

Engineering managers should measure outcomes rather than raw agent activity. Useful signals include cycle time for eligible work, percentage of work passing validation on the first attempt, defect and rollback rates, test health, blocked-work volume, and the amount of human intervention required per completed task. Attribution also matters. Teams should be able to identify whether a change came from a human or a coding agent and trace it back to its requirement, review, test evidence, and deployment result.

Should a team use an AI software factory for every project?

No. The right level of autonomy depends on the project’s risk, complexity, and ability to validate outcomes. An AI software factory is well suited to bounded prototypes, exploratory builds, and repeatable engineering tasks with clear checks. Complex systems, unclear requirements, sensitive data, and changes with costly failure modes deserve more direct human involvement. The practical goal is not universal autonomy. It is to use automation where it creates real speed without exceeding the team’s ability to verify and control the result.

Key Takeaways

AI software factories are becoming a practical way to accelerate selected software work, but they succeed only when teams treat them as controlled engineering systems rather than autonomous magic.

The best factory is one whose limits are explicit.

• Start narrow: Use a bounded prototype or proof-of-concept before attempting broad production autonomy.
• Design for proof: Tie requirements to tasks, tests, CI/CD results, and deployment records.
• Match autonomy to risk: Increase agent authority only where failures are detectable, reversible, and acceptable.
• Improve the harness: Use recurring failures to strengthen task templates, context, permissions, and validation.
• Keep context shared: Agents work better when project intent, history, and quality gates persist across runs.

The goal is not to eliminate engineering judgment. It is to apply that judgment to better systems, stronger constraints, and higher-value decisions.

Further reading

• The Five Levels: from Spicy Autocomplete to the Software Factory
• AI Software Factory open-source repository
• Archon workflow engine repository
• Levr agent-first project control plane
• Levr features for agents, issues, tests, and CI
• Levr agentic development workflow
  
  

Ship at agent speed

Give your coding agents a control plane, not just a prompt.

Levr connects your coding agents, including Claude Code, Cursor, Codex, and Copilot, to shared project context with issues, gates, test suites, and memory. Free tier available. No credit card required.

Levr keeps agent activity, shared memory, cross-agent context, and project workflows connected in one place.

Get early access, it’s free

No credit card required during beta.