The software factory has stopped being a slide-deck abstraction and started running inside real engineering orgs, often without anyone naming it. That shift is what brought three practitioners together for The Great Software Factory Debate, a LinearB roundtable that aired as an episode of the Dev Interrupted podcast: Dexter Horthy, CEO and co-founder of HumanLayer, which builds a multiplayer coding agent workspace; Aloke Desai, Founding Engineer and Head of Product Engineering at Warp; and Dan Lines, co-founder and COO at LinearB. Between them they span the orchestration layer, the factory infrastructure, and the measurement framework that leaders now lean on.
Each has spent years closer to this problem than most. Desai has been building agents at Warp for six years and now spends his time helping companies build factories that demonstrate ROI. Lines works with CTOs and VPs of engineering every day, helping them turn a board-level AI mandate into measurable delivery outcomes, and brings the benchmark data LinearB gathers across engineering orgs to show what a mature software factory actually looks like. Horthy solves hard problems in complex codebases, hundreds of repos and hundreds of engineers deep, while pushing to keep humans installed at the right high-leverage points. What follows is their shared map of where the factory works, where it breaks, and what still belongs to people.
The software factory is already running inside your SDLC
Most teams are already automating slices of the SDLC, from code generation through review, even if they never call it a factory. The gap between orgs is wide. Lines sees everything from teams with nothing formalized to teams running a defined pipeline end to end, even though the terminology itself has been around for fifty or sixty years.
That history matters. The term borrows from physical manufacturing and predates AI by decades. What forces leaders to formalize it now is the maturing AI development lifecycle, or ADLC, and the pressure to intentionally shape a process that agents have already begun to reshape on their own.
The building blocks are arriving fast. HumanLayer's workspace is an orchestration layer with room to bring your own compute, harness, and dev environment. Warp takes a different angle with an opinionated default factory that lives in code, one teams can extend with their own agents, skills, and models. The common thread is a system with defined stations, not a black box.
Measuring software factory success starts with business outcomes
Every factory, regardless of domain, optimizes for two things. In Desai's framing, the test is whether you can measure and demonstrate that throughput is rising while cost per item holds or falls. Throughput is how much product ships. Cost per item is what it costs to build, which in software ultimately means cost per PR. Those are the top-line numbers, but the downstream proxies tend to tell the sharper story.
The business rarely asks about tokens. It asks whether customers are getting more value, faster. "Are you delivering customer value on time more often than you were before?" That is where Lines starts with engineering leaders under pressure to answer for AI investment. Predictable delivery and capacity give leaders something to hand back to a non-technical executive before drilling into factory-level indicators.
Measuring true customer outcomes is hard, and the teams doing it well are cleaning up. GitLab is the model here, handing engineers customer problems instead of tickets and refusing to count lines of code as progress. Horthy is candid about the hierarchy that follows when outcomes are out of reach. When you can't measure outcomes, you measure feature ships. When you can't measure those, throughput, then lines of code, then tokens spent.
That descent is the tokenmaxxing trap. Tokens are the easiest rung to grab and the least meaningful, yet many orgs latch onto them and never climb toward successful outputs and real business impact. The lesson echoes The Goal, Eliyahu Goldratt's classic on factory optimization, where MBAs tuned individual stations while overall throughput stagnated. Software adds a harder wrinkle. A car leaves the factory and stops affecting future work, but every code change compounds forever. Ship sloppy code today and it taxes every change you make for months until you fix it.
Dark factory ambitions need night vision to actually work
The phrase "dark factory" comes straight from manufacturing, where it describes a plant so automated it can run with the lights off because no human needs to be on the floor. Companies once bragged about it. The instinct to chase the same badge in software, more autonomy, fewer lights, is understandable, and mostly wrong.
The better goal is visibility. "I think it's about having night vision," Lines says. Everything runs in the dark, but you can still see. You monitor quality, you catch slop before it spreads, and when an incident hits production you feed that context back so the agents change behavior in real time. Horthy has already shipped a skill that distills a diff into human-readable snippets and diagrams, because you cannot outsource the understanding of your own codebase.
Autonomy, not darkness, is the honest signal. Warp tracks an 80% autonomy score, meaning a human never has to step in and commit code for 80% of the work flowing through. That is a more valuable number than dark for the sake of dark, because the point was never the absence of humans. It was high-quality product, which still depends on humans standing in the right places.
Code ownership in the age of AI still belongs to humans
Agentic PRs do not dissolve accountability, and the data shows what happens when orgs pretend otherwise. LinearB's benchmark report found that only 37% of agentic PRs get merged in organizations classified as less mature in the ADLC. A number that low usually means nobody knows who owns the PR, who the reviewer is, or whose agent produced it in the first place.
The fix is intentionality. The best leaders decide on an ownership plan, automate assignment by codebase area or feature, and apply risk-based governance so a documentation-only change never consumes the same human attention as a high-risk one. Desai's read is that humans still own PRs, full stop. A software factory is not a fully dark pipeline from issue to merge. An agent that recognizes it needs a spec, or assigns a PR to a human, is a feature, not a bug.
Framing changes everything about how engineers receive this. Cast them as developer productivity engineers who maintain and improve the factory, and ownership becomes energizing rather than a demoralizing spray of context-free PRs. Horthy lands in the same place, that every piece of work needs a human owner. The alternative is engineers slinging slop and shifting the real work of producing good software onto senior reviewers, who burn out and leave for teams that still care about craft.
Cost per PR and throughput metrics reveal factory health
If throughput and cost are the universal factory metrics, cost per PR is where they meet in software. It is the number that translates AI spend into something a factory operator can actually manage.
Leading indicators expose whether the investment works. Lines's list starts with cost per effective PR merge, then merge rate per developer, rework rate, and assisted PR rate. Raw throughput without quality checks is a trap, since it just accelerates bad code into future rework. A PR that needs heavy rework quietly costs more than the work it was meant to replace.
PR maturity is the metric on the rise, tracking how many back-and-forths a PR needs before it merges. A mature PR arrives in good shape. An immature one burns more time in review than the feature was worth, and that hidden cost is exactly what tokenmaxxing lets teams ignore. Quality matters again, now that generating code is the easy part.
Agentic PR review bottlenecks signal too many bad PRs
The most common complaint in this new world is volume, and it almost always masks a quality problem. In Horthy's words, "Everyone who says, 'Oh, we have too many PRs. We have to solve the too many PRs problem,' is like you probably don't have too many PRs." Reviewers are not drowning in quantity. They are drowning in low-effort, high-rework output.
The distinction is emotional as much as technical. "If you have this as a pain point, you probably have too many bad PRs because a good PR is a joy to review," Horthy adds. A PR needing under 5% rework reads cleanly, follows the agreed patterns, and heads off the corners agents love to cut. A bad one carries a burden for both reviewer and submitter, the dread of telling someone their polished work is not actually done.
Some teams change the incentive instead of fighting the symptom. Several San Francisco CTOs built tight auto-merge gates, where a change that avoids sensitive code areas, stays under a size threshold, and passes checks needs no review at all. Behavior shifted immediately. Engineers stopped lobbing oversized, low-effort PRs and started shaping small, low-risk ones to qualify, and volume climbed for the right reasons. The gate has to respect where code lives. Deeper, more core code, often strongly typed and harder to change, demands stricter human review, while higher, cheaper-to-change layers can tolerate more autonomy as ADLC maturity grows. Front-end work is not automatically safe territory either, since agents still struggle to reason over tangled render logic like React's useEffect.
Trust decides how far the factory runs on its own
The through-line across every part of this conversation is trust, and where it runs thin. Teams gate hardest wherever they are most afraid, which starts at PR merges and eventually moves to incident management and the top-of-funnel question of what to build at all. Night vision, human owners, and honest metrics are what let leaders extend autonomy without losing the plot, because the factory only compounds value when someone can still see what it is compounding.
None of that shrinks the role of the engineer. It raises it, toward systems thinking, product ownership, and the hard-won intuition no model has learned to replicate. The factory handles the stations. People decide what the factory is for, and whether what comes off the line is any good.
Dexter Horthy, Aloke Desai, and Dan Lines go further on all of this, from measuring factory success to dark factories versus night vision to code ownership in the age of AI, on the full episode of the Dev Interrupted podcast.
