Agents have made code abundant, but confidence is scarce, specifically confidence that the code is correct, secure, and ready to ship. Developers tell us that 5% of organizations run AI software factories today and 34% expect to within a year. As factories take on more of the work, the quality of what they ship will depend less on which model writes the code and more on how well each factory checks it. Teams have to engineer confidence into the software factory the same way they engineer reliability into any production system, and that work starts with verification.
Benedikt Stemmildt, Co-Founder and Co-CEO of hackers&wizards and co-author with Alex Merced of Building the Agentic Software Factory, develops these systems with clients every day. On the latest episode of The Next Commit, he told host Tom Howlett that "ultimately this is all about trust." For Benedikt, building that trust means designing factories to run without a human in the loop and giving them checks the team can rely on in place of reading every change.
Turn each failure into a check
Teams improve a software factory by turning each failure into a new check that the factory applies to every change. In that sense, verification is the factory’s feedback system. Teams get the most from it when they run checks inside the development loops, starting with the agentic loop, so each check can shape a change while the agent is still writing it. Teams that build it in this way end up with clear intent, guardrails that keep agents on track, independent verification, and evidence that every check ran. A factory that falls short on any of those gives its owners little reason to trust what it ships.
When Benedikt finds a problem in what a factory produced, he leaves the feature code alone and changes the factory. "I'm reviewing the artifact the factory produced," he says. "If I see something that isn't what we want, I fix the factory." He also starts clients on narrow, repeated work such as dependency updates, because the team already knows which verifications that lane needs before the factory runs.
Confidence needs both kinds of verification
Sonar embeds two kinds of verification at every stage. Deterministic verification is a repeatable assessment based on structural rules and known patterns, and it gives the same answer every time without changing that answer under pressure, which makes it a dependable gate for the standards a team has written down. Agentic verification applies deliberate, context-aware reasoning to verify intent and discover anomalies, covering business logic, deep semantics, and other problems no rule anticipates. Teams need both kinds, because each one checks what the other can't.
Benedikt strikes the same balance in his factories, adding lint rules and ArchUnit tests "so that you can trust the non-determinism more" and handling contextual problems with skills and instructions. He warns that a factory loaded with too many hard constraints becomes "like a cage" that stalls or keeps pulling in a human, while a factory with too few gives its owners nothing to trust.
Both kinds also have to run independently of the agent, model, or developer that wrote the code. Sonar verifies separately from the agents and models a team uses, so one standard holds across all of them, including code written by people. A factory that asks another model to judge its output inherits that model's inconsistency, and recent research shows frontier LLM judges change 7% to 17% of their verdicts when asked the same question again, even with their randomness setting turned all the way down.
As Benedikt points out, teams trust senior engineers even though people are non-deterministic, because a senior engineer works within a known range and won't do anything wildly wrong. Agents carry no such guarantee, and he describes results that leave you asking "what on earth?" Teams need checks that stay the same no matter which agent made the change.
One standard that teaches the agent in every loop
A check that only reports a problem invites the agent to make the warning disappear, and Benedikt's linter example demonstrates the cost. A linter flags a 15-line method against a 10-line limit, and the agent "will just cut it in half," producing two shorter methods that pass the check and weaken the design. An experienced developer would read the warning as a reason to rethink the method's responsibilities, but that knowledge never appears in the message. Benedikt argues that most of our tooling was written for senior engineers, while agents benefit from explicit guidance the way junior developers do.
Sonar issues include rule descriptions that explain why an issue matters and remediation guidance that points toward a sound correction, which gives an agent the context to fix the underlying problem rather than game the check. Sonar applies that standard wherever agents touch code. In the agentic loop, Sonar Vortex gives the agent context and constraints before it writes, verifies each change against the same SonarQube quality profile that gates merges, and prompts the agent to correct its output when a check fails. In the CI verification loop, SonarQube sets the standard through quality profiles and quality gates, and Gitar reviews each pull request for logic and intent and iterates on fixes until CI is green. SonarQube sets the standard; Gitar enforces it at merge speed. In the code maintenance loop, SonarQube Remediation Agent fixes issues in the background and rechecks each fix with the engine that found it, so only verified fixes ship. Every check leaves a consistent, auditable record, which helps a team understand a codebase it no longer reads line by line.
Benedikt considers ownership of that standard the hardest part of building factories. "When we build factories with our clients, it's not a technology problem, not at all," he says. He describes the factory as an internal product, built by factory engineers and fed by product engineers who work closely with the business, and he notes that teams are still working out who owns context, skills, and verification between them. A shared verification standard gives both groups the same definition of good.
Deciding what the factory treats as “good”
The teams building software factories today will decide what their factories treat as “good.” Benedikt closed the episode with advice for developers adjusting to the change: "Find your new flow because this is not going away."
Listen to the full episode of The Next Commit with Benedikt Stemmildt, then explore howSonar's AI code verification fits into your software factory.
