TL;DR: We built a software factory to automate mechanical work across the SDLC. Over eight months, size-adjusted output per developer grew 4.5× while merge times and revert rates fell. We added agents wherever work was piling up, rather than automating in lifecycle order, and kept engineers responsible for product decisions, architecture, and production risk.
By November 2025, AI was already writing nearly 100% of Augment's new code. But producing code is not the same as shipping reliable software. As coding accelerates, the bottleneck moves to other parts of the SDLC: review, verification, planning, incident response, or feedback resolution.
A software factory solves this bottleneck by moving engineering work faster between requirements, tickets, pull requests, and production (read more about the software-factory model). Specialized agents automate the mechanical work at each transition while humans retain ownership of consequential decisions. We built ours on Augment Cosmos, our platform for running and coordinating agents. We added each component as a new bottleneck appeared.
Between November 2025 and July 2026, across all of Augment engineering:
- Size-adjusted output per active developer increased from 12.3 to 55.7: 4.5×.
- Raw pull requests per active developer increased from 16.6 to 45.5: 2.7×.
- Lines changed per active developer increased from 8,031 to 35,147: 4.4×.
- Median time to merge fell from 11.2 hours to 3.1 hours: 72% lower.
- The 14-day revert rate fell from 1.9% to 0.4%: 79% lower.
The gains emerged over time as we incrementally expanded automation beyond code generation to planning, review, verification, feedback, and operations.
How work moves through Augment's software factory
By the beginning of August, our software factory spanned four connected states of engineering work: Requirements, Ticket, PR, and Prod. Our factory loops connect Linear for tickets, GitHub for pull requests, Slack for product feedback, and Slack + PagerDuty for incident response. Specialized agents operated on the transitions between those states, automating the mechanical work required to move ideas forward while preserving human ownership of consequential decisions. Once a PR is merged, our existing deterministic deployment pipeline carries the change to production. We did not automate these transitions in lifecycle order;we started wherever work accumulated. Our operating loop was simple: find the bottleneck, automate it, and repeat.
| Workflow | Trigger | Agents | Output | Human role / gate |
|---|---|---|---|---|
| Requirements → Ticket | Feature description | Project Builder | Codebase-grounded design doc and work split up into tickets | Iterate with Project Builder on product requirements and architecture decisions; approve the design |
| Ticket → PR | Ticket assigned to Cosmos; or task description pasted in session | PR Author, Ticket Manager | Draft PR and fixes for CI failures, conflicts, and review comments | Review spec if needed; review auto-fixes on PR |
| PR → Prod | Opened or updated PR | Risk Analyzer, Deep Reviewer, Pair Reviewer; Verifier | Risk Analyzer auto-approves low-risk PRs; Deep Reviewer posts comments for objective bugs; Pair Reviewer creates Design & Architecture report; Verifier generates runtime evidence (screenshots, logs, etc.) from E2E testing | Review Design & Architecture report, review Verifier evidence, and make the final merge decision |
| Prod → Ticket | Product feedback, or PagerDuty alert | Feedback Triager; Incident Investigator | Evidence-backed RCA, ticket, and remediation recommendations | Review RCA and approve remediation action (i.e., code fix, rollback, or escalation) |
What changed as the factory grew
Before we introduced these agent workflows, our engineers already used interactive AI coding agents in their IDEs and CLIs, along with a legacy AI code-review engine. The major shift was from individually operated tools to persistent, team-wide agent workflows that owned work across systems and involved humans only at defined judgment points.
The PR-to-production loop makes the difference concrete. Previously, a typical PR required roughly 10–15 human touchpoints: a reviewer asking an agent to explain the PR, an author prompting it to fix CI failures, prompting it to fix review comments, configuring a test environment, manually exercising the feature, repeatedly reviewing updates, etc. By the beginning of August, the automated review workflow reduced that to three primary touchpoints: review the Pair Reviewer's design-and-architecture report, inspect Verifier's runtime evidence, and make the final merge decision. It also replaced bespoke developer workflows with a standardized review process.
This reduced active human handling per PR. Over the same period, median time to merge fell from 11.2 to 3.1 hours, while the 14-day revert rate fell from 1.9% to 0.4%.
The factory accumulated over nine months:
- November 2025: Augment gained access to Claude Opus 4.5 and deployed its legacy AI code-review bot. Engineers used interactive IDE and CLI coding agents for almost 100% of all new code.
- January 2026: Cosmos was released internally (interactive use only); automation and orchestration primitives still being built.
- February: We launched PR Author and the initial code-review fleet.
- April: After tuning and improving the fleet through March and April, code-review agents reached engineering-wide adoption.
- May: We deployed Incident Investigator to investigate production alerts before humans arrived.
- June: We deployed Project Builder to accelerate planning, design, and execution of large projects.
- July: We deployed Feedback Triager and Verifier, closing more of the feedback and runtime-verification loops.
The analysis below shows our productivity and quality metrics on 17,200 merged pull requests across all of Augment engineering from November 2025 through July 2026. We generated this report using the Cosmos ROI Analyst, a read-only agent that retrieves merged-PR activity from GitHub, identifies reverts, and computes throughput, cycle-time, quality, and complexity-weighted output metrics.
Output per developer increased 4.5×
Raw pull requests per active developer increased 2.7×, from 16.6 to 45.5. Because PR counts alone can be distorted by changes in PR size, we constructed a size-adjusted output index to test whether the increase was explained by splitting work into smaller PRs. The index weights each PR using changed files and lines changed, with caps to limit the influence of extreme changes.
That measure increased from 12.3 to 55.7 effective pull requests per active developer: 4.5×. Lines changed per active developer increased by a similar 4.4×, providing an additional, though noisier, signal.
The review system absorbed the additional volume
Median time from pull-request creation to merge fell from 11.2 hours to 3.1 hours, a reduction of 72%, even as output per developer increased 4.5×. This reduction is critical from a developer's standpoint. Long merge-times result in long review backlogs, and a developer could be multi-tasking with 20 open PRs in parallel, which quickly gets overwhelming for most of us; bugs can sit unfixed for days or weeks. A short merge-time (like 3 hours) ensures that a developer is only handling a couple of open PRs at a time, and bug fixes land in hours.
The measured quality signal improved
The percentage of pull requests reverted within 14 days fell from 1.9% to 0.4%. Revert rate is not a complete measure of quality (many defects are fixed forward or discovered later), but it provides a consistent signal that higher output and faster merging were not accompanied by more immediate rollbacks.
These figures are a longitudinal case study, not a controlled experiment. November included access to Opus 4.5 (the first model we found reliable enough to complete routine engineering tasks end to end) and deployment of our legacy review bot. Models continued to improve, but we did not see another comparable step change during the study period. Adoption, workflows, and work mix also evolved, so the milestones show what we built and when—not the causal contribution of each component.
What the trend does show is that output continued to increase as automation expanded beyond code generation into planning, review, verification, feedback, and operations.
The Engineering Leader's Guide to Building a Software Factory
How software teams move from individual coding agents to team-level software delivery.
What we learned
Follow bottlenecks, not lifecycle order
The deployment order followed the bottlenecks we encountered, not the order of the software lifecycle. We started with automating code review because our review backlog was growing rapidly in January. Similarly, we automated feedback triaging only when our Slack feedback channels started to consume too much developer time.
Throughput increases only when the whole system can absorb the work
Increasing code production alone would have created a larger review queue. The important result was not simply that PRs per developer increased. It was that size-adjusted output rose while median merge time and the measured revert rate fell.
We came to treat accumulated work as inventory. A growing queue at any stage—tickets awaiting implementation, PRs awaiting review, changes awaiting verification, or feedback awaiting investigation—showed us where the next investment belonged.
Agents need the same evidence and environments as engineers
Repository access was not enough. Our agents became more useful when they could work with CI, test environments, logs, metrics, tickets, documentation, deployment state, and the operational procedures encoded in skills and runbooks.
That was especially important for Verifier and Incident Investigator. Their value came from gathering inspectable runtime evidence, not from producing plausible explanations based only on code.
Preserve human ownership of judgment
We did not design the factory for total autonomy. Like new engineers, agents do not always have the organizational context needed to choose between multiple reasonable designs. Repository guidelines and product specifications can narrow that gap, but novel problems still require human judgment. We therefore designed each workflow to automate mechanical work while preserving human ownership.
Agents come up with architecture choices, gather evidence, perform repetitive analysis, implement approved work, run and fix tests, and resolve mechanical feedback. Engineers make product and architecture decisions, evaluate ambiguous tradeoffs, approve production risk, and remain accountable for the systems after deployment.
Adoption follows deployment
Deploying an agent did not instantly change engineering behavior. Teams needed time to understand its strengths, inspect its evidence, correct its behavior, and trust it with longer-running work. We also had to tune each agent based on feedback to ensure it had the right guardrails, authentication, and configuration for each team's unique workflows. Some of the measurable effect therefore appeared weeks after the corresponding deployment milestone.
The factory is still evolving
We started in November with IDE and CLI coding agents, access to a stronger model, and a legacy AI review bot. By the beginning of August, specialized agents operated across planning, implementation, review, verification, feedback, and incident response.
No single agent or model release explains the 4.5× increase in size-adjusted output per developer. The change coincided with repeatedly identifying where engineering work was waiting and building the next component needed to move it through the system.
The factory did not remove engineers from software development. It moved their attention away from repetitive investigation and execution and toward decisions, ownership, and learning. Our goal is simple: keep increasing engineering velocity while holding the quality bar constant.
If you're building your own factory, start where work is piling up. You can try Cosmos with one workflow and expand as it proves useful.
Written by
Akshay Utture
Akshay Utture builds intelligent agents that make software development faster, safer, and more reliable. At Augment Code, he leads the engineering behind the company’s AI Code Review agent, bringing research-grade program analysis and modern GenAI techniques together to automate one of the most time-consuming parts of the SDLC. Before Augment, Akshay spent several years at Uber advancing automated code review and repair systems, and conducted research across AWS’s Automated Reasoning Group, Google’s Android Static Analysis team, and UCLA. His work sits at the intersection of AI, software engineering, and programming-language theory.