You Want a Software Factory? Ready Your Repositories First.

Most software-factory pitches start with the agent. Pick a model. Add an orchestrator. Have it open pull requests while a small team watches the work. But that sequence is backward.

The factory is not the model. The factory is the repository and delivery system that can give the model context, constrain its authority, verify its work, recover from mistakes, and measure whether the change helped anyone.

The distinction matters because the evidence is mixed, which is exactly what a serious engineering leader should expect. DORA's 2025 research drew on nearly 5,000 technology professionals and more than 100 hours of qualitative data. Ninety percent reported using artificial intelligence at work, and more than 80% believed it improved their productivity. Yet 30% reported little or no trust in AI-generated code. Adoption alone isn't the signal. What matters is whether the delivery system can turn that use into trustworthy change.

Don't wait for some abstract state of repository perfection before using agents. Give them bounded work now. Then invest in the specific missing control that keeps an agent, reviewer, or operator from knowing whether a change worked. That's how a repository earns more consequential autonomy.

The agent is not the factory

Vendor guidance is settling around the same practical lesson. OpenAI's Codex guidance describes durable repository instructions with scoped overrides. Its implementation guidance asks teams to spell out run, build, test, lint, pull-request, constraint, and done criteria. For its coding agent, GitHub recommends well-scoped issues, acceptance criteria, file directions, and simpler starting tasks. Anthropic's Claude Code GitHub Actions documentation also treats project rules and review criteria as repository material rather than tribal knowledge.

None of those documents proves that writing an instruction file will make a company ship better software. They establish a more basic point. An agent can't reliably contribute if it has to reconstruct the environment, hunt for the relevant contracts, guess the validation command, and work out who owns a risky path. The common pattern is repository legibility.

So the conversation should start with the system that controls implementation, not the model that produces a patch. A model can generate code in an empty directory. A software factory has to turn a request into a bounded change, assess it, release it, observe it, and learn from it, then do all of that again. The repository is where those habits become executable.

DORA supplies the missing standard of proof

DORA's research gives this argument a useful constraint. Its 2025 findings describe AI as an amplifier of the delivery system already in place, shaped by testing, version control, feedback loops, architecture, platforms, workflows, policy, and accessible data, as the report announcement explains. In a healthy system, faster iteration can become learning. In a weak one, the same speed can produce a longer review queue, noisier releases, and work that looks productive right up until it reaches operations.

Earlier evidence makes the caution concrete. DORA's generative-AI report found that a 25% increase in AI adoption was associated with a 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability. Those figures are associations, not a universal forecast. They support a warning that teams can generate code faster than the organization can remove the constraints waiting downstream.

The current tension will sound familiar to anyone reviewing AI-generated work. DORA's analysis of developer experience and AI describes time saved during generation moving into prompting, auditing, and reviewer load. That's the verification tax in human terms. The work doesn't disappear. It changes hands and shape, and leadership can lose sight of it by counting pull requests instead of outcomes.

This is why commits, generated lines, and pull-request volume aren't value metrics. DORA's measurement-framework guidance distinguishes activity logs from the broader interpretation needed to understand delivery performance. Its current delivery-performance model uses five measures across throughput and instability. An agent program needs that outcome lens, along with visibility into verification burden and user or operational outcomes.

Ready the repository in the order work can fail

A repository doesn't need a grand maturity score. It needs evidence that it can support the proposed class of work. The practical sequence is admit, execute, verify, recover, and learn. This is an article synthesis from DORA's delivery findings and the repository patterns vendors document. It is not an official DORA model, certification, or composite score.

1. Admit work with a reproducible environment and a real task boundary

Start with the cold path. From a fresh clone, a new contributor or agent should be able to install dependencies, start the required services, build the project, and run the relevant check without relying on an undocumented ritual. Write down the exact commands your repository already supports. Don't invent a generic command vocabulary for the agent. GitHub documents a repository setup workflow for making build, test, and validation steps reproducible for its coding agent. If a clean environment can't establish the baseline, every later claim of successful agent work is borrowing confidence from one person's laptop.

Next, make the task bounded enough to evaluate. A usable task brief names the outcome, the included and excluded paths, the acceptance criteria, the relevant context, the owner to consult, the permitted actions, the risk, and the recovery plan. It also names the command or observation that can prove the work is done. “Fix onboarding” makes an agent invent the boundaries. A useful task gives it a falsifiable claim to test. That's where quality assurance becomes the control system rather than a late-stage inspection queue.

2. Execute with legible context and constrained authority

Put stable repository guidance where people and agents can find it. Codex can load repository-wide and scoped AGENTS.md instructions. GitHub supports repository-wide, path-specific, and nearest-file instructions. These features aren't interchangeable standards, and ordinary documentation still matters. In practice, a useful instruction file answers four plain questions: where do I start, which command proves this change, which paths need special handling, and who must review them. Keep the path-specific rule beside the sensitive path, not buried in a handbook.

