The Agentic Software Factory Enterprises Actually Need [Testμ 2026]

The 10x Code Question

Heena opened by pointing out that the industry has spent the past few years answering whether AI can generate code. That question is settled, and it is no longer what enterprises are asking.

The question now is whether a system can be built around AI-generated code that an organisation can actually trust. That reframing shaped the whole session.

She was explicit that the panel would not be about one magical autonomous agent. It would be about what agents need around them: context, governance, permissions, and a way to tell whether the code being produced is improving outcomes for the engineering team and the wider business.

Each panelist works on a different layer of that stack. Qodo focuses on code review and code governance, acting as the adversarial counterpart to coding agents and reporting on software health and technical debt. Faros AI connects AI sessions to engineering artifacts and then to company strategic initiatives. Moderne gives agents a deterministic set of tools grounded in a compiler-accurate model of the codebase.

The Bottleneck Moved to Trust

Asked what broke first as AI-generated code scaled, Chase traced the pattern back to 2022, when the interaction was a browser tab and ChatGPT. Adoption moved into the enterprise over the following year and a half without a framework attached to it.

The instruction was effectively to use the tool, with no accompanying answer on how to use it well. In his reading, that missing process is the origin of the problems teams are working through now, and the question is only being asked properly at this point.

Patrick described the same period differently. AI did not remove the bottleneck in the software development lifecycle; it relocated it from writing code to trusting code.

Writing accelerated to the speed of AI, and the cost reappeared as a human tax on code review. The code arriving is often almost right, so cycle time has not dropped and the effort has shifted downstream into reviewing, testing, and validation.

He listed the knock-on effects as technical debt, developer satisfaction, and a widened surface for security problems.

Judgment Spills Downstream

Itamar named human judgment as the umbrella problem that follows once the coding part is nominally solved, and framed the challenge as using that judgment well without burning out senior developers.

He also answered an audience question about what the AI SDLC means. Producing an outcome is not only writing code; it is carrying a customer need or a vision through to something in the customer’s hands, and code is one part of that.

His observation about where judgment used to live is the part worth sitting with. Product managers wrote specs and did their best, but a great deal of real judgment happened while the code was being written.

Delegate that to a coding agent, which teams should do, and the judgment does not disappear. It spills somewhere else, and it lands largely on senior developers, amplified because more code is now arriving for them to consider.

The Dark Factory, Worked Backwards

Heena grounded the next question in enterprise reality: thousands of engineers, thousands of codebases across many repositories, a mix of coding assistants already in use, plus legacy code, existing CI/CD pipelines, security requirements, and compliance obligations.

Itamar answered by looking three years out to what some call the dark factory. The input is a description of the software you want and the output is the software, with the interior treated as a black box as long as the request comes out the other side.

He was direct that the industry is not there, and that enterprises in the setup Heena described are very far from it. His argument is to hold that picture in view and build backwards from it.

One way to work backwards is to start from your most capable engineer and ask what that person does to carry work end to end. The answer involves tribal knowledge:

• What worked and what did not - the accumulated record of approaches the organisation has already tried.
• How code is maintained here - the conventions that make a change fit this codebase rather than a generic one.
• How new features are communicated - including the configuration a new feature needs, which he noted is easy to overlook.

Automating those elements as deterministically as possible turns some of them into infrastructure. That is where the context lake comes in, holding not just knowledge but the experience an organisation has accumulated.

Code as Data

Patrick argued that models and coding assistants are the two components the market has handed teams, while the full architecture needs several more substrates underneath.

His starting point is an analogy to the editor. Developers needed editors to read code, so the question becomes how agents read code, and today they read it as characters and letters.

That matters because the codebase is the most valuable dataset an enterprise owns. His team approaches it the way a biologist would, treating the codebase as a genome and sequencing it so an agent can query it rather than scan it.

The payoff is fidelity. When the agent sees what the compiler sees, it finds things more reliably, frames them more accurately, and fixes them better.

Context, Guardrails, and Verification

Chase agreed that context is the deciding factor and gave the audience three things to build.

• A company context lake - so agents exploring a problem space have the organisation’s context available, whether that is CRM data or engineering artifacts.
• Guardrails - a mesh layer over the agent, so a change made in one place surfaces the ripples it causes elsewhere. He was candid that the work is never perfect when the pull request opens.
• A verification space - a browser, a database, or wherever verification belongs, so the agent can loop until the work is ready to become a pull request.

He then raised a structural gap. The SDLC is a well-understood framework with established engineering artifacts, while AI sessions currently live outside it, inside a model provider’s systems.

Pulling that usage back into the traditional SDLC is what makes it modellable, letting teams ask what-if questions and probe results. Agents emit rich metadata through telemetry events and proxies, so the connective tissue exists.

Determinism at Scale

Patrick drew the line between where probabilistic work suits the job and where it stops scaling. Open-ended reasoning and planning are a good fit, with a developer in the loop and retries available, and that holds for a single repository.

Run the same pattern across thousands of services and non-determinism compounds. His illustration was a 92 percent success rate, which leaves an 8 percent failure rate whose location nobody can point to, and customers operating at that scale describe it as a trust issue.

