An agentic software factory is a repeatable delivery system in which AI agents perform coordinated development tasks, while people define the intent, the constraints, the acceptance criteria, and the approval policies. Work goes in as a ticket, a specification, or an incident signal. Verified, releasable changes come out.
A factory is an operating model. It is not a single coding tool, and there is no universal standard architecture for one. Two teams can both run a software factory and look very different on the inside. What they share is the idea that the unit of work is no longer one software developer writing one change. It is a system that produces changes continuously, with people responsible for the system.
This guide explains how a factory works, the difference between a "light" and a "dark" factory, what it needs to run responsibly, and where independent code verification fits.
How is an agentic software factory different from AI coding assistants and CI/CD?
Three things are easy to confuse here. They overlap, but they answer different questions.
A coding assistant makes one person faster. CI/CD checks and ships code. A factory sits above both: it decides what work to do, has agents do it, and routes the result through checks and approvals.
It also helps to separate this from two older uses of the word "factory."
Traditional software factories. The idea dates to a 1968 paper by Bob Bemer, "The economics of program production," and for decades it meant standardizing software work into repeatable, instrumented processes. It often fell flat, in part because ideas are hard to stamp out like parts. AI agents change that calculation because they can do the repetitive reasoning work, not only the repetitive mechanical work.
AI factories in data centers. In infrastructure and data center discussions, an "AI factory" usually refers to the compute and operations that produce AI models and their output. That is about running AI, not about how software gets built.
How does an agentic software factory work?
Here is one concrete example of the flow. The names of the steps vary by team, but the shape is common.
- Issue or specification. A person writes down what should change and how success will be judged. A production incident or user request can also create work.
- Context and planning. The agent gets the relevant parts of the repository, the team's coding standards, and the architecture rules. It proposes a plan.
- Agent implementation. The AI agent writes the change inside an isolated environment, with only the permissions it needs.
- Tests and independent analysis. Tests run, and so do checks that were not written by the agent: static analysis, security scanning, dependency checks.
- Pull request and CI verification. The change is opened as a pull request and goes through the same pipeline as any other code.
- Failed checks return the work. If something fails, the agent gets the findings and revises. This repeats until the checks pass or the task is handed to a person.
- Authorized release. Approval rules decide who or what can merge and deploy. Some changes need a person. Low risk changes may not.
- Production feedback. Monitoring, incidents, and user reports flow back into the queue as new work.
Two design points matter more than the rest. First, agent permissions are bounded: an agent should reach only the repositories, data, and actions its task requires. Second, approval boundaries are explicit: the factory knows which changes can pass on automated evidence and which require a person to decide.
Addy Osmani, who works on Claude Code at Anthropic, offers a useful way to picture this. A loop is one agent doing a job on repeat: gather context, act, check the result, go again. A harness is the environment around the loop: the sandbox, the tools, the memory, and the gates that define "done." A factory is many harnessed loops running at once, fed by a queue of work and drained through a review gate into production, with people owning the whole thing from above.
His observation about cost explains most of what follows. Generation, tests, and scanning are close to free at scale. The review gate, where judgment is applied, is the one expensive step that does not scale.
What is the difference between a light factory and a dark factory?
The terms come from manufacturing. A "lights-out" factory runs with no people on the floor, so the lights can stay off. Osmani applies the image to software, and the two terms are now widely used, though definitions are still settling.
A dark factory lets agents scope, build, and ship code without anyone reading the details. Machines write the change and other machines verify it. Humans set goals at the start and look at outcomes afterward.
A light factory keeps people in the loop where judgment matters. The agents still do most of the building, but a person reads what comes out before it ships, and human judgment moves earlier too, to product, design, and architecture decisions made before an agent starts.
The same pipeline can be either. The difference is where the lights are on.
Why does this choice matter? A dark factory feels fast because the slowest step, human review, disappears. The cost shows up later. Osmani calls it comprehension debt: the widening gap between how much code exists and how much any person still understands. Tests can stay green the whole time while that gap grows. He cites Dex Horthy, co-founder of HumanLayer, who ran a fully automated factory for about four months with no human reading the code, and found the damage only through painstaking manual debugging. The reckoning, Osmani writes, is quiet and late rather than dramatic.
A light factory has the opposite problem. If a person must read everything, the review queue becomes the bottleneck and the factory stalls.
Many teams will likely land between the two: lit at the places where a wrong answer is expensive, dark in small corners where the check is cheap and hard to fake. Osmani offers a practical rule for deciding. A loop can run unattended only when its check is cheap, runs often, and cannot easily be fooled, for example a pass or fail test, a type check, or a property test. Short loops are easier to verify than long ones. Changes to authentication, billing, or a public API contract are the places to keep the lights on.
The rule underneath is one of back pressure: give a loop only as much autonomy as you can cheaply and reliably verify, and no more.
What components does an agentic software factory need?
The split of responsibility is the important part. Agents do the execution. Tooling does the checking, repeatably. People own intent, set the rules, make the calls that need judgment, and stay accountable for what ships.
What are the benefits and risks?
Benefits. Teams adopting factory models report large gains in throughput and shorter backlogs, though these are mostly vendor and consultancy reports and not independent benchmarks. BCG Platinion reports 3 to 5 times productivity gains for organizations running this model. Augment Code reports, from its own engineering team, that size-adjusted output per developer rose 4.5 times and median time to merge fell from 11.2 hours to 3.1 hours between November 2025 and July 2026, in a case study the company itself describes as not a controlled experiment. Treat these as signals worth testing in your own environment, not as promises.
Risks. The same speed creates problems that are easy to underestimate:
- Review bottlenecks. A study of agent activity on GitHub found lines of code up 2,450% while shipped releases rose 30% (NBER Working Paper 35275, Demirer, Musolff and Yang). Code gets created faster than anyone can confidently release it.
- Insecure dependencies. Agents can add packages quickly, and a risky malicious package can slip in unless something checks it.
- Architectural drift. Each change can look reasonable while the whole system slowly loses its shape.
- Rework and token cost. Changes that miss project context drive rework, and every retry spends tokens.
- Verification debt. Code piles up faster than anyone can check it, so unchecked risk builds up in production.
Why passing tests is not enough. Tests show that code does what the test expects. They do not show that the code is secure, maintainable, or consistent with the architecture. And when the agent that wrote the code also wrote the tests, a pass mostly means the agent agrees with itself.
The obvious fix, using another model to review the first model's work, helps but does not close the gap. In published research on AI judges, 7% to 17% of verdicts changed when the identical question was asked again at temperature zero (Kumar, Rathore and Moitra, arXiv:2610.12083), and 7% to 34% flipped when another AI argued against them (Zhao et al., arXiv:2608.12645). A gate that changes its answer under pressure is a weak gate.
People are not a complete answer either. In Wharton research on how people use AI advice, participants followed the AI 93% of the time when it was right and 80% of the time when it was wrong (Shaw and Nave, 2026). A tired reviewer skimming a large agent-written pull request is in exactly this position.
Where does Sonar fit in an agentic software factory?
Sonar does not run the factory. It does not replace your coding agents, your orchestration, or your CI/CD. Sonar is the independent verification and governance layer that works alongside them.
Sonar's point of view starts from a simple idea: code is now abundant, and confidence is scarce. Sonar CEO Tariq Shaukat has made this case in recent conference talks, including a keynote at AI Engineer New York on October 14, 2026. His argument, drawing on lessons from how factories transformed manufacturing, is that code confidence, not model capability, is the defining constraint of agentic development.
Sonar expresses this as a formula:
Code confidence = Intent × Guiderails × Verification × Evidence
- Intent: goals and standards, clearly specified before the agent starts.
- Guiderails: boundaries that guide and govern what agents can do and which rules apply.
- Verification: thorough, independent checks on every change.
- Evidence: a consistent, auditable record of what was checked, what was found, and how it was resolved.
The terms are multiplied on purpose. If any one is zero, confidence is zero. Clear intent without verification does not prevent mistakes. Verification without evidence does not create accountability. And evidence without independent verification is only a record of what an agent claimed.
This is where the light and dark factory question gets a practical answer. Osmani's test for "which loops can run unattended" is whether a cheap, hard to fake check exists. Independent verification is how teams build those checks, which is what lets them turn more lights off safely.
Independent verification: zero trust and multilayered
Sonar's view is that verification should be zero trust: it works the same no matter how the code was written, uses a different method from the one that generated it, keeps a clear separation of duties, and is repeatable and explainable. It should also be multilayered. No single approach catches every problem, so teams combine deterministic analysis, which gives the same answer every run, with agentic review that reasons about intent and business logic.
The Agent Centric Development Cycle (AC/DC)
Sonar organizes this work as the Agent Centric Development Cycle, with three stages: Guide, Verify, and Solve. They run across three loops of a software factory.
SonarQube analyzes code across 45+ languages and frameworks and applies the same quality profile to code from any agent or any model, so standards do not vary by tool or team.
What Sonar has measured
- In Sonar's published testing, Sonar Vortex cut token consumption by up to 36% on navigation-heavy tasks and reduced issues in committed code by up to 92% for a leading coding agent.
- In Sonar's upcoming 2027 State of Code Developer Survey (n=1,026), SonarQube users were 81% more likely than non-users to say AI coding has had a very positive impact on code security. This is a "very positive" top-box result, and it describes correlation, not proof that SonarQube caused the difference.
- An enterprise fintech customer reported clearing 1,000 hours of technical debt in 45 days with SonarQube Remediation Agent. This is customer reported.
Sonar helps teams build confidence in what their agents produce. It provides independent checks on every change and an audit trail of what was checked, what was found, and how it was resolved, so teams can decide, with evidence, how much autonomy to give their agents
How should teams get started?
Start small and make the boundaries explicit. A practical sequence:
Pilot checklist
- ☐ Pick one bounded area: a service, a repository, or a class of work such as dependency upgrades or test coverage.
- ☐ Write acceptance criteria before the agent starts, including security and architecture expectations.
- ☐ Give the agent least-privilege access: only the repositories, data, and actions the task needs.
- ☐ Run independent checks that the agent did not write and cannot change.
- ☐ Set approval rules: which changes merge on automated evidence, and which need a person.
- ☐ Keep the lights on for high stakes changes: authentication, billing, public APIs.
- ☐ Send findings back to the agent for revision and record the result.
- ☐ Review the results weekly and widen the scope only when the checks hold.
What to measure. Generated lines of code is a poor measure of success. Track:
- Lead time for accepted changes
- Escaped defects (problems found after release)
- Rework rate
- Review effort per change
- Cost per accepted change, including tokens
A quick self-check you can use today. The next time an agent opens a pull request, ask four questions. Did the agent know your standards before it started? What was it allowed to touch, and what needed a human decision? Did something other than the model that wrote the change check it? Can you show what was found and how it was resolved? Wherever the answer is no, that is your confidence gap, and where to start.