The engineering team at a Fortune 500 industrial manufacturing company was not looking for a headline metric when they began their agentic development workflow initiative in early 2025. They were looking for a way to clear a backlog that had grown to over 1,200 open issues across their internal tooling portfolio—a portfolio that four engineers were responsible for maintaining alongside feature development for a platform used by 14,000 employees globally.
Twelve months later, that same four-person team had cleared the backlog, shipped a major platform version, and reduced their mean time to resolution on maintenance issues from 18 days to 4.2 days. The figure that surfaced in internal presentations—a 300% increase in engineering velocity for maintenance work—is the kind of number that tends to get laundered through marketing before it reaches the public. In this case, the underlying methodology is worth examining in detail.
The Problem: Maintenance as a Velocity Killer
Software maintenance work is the least glamorous category of engineering output and the most consequential for organizational function. Dependency updates, bug fixes, performance regressions, compatibility patches, and internal API migrations do not generate new capabilities—they preserve existing ones. But neglecting them creates compounding technical debt that eventually makes feature development impossible.
For a small team maintaining a large internal platform, the calculus is brutal. Every hour spent on a dependency update is an hour not spent on the product roadmap. And dependency updates, unlike feature work, are not negotiable—they are required for security compliance, and failing to keep up with them creates vulnerabilities that a company of this size cannot tolerate.
The team's backlog was not a failure of engineering competence. It was a structural mismatch between the volume of necessary maintenance work and the human hours available to perform it.
The Agent Architecture
The solution they built over four months was not a single AI system but a pipeline of specialized agents, each responsible for a discrete class of maintenance work.
The Triage Agent monitors the issue tracker, ingests new bug reports and dependency alerts, and produces a structured classification: severity, likely root cause category, estimated complexity, and a confidence score. This agent runs continuously and updates the backlog in real time. The critical design decision here was to make the triage agent's outputs transparent and auditable—engineers can see exactly why a ticket was classified at a given priority level and can override the classification with a single action. Trust in the system required that it never feel like a black box.
The Dependency Resolution Agent handles the category of work that previously consumed the most calendar time without requiring much intellectual effort: identifying outdated dependencies, determining compatible version ranges, generating the update, running the test suite, and either auto-merging (for low-risk updates that pass all checks) or creating a PR with a structured description of the changes and test results for engineer review.
This agent operates against a curated policy file that defines which packages are safe for autonomous update and which require human review regardless of test results. Security-critical dependencies and packages with major version changes always route to human review. Patch updates to well-tested internal packages are merged automatically after CI passes.
The Investigation Agent takes the most complex step: given a confirmed bug report with reproduction steps, it attempts to identify the root cause by tracing execution paths through the codebase, correlating the failure with recent changes via git history analysis, and generating a hypothesis. For approximately 60% of bugs in their portfolio, the investigation agent's hypothesis was accurate enough to serve as the starting point for a fix rather than requiring the engineer to re-derive the analysis from scratch.
The PR Generation Agent—the component most directly analogous to Neumar's Linear ticket-to-PR pipeline—takes an approved fix plan and produces a complete pull request: the code change itself, unit tests for the new behavior, documentation updates where relevant, and a PR description formatted for the team's review conventions. The quality of the generated PRs was the metric that surprised the team most: reviewers reported spending less time understanding what a PR did and more time evaluating whether it did the right thing, which is where human judgment should be concentrated.
The Linear Pipeline Parallel
The pipeline this team built independently mirrors the architectural pattern that Neumar's Linear integration formalizes. The insight in both cases is the same: the path from "identified problem" to "merged fix" involves a sequence of steps—triage, investigation, implementation, testing, documentation, review preparation—most of which can be automated without compromising the quality of the final output, provided the human remains in the loop at the decision points that require organizational context or judgment calls.
Neumar's two-phase execution model—plan, then execute—maps directly to this structure. The agent presents its interpretation of the task and its intended approach before taking action. The engineer approves, modifies, or rejects the plan. Only then does execution begin. This is not a UX nicety—it is what makes autonomous operation safe enough to trust with production-affecting changes.
What the 300% Figure Actually Means
The velocity gain is real, but its composition matters. It is not uniformly distributed across all types of engineering work.
| Task Category | Velocity Gain | Agent Role | Engineer Time |
|---|---|---|---|
| Dependency management | 600-700% | End-to-end autonomous | 15-30 min review |
| Routine bug fixes (clear repro) | 600-700% | End-to-end autonomous | 15-30 min review |
| Complex architectural bugs | 40-60% | Assists with root cause hypothesis | Engineer leads implementation |
| Aggregate (all ticket types) | 300% | Mixed | Varies |
For dependency management and routine bug fixes with clear reproduction cases, the actual throughput increase was closer to 600-700%. These tasks, which previously required an engineer to context-switch, investigate, implement, test, and document, can now be handled end-to-end by agents with fifteen to thirty minutes of engineer review time replacing what previously took one to three days of elapsed calendar time.
For complex architectural bugs—the ones that require understanding system behavior across multiple services, reasoning about race conditions, or investigating performance regressions with non-obvious causes—the agents provide meaningful assistance but do not autonomously resolve the issue. The investigation agent's root cause hypothesis is useful, but an engineer still leads the implementation. In this category, the velocity gain was approximately 40-60%: still substantial, but far from autonomous.
The 300% aggregate figure averages across the full distribution of ticket types. It is honest because the team measured across their complete backlog rather than cherry-picking the categories where automation performs best.
Adoption Friction and What Overcame It
The non-technical challenges were significant. Three of the four engineers on the team had initial reservations about deploying agents with any level of autonomous merge authority. The concern was not irrational—a bad automated merge to a platform used by 14,000 people is a serious incident.
What resolved the skepticism was not an argument about AI capability. It was the rollout structure: the auto-merge policy began with a list of exactly twelve packages that had a two-year history of clean automated updates, comprehensive test coverage, and no significant downstream dependencies. Over three months, engineers could observe the agent's behavior on a contained set of cases before the policy expanded.
By month four, the team had enough empirical data to extend the auto-merge policy with confidence. The trust was earned through demonstrated behavior, not assumed from capability claims.
Implications for Engineering Teams
The most important lesson from this deployment is not about the technology. It is about the work design. The team that succeeded here did not start by asking "what can we automate?" They started by asking "what are the most valuable ways an engineer's time could be spent, and what could take everything else off their plate?"
The answer was: engineers should spend time on architectural decisions, complex bug investigations, code review judgment, and user-facing feature development. Everything else—the procedural, the repetitive, the well-specified—should be routed through agents.
That framing produces a different set of agent designs than starting from "what is technically automatable." It produces agents that are optimized for creating reviewer confidence rather than minimizing engineer involvement, because the goal is not maximum automation—it is maximum useful engineering output.
That distinction is why the PR generation agent was designed to produce verbose, well-documented pull requests rather than minimal diffs. The agent is not trying to make itself invisible. It is trying to make the engineer's review as productive as possible.