While that evidence is still immature, constrain what the agent can do. Claude Code's security guidance describes read-only defaults and sandbox boundaries. It also makes clear that people remain responsible for reviewing commands and code. OpenAI's approval and security guidance reaches the same practical point from another direction: the workflow owns the authorization boundary, not a model that sounds confident.

Routine documentation, isolated tests, and low-risk maintenance can earn a narrow implementation and pull-request path early. Keep authentication, payments, schema changes, regulated data, destructive infrastructure, and high-blast-radius integrations plan-first or explicitly supervised. The boundary should follow reversibility and consequence, not vendor branding.

3. Verify in the same system that will decide whether to merge

A green check matters only when it represents meaningful evidence. DORA's continuous-integration guidance emphasizes frequent integration and fast feedback. Its test-automation guidance treats automation as one part of a broader quality system, not a substitute for human exploratory work. The practical target is parity between local and continuous-integration checks. The command an agent runs should be the command the shared branch trusts.

Build verification in layers. Begin with fast formatting, static, and focused behavior checks. Add contract, integration, performance, and end-to-end checks when the risk calls for them. Keep the feedback path clear enough that a failure tells an agent or reviewer where to look next. A slow, flaky, or opaque pipeline turns cheap code generation into expensive uncertainty.

Every consequential agent pull request should carry an evidence package: intended outcome, changed scope, commands run, results, risk considered, deployment or migration implications, rollback path, and unresolved uncertainty. That is the reviewer's receipt. It should let someone who did not prompt the agent see what changed and decide whether the evidence is enough. GitHub is explicit that Copilot code review is supplemental. It doesn't satisfy required approvals or block merges. Treat every automated review the same way. It's useful evidence, not delegated accountability.

4. Recover before you accelerate

Small batches and frequent integration aren't process nostalgia. They make cause and effect easier to read. Compared with a broad autonomous renovation, a narrow change gives reviewers and operators a clearer story as they test, release, observe, and reverse it. DORA's AI findings identify mature version control and fast feedback loops as important control systems for AI-assisted development, as its 2025 announcement summarizes.

Before an agent acts independently on a task class, know how you'll contain a bad result. For the first task in a class, write the recovery move before the agent starts: feature flag, staged rollout, preview environment, revert path, or a human approval step. Then make sure someone can actually use it. A system isn't closed-loop merely because it can deploy. It earns that name only when it can connect a signal to a bounded action, preserve the evidence, observe the result, and stop or reverse the action if the result degrades.

5. Learn by turning recurring failure into executable control

The useful flywheel isn't code generation feeding deployment feeding more code generation. It starts when a review comment, flaky test, failed migration, or incident becomes a stronger condition on the next attempt. Make a recurring missing test a required check. Turn a prohibited dependency into a policy rule. Protect an unsafe path. When a release is opaque, write the runbook and test the rollback. The point is to leave the repository easier to operate than it was before the agent touched it.

That's how teams can use the amplifier effect deliberately. The mechanism that magnifies weak habits can compound strong ones when teams convert evidence into shared infrastructure. It also keeps the human role where it belongs: deciding which trade-offs are acceptable, which risks require escalation, and which outcomes are worth optimizing.

What leaders should measure

Measure the delivery system, not agent theater. Pair DORA's throughput and instability measures with review rework, validation failures, test reliability, rollback frequency, time to restore service, security interventions, and the user or business result attached to the change. Then read those measures together. A rise in deployment frequency might indicate healthier small-batch delivery, or it might reveal uncontrolled churn. More tests could mean stronger behavioral coverage, or a slower, flakier suite.

Ask one hard question: can you explain whether the last increase in agent-generated pull requests improved delivery, or merely moved work into review and recovery?

Expect an adjustment period. The DORA evidence doesn't support calling agent adoption a failure because verification work appears early. Nor does it support calling the effort successful because code appears quickly. The decision is empirical: can the team increase useful delivery without worsening stability, recovery, human rework, security outcomes, or the experience of the people the software serves?

Build the factory where the work actually happens

You don't need to buy another agent platform to start. Pick one low-risk task class. Make its cold path work. Write the task brief, put the local rules beside the work, and make the same command pass locally and in continuous integration. Require a review receipt. Practice the recovery move. Then look at what happened after the merge before granting the next slice of authority.

Then repeat. A repository earns broader autonomy when those controls hold up under real work. This is slower than treating a model demo as a factory launch. It's also how a software factory becomes something more valuable than a machine for producing code: a human-led system for producing verified, recoverable, useful change.