The engineer’s guide to building a software factory

Estimated reading time: 7 minutes

Key takeaways:

• Individual agents plateau at 20-30% gains, not the 2-3x teams expect.
• The fix is to use multi-agent loops with separated objectives, not one agent checklisting.
• Three loops lead: PR→merge, Ticket→PR, Alert→resolution, each with major measured gains.

---

In conversations with hundreds of engineering leaders, I keep hearing the same pattern. Teams went in expecting coding agents to make them 2-3x more productive. What they actually see at the org level is more like 20-30%, which is real, but not what anyone was promised.

The reason is that individual adoption changes one engineer’s workflow, not the team’s delivery system. Code gets written faster, but it still moves through the same review queues, the same planning cycles, the same deployment process.

I’ve been calling this the productivity plateau, and step-function gains only come when everything around the code speeds up too.

The vision: a software factory

Speeding up everything around the code means a system that works at the level of the team, one that coordinates humans, agents, context, tools, verification, and feedback across the whole delivery process.

Individual coding agents can’t supply that, however good they get. Each one starts from zero and stops at the edge of its own task. It has no memory of the last run and no interest in what happens after it hands off.

I call that system a software factory. I know the word makes some engineers flinch, so let me be clear about what I mean. A factory isn’t about volume, and it’s definitely not about slop. It’s instrumented, repeatable, quality-gated production: throughput measured in outcomes, issues caught by the process, and skilled people spending their time on the highest-leverage judgment calls.

Nobody builds one in one go. You build it one production line at a time.

Production lines are agentic loops

Each production line is an agentic loop. It takes a recurring job in the software development lifecycle and handles it end to end. A bug report comes in and a merged fix goes out. A vulnerability gets flagged and it closes. Agents do the repetitive work in the middle, humans step in at the moments that actually need them, and every run leaves the loop better set up for the next one.

The thing people get wrong about loops is picturing one agent working through a checklist. In practice it’s several agents, each with its own objective, tools, and acceptance criteria. One assesses the risk of a change. One does the work. One tries to find fault with it. One decides whether a human needs to see it.

That separation is what makes the output trustworthy. An agent grading its own work will pass its own work, every time. Give each agent a different objective and every stage has something checking it that wants a different result. It’s the same reason you don’t let engineers approve their own PRs.

Connect enough of these loops and you stop managing agents one at a time.

Three loops to start with

Across the engineering organizations we work with, the same three loops keep showing up first. The order varies, but the pattern is remarkably consistent, and the reason is usually the same: teams pick whatever hurts most, build a loop around it, and what they learn reshapes how they scope the next one.

1. PR → merge

This is the loop most teams need first. When agents write more code, PR volume rises and the constraint becomes confidence. We hit that wall ourselves with 1,400+ PRs open and median time to first human comment around 20 hours.

The loop starts when a PR opens and ends at a verified merge. A risk analyzer routes the change, auto-approving low-risk PRs and tagging higher-risk ones for human input. A deep reviewer checks correctness line by line: is there an objective bug? A PR fixer repairs findings, CI failures, and merge conflicts, so most issues resolve without another human round-trip. A verifier deploys to an isolated instance, exercises the affected behavior, and posts inspectable proof – logs, screenshots, a replayable trace. An intent reviewer asks whether the change makes sense in the broader system and surfaces the decisions that need human judgment. A memory manager distills the feedback into per-repo knowledge every agent reads next run.

Result: 66% faster time to merge.

2. Ticket → PR

Once review is moving, the constraint shifts upstream. The bottleneck is rarely code generation – it’s specification, dependency discovery, testing, and coordination.

This loop starts when a ticket is assigned and ends with a merge-ready PR. A planner grounds the ticket in the actual codebase (affected files, dependencies, constraints) and produces a spec a human can review before implementation starts. A code author implements against the approved spec with repo context and shared memory. A test author generates and runs tests, catching regressions before the PR opens. A compliance checker validates against team-defined policies. An intent reviewer looks at the spec before implementation and the PR before merge. Then the loop hands off to PR → merge.

Result: a five-feature epic that took a senior engineer about a week finished in 3.5 hours, including an hour waiting for human review.

3. Alert → resolution

On-call time goes mostly to reconstructing context: moving between PagerDuty, Slack, dashboards, and logs to work out what broke.

This loop starts when an alert fires and ends at a verified resolution. An incident investigator gathers evidence from logs, metrics, recent deploys, and code, then posts an RCA with a recommended remediation before a human has looked. A PR author creates the fix when one is needed and hands it to the review loop. A rollback agent reverts problematic deployments when that’s faster. An escalation router finds the right service owner when the issue is outside agent scope. An intent reviewer scans the RCA, asks follow-ups, and keeps production-impacting calls with people. A memory manager captures operational learnings so the next investigation starts with more context.

Result: across five on-call channels, agents handled 81.3% of incidents (up from 0.4%), median time to first RCA fell from 30.1 to 6.2 minutes, and on-call engineers merged 44% more PRs per week.

The stack underneath

Individual loops solve individual problems. What turns them into a factory is a shared foundation that every loop builds on and contributes back to:

• Orchestration. The control plane that decides which agent runs next, passes context between stages, handles failures, and enforces sequencing. Tuning loop behavior should feel like editing a specification, not shipping a feature.
• Cloud runtime and isolated environments. Virtual machines with real dev tooling where agents can check out, build, deploy, and test – each run isolated so concurrent work doesn’t interfere.
• Access to context. Code, tickets, logs, metrics, deploy history, standards, runbooks. Every input an agent can’t reach is a class of problem it can’t solve.
• Event-based triggers. Loops start from events and should pause until a human approves, a CI check passes, or a dependent loop finishes. This is what makes human-in-the-loop control practical at scale.
• Shared memory. A correction in review improves future authoring. An incident pattern speeds up the next diagnosis. Without it, each loop operates in isolation and the factory never compounds.
• Model routing. No single model is best at every task. Route each one appropriately, swap providers as the market moves, make cost-quality tradeoffs visible.
• Governance and auditability. Scoped permissions, audit trails, enforced human-in-the-loop rules. Governance is what lets leaders trust the system enough to widen the autonomy.

What it looks like in practice

Pearl Technologies runs an engineering team of over 100 people building a transportation management system. Before Cosmos, moving a ticket to a production-ready PR meant manual story writing, local environment setup, and repetitive unit testing, and knowledge transfer needed a scheduled call or a written handoff.

They rebuilt around cloud-run loops connected to their existing systems. Cosmos integrates with Azure DevOps through webhooks, and the loop writes user stories from high-level instructions, generates code, handles unit testing, and opens PRs. Workspace segregation separated front-end, back-end, and DevOps contexts, and session sharing let one developer hand a full working context to a teammate.

In a four-day baseline window in early April, the team completed zero PRs. In the 13 working days after adopting Cosmos, they completed 728. Complex migrations that had spanned multiple days began completing same-day. Efficiency climbed from 3.2 to 4.7 PRs per session over three weeks. Pearl reports the overall change as a 3x productivity gain.

Start today

The productivity plateau breaks when you stop optimizing individual engineers and start optimizing the system they work in.

Pick the place where work waits longest in your organization. Build a loop around it. That’s your starting point, and every loop you add after compounds on the same foundation.

Build your first loop with Cosmos →

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.