I keep seeing the phrase “software factory” come back into conversations about agentic engineering. I even mentioned it in my latest talk at We Are Developers World Congress in Berlin (July 2026).

I fear that a shallow interpretation of this can fester in the developer ecosystem:

More agents.
More loops.
More automation.
More code.

That rhetoric or result shouldn’t be the goal. A factory should not be solely defined by how much it produces at scale. A factory is defined by the ability to garner trust by engineers leveraging it.

And in software, trust should not come from throughput alone. It can come from quality control at scale.

The software factory idea has history. Jack Greenfield and Kieth Short were writing about software factories years before the current agentic engineering discourse. CMU SEI’s work on software product lines framed it around shared core assets, prescribed production methods, managed variation, and systematic reuse.

The history of software factories, in my opinion, was meant to set the tone for how we can approach software factories for agentic engineering. And so it's clear from those sources that software factories are not about generating as much as we can at scale.

In a classic problem-solution-oriented strategy, I like to start with a question. And a question powers how to approach execution, definitions, and goals:

Can we capture production knowledge so software can be built more consistently?

Instead of patterns, frameworks, models, and generators alone, we now have agents, harnesses, skills, context systems, CI gates, review automation, and automated feedback loops.

But the engineering challenge is still the same. And it's one that powers the work I do in developer relations:

Can the production system preserve code quality as code output increases?

The inner loop asks:

Can the agent quickly discover whether its code works?

This is where local validation lives: tests, type checks, linters, IDE feedback, repo-specific rules, and fast review signals.

The outer loop asks:

Can the organization determine whether this change is safe to merge, deploy, operate, and defend?

This is where pull request review, CI, integration testing, cross-repo impact, security checks, compliance, release readiness, and production observability matter.

But the meta-loop is something I have been thinking about lately and want to define around a question as well.

The meta-loop asks:

Can failures from today improve the system tomorrow?

This is where I believe agentic engineering becomes systematic, organizational learning.

This is why deterministic quality gates matter so much. A factory without quality gates can build more problems and technical debt at scale.

A coding agent can reason, explain, and sound extremely confident. It can even revise itself. But if nothing in the system can stop it when you would stop yourself, then the loop is still too lenient. Not every part of agentic engineering should be stochastic.

Some things should be strictly enforced gates:

LLMs are useful for reasoning through ambiguity. And deterministic gates make the system enforceable.

Guidance = a coding rule that only lives in your agent prompts.

Governance = a rule that can block a merge.

This is where I get nervous about some software factory conversations.

If “software factory” becomes a synonym for “agents doing everything,” we will recreate the many problems at a larger scale.

In fact, agentic systems can expose the mess faster. If your tickets are vague, your tests are thin, your review standards are implicit, and your architecture boundaries are undocumented, agents will not magically make the system more mature.

They’ll run into the same weak points humans already work around. And most likely, this will happen faster than ever.

Here’s how I’d explain a useful software factory:

A controlled system.

Context that tells agents what matters.

Inner loop that catches local mistakes early.

Outer loop that protects the organization from unsafe changes.

Meta-loop that turns repeated failures into durable controls.

That is the part I want to see practitioners to focus on. The future of agentic engineering should be measured by whether teams can still understand, verify, maintain, and stand behind what gets shipped.

While everyone may not be reading every line of code in the future, extremely strict parameters for what gets through into production and what fails and needs to be retried until success are a way we're seeing more and more practitioners build trust in the systems they're engineering.

Sources