His conclusion is that the agent’s job should be reaching the tool rather than being the tool, with the tool itself deterministic and trustworthy. At Moderne that takes the form of recipes built on the compiler, unit tested, and inspected against the resulting diffs.

Chase added the sequencing that has to come first. Observe, then optimise, then govern, and the observation step carries its own difficulty.

When he asks teams whether they know what outcomes their agents are producing in terms the company cares about, the answer is largely no. Teams can report token spend for the month, which is a different question entirely.

Itamar made the case that determinism is a matter of reducing variance rather than eliminating it. Humans are probabilistic too, and still ship working software, because processes, guardrails, checks, and measurement narrow the range of outcomes.

His method is decomposition. Break the lifecycle into small components and attach specific workflows to each, noting that code review alone is not one task but hundreds of subtasks: verifying against intent, against architecture, against issues seen in production, and against the documentation.

He also flagged the elephant in the room. Automating the current SDLC is the sensible move, but it optimises toward a local minimum, and it is worth occasionally asking whether the lifecycle should look entirely different.

From Token Maxing to Outcome Maxing

Heena noted that engineering organisations currently measure AI impact through licence utilisation or the percentage of code that is AI-generated, and observed that an agent can consume billions of tokens and produce nothing useful.

Chase’s answer starts from what a company already records. Strategic initiatives live in a project management platform as epics and tasks, and the industry has long since learned to connect engineering work to them by attaching a ticket.

The move is to extend that chain by one link, connecting AI work into engineering artifacts and through to the initiatives themselves. Once the chain holds, the question about an engineer’s session changes from whether they spent a lot of tokens to whether those tokens went toward something the company cares about.

Patrick reached for the factory metaphor to make the same point. Tokens, licences, and AI-generated code volume are what the factory consumes, the equivalent of its electricity bill.

What deserves measurement is what lands: the changes that merge, stay merged, and stay in production, as against the small changes that came and went. He also asked how AI has affected the human side that frameworks such as SPACE and DORA were built to measure.

Itamar offered an equation, with everything that makes a team happy on the numerator and everything that does not on the denominator. Token maxing, in that structure, puts tokens on top and nothing meaningful underneath.

Borrowing the framing of The Phoenix Project, features and infrastructure that let a team move fast belong on the numerator, while bugs, incidents, firefighting, AI cost, and human cost belong on the denominator. Track those six over time and the trend gives a usable read on return.

Drawing the Autonomy Line

Heena put the closing question plainly. The dark factory vision has agents writing, reviewing, testing, deploying, and repairing software with the human largely absent, which she described as far from ground reality and mildly terrifying to hear in a bank.

Patrick’s answer was that software will remain a team sport between humans and agents, and that autonomy is really a question of positioning. He is comfortable where an agent leans on already-tested tools rather than writing novel code, so that pulling on a component yields something trustworthy and a reviewable diff.

In that formulation the agent plans, queries, and reaches for tools, and the change lands as a pull request with human logic still in the path. The agent does not have to do everything; it can be the thing pressing the buttons.

Chase was blunt that using AI well today is hands-on steering rather than set-and-forget, and encouraged teams to treat their own comfort level as the thing to discover.

His concrete example is a review panel of agents that runs on every pull request his team opens. Senior engineers encoded their tribal knowledge into each panel member, and every review carries a risk level.

For the low-severity pull requests, that review cycle is automated, which is where their comfort sits today. Another organisation might draw the line at medium risk, or decline to draw it at all.

He added a point about team composition that cut against the usual advice. Not everyone needs to be fully AI-mature, and the pull between skeptics and AI-forward engineers is what keeps an organisation sane while it still moves faster than it did before.

Q & A Session

Audience questions ran through the chat during the session, and the panelists picked them up as they went. These are the ones that drew the most direct answers.

• What does the AI SDLC actually mean?

  Itamar: It is the software development lifecycle reconsidered for AI, sometimes called the agentic SDLC. Producing an outcome is not just writing code; it is taking a customer need or a vision and putting the result in the customer’s hands. Once coding is delegated to an agent, the judgment that used to happen during coding moves elsewhere, which is why code review and quality workflows matter more than they did.

• How do you measure quality when the term is this broad?

  Itamar: Break it down. Quality decomposes into testability, maintainability, compliance, stability, scalability, and related properties, roughly nine groups, each carrying policies. Some policies are global and some are specific to an organisation, and AI can accumulate the scars and experiments behind the specific ones. Score the result and watch the drift over time rather than trying to define quality in one stroke.

• Greenfield or brownfield, where should an enterprise start?

  Itamar: The more useful question is which part of the codebase supports a high-confidence verification loop. If you can stand up an environment close to production with full coverage across tests, compliance, and functionality, you end up with a report that tells you whether to trust the change. Greenfield has the advantage of being built that way from the start, but many organisations have compartmentalised areas that already verify well because they were built for humans, who are probabilistic too.

Itamar closed with a challenge drawn from conversations with financial institutions, several of whom believe the large majority of human code review at their organisations adds little. His point was not to settle that claim but to use it: where humans are already performing poorly, an autonomous agent has a lower bar to clear and a clearer case to make.

This panel was part of Testμ Conf 2026, which ran across three days of sessions on agentic engineering and quality. Registrations for the next edition are already open on the Testμ Conference 2027 page.