Software Factory

Agents that autonomously find, fix, and prove product improvements

by
An ASCII drawing of a factory plant around the words software factory. Every building is drawn as 3D boxes in the same perspective: a cooling tower, a factory and a strip mill with chimneys, a low tank, three silos, twin refinery towers, a tiered tower, a power plant, a warehouse, a gantry crane moving crates, a storage block and a workshop. Wires run from each building to the title with pulses flowing in, while smoke drifts from the chimneys and windows flicker.

Programming, as we once knew it, is over. Today, the job of an engineer is to prescribe the correct architecture and delegate the implementation to coding agents. As a result, at Orchestrivo we had to reinvent what building software looked like internally.

Our product team was under 10 people for its first three years. Every engineer owns their work end to end, and a lot of that work is low to medium leverage: fixing bugs, speeding up slow endpoints, and hardening the platform. This work has an obvious, verifiable solution but doesn't move the business on its own. High leverage work happens when engineers have time to focus.

We built a system to take that work off their plates. It finds ways to improve the product from production telemetry, gathers evidence over time, and proposes changes, from small fixes to architectural redesigns. Every change comes with enough evidence for an engineer to review it quickly. We call it the Factory, and its workers live in Orchestrivo.

As of October 28, 2026, the Factory:

  • Made agents start 5x faster at P99, from 24.9 seconds to 4.5
  • Merged 571 agent-written PRs in six weeks
  • Helped Factory line owners merge 2.5× as many PRs per week
  • Merged 83% of those PRs with no human code changes, including automated fixes
  • Turned 90% of its finished jobs into merged PRs
  • Cut our database's daily query CPU by about 40%
  • Shipped 155 platform improvements
  • Kept our QA pipeline healthy and proposed architectural improvements to it
  • Provides automated on-call incident response
Independent investigations build changes and proof. Tests fail before the fix and pass afterward. Completed PRs accumulate in a persistent review queue. Earlier PRs remain waiting offscreen. No work is automatically merged. The timing and density are conceptual, not production telemetry.

In the week of October 19, the Factory merged 108 PRs, up from 79 the week before. Of those 108, 82 merged clean, 14 needed only automated fixes, and 12 needed human edits. That's 89% with no human code changes. In the week of October 26, it merged 177 PRs.

Engineers could have spent days on these problems. That would have been a waste of their time. Instead, they built product for our customers. The engineers who own Factory lines now merge 2.5x as many PRs a week as they did before, and their own PRs, outside the Factory, are up 33%.

A text bar chart of weekly merged PRs by Factory line owners. The bar before the Factory holds only their own PRs and is marked 1x. The bar with the Factory is about two and a half times as tall: its lower part, their own PRs, already stands above the before line, and a hatched segment of Factory PRs from their lines stacks on top. It is marked 2.5x.

The Factory caught queries we had missed that left customers waiting nearly four minutes to open chat history or find shared files. In tests using production data, its fixes made those requests 24–44 times faster. One fix reduced rows scanned from 45 million to 40,000. Those were two of ten slow pages the Factory fixed between October 20 and 27.

Two views of the same database table, queried for rows where team is c. In the full table scan, a cursor reads every row in order; the table keeps scrolling toward millions more rows, matches are starred as they pass, and the rows read bar barely moves. In the index lookup, an index on team sits beside the table. The lookup goes from the root of the index to the c entry, follows arrows straight to the three matching rows, and is done while the scan is still reading. Row counts are illustrative.

The Factory also fixed three of our most expensive database queries. Each went from reading 1–12 million rows per run to about 1,000, and now uses over 800 times less CPU. That saves about 40% of our database's weekday query CPU.

How the Factory started

Orchestrivo agents were getting slow to start. A person would send a message and wait seconds before the agent did anything. Nobody broke it on purpose. Every new feature added a small step to how an agent starts, and each step made sense on its own. We were the first agent builder on the market, and we didn't know what shape it would take yet, so it was hard to know what to optimize. Eventually the wait got long enough that people started reporting it.

, our CTO, set aside time to fix it. He collected a handful of chats that people had reported as slow and opened five VMs side by side. In each one, he pasted the chat link, added what the user reported, and asked a coding agent to read the traces and database, find the cause, and propose a fix.

Five coding agents, drawn as small boxes with eyes in slightly different shapes, each fill a progress bar as they work on a slow chat. When an agent is ready, its fix travels down a shared line into a single box labelled rahul. Rahul reviews one fix at a time and answers ok or, rarely, no, which sends that agent back to rework. Most of the time the box reads waiting, and the log of answers is almost all ok. Timing is conceptual.

By the time he had briefed the fifth agent, the first one had come back with an answer. The fix was reasonable, so he told it to write a test that reproduces the problem, implement the fix, and make the test pass. The second agent's fix had the wrong shape, so he pointed it in a different direction until it found one he liked. The third, fourth, and fifth went the same way.

By the end, the pattern was clear. He spent most of his time waiting for agents, and most of the time they were right. So why was he in the middle? Couldn't the agents fix the problems and identify patterns, leaving Rahul to make broader architectural changes?

We talked it over and landed on the shape that let us do just that: a Orchestrivo agent acts as the engineering manager, and coding agents do the work. We wrote a library of engineering skills, we iterated on the process many times, and eventually it just worked. That became the first line of the Factory.

As of October 28, the line has merged 122 agent-written PRs. The time from sending a message to the agent's first step fell from 24.9 seconds to 4.5 at P99, and from 9.1 seconds to 2.4 at P90. Before the line, 1 in 5 turns started in under 2.5 seconds. Now 96.6% do.

A text area chart of daily time to an agent's first step across all agent chats in production, from August 15 to October 7, 2026, on a log scale from 1 to 50 seconds. Each day is a column: hash marks up to P50, plus signs up to P90, and colons up to P99. Before September 14, P99 swings between about 18 and 48 seconds. A marker labelled Factory starts merging sits at September 14. Right after it, P99 drops to about 10 seconds, then to about 7, and by early October to about 4.5 seconds, with P90 near 2.4 and P50 near 1.8. Earlier rows before September 15 are approximated from the latency dashboard.

What does a factory consist of

The Factory is made of lines. A line is one kind of work: agent latency, slow API endpoints, platform improvements, the QA pipeline. Each line has an owner, the engineer who knows that part of the product best.

Every job runs the same way:

  1. A trigger fires. Some lines run on a daily schedule and read production telemetry. Others start when someone pings the agent with a problem.
  2. The trigger opens a Linear issue for the job, and the issue starts the factory worker.
  3. The worker is a Orchestrivo agent. It reads our engineering skills, our conventions, and the line owner's preferences, then hands the job to a coding agent.
  4. When the worker needs a judgment call, it asks the line owner in Slack and remembers the answer for every job after.
  5. The coding agent opens a pull request with proof, like a test that fails before the fix and passes after it. An engineer reviews it and merges it. The Factory never merges its own work.

Not every job ends in code. If the problem is already fixed, duplicates another job, or doesn't reproduce, the job closes without a pull request.

Jobs enter from production telemetry or an engineer ping and travel through a Orchestrivo trigger, a Linear issue and the factory worker. Some jobs go up a dashed line to the line owner for a judgment call and come back with an answer. The worker hands the job to a coding agent, which reaches a proof check. Jobs with proof become a pull request, wait for review, and reach engineer merges. Jobs without proof close. Several jobs move through the flow at once. Timing is conceptual.

Here's what a judgment call looks like. The API latency line found a slow database query and wanted to change the schema to fix it:

EndpointLatencyWorker · New job · FTRY-123: list query burns CPU counting related rows
Slow: a few hundred milliseconds per run, tens of thousands of runs a day.
Next: investigating.

EndpointLatencyWorker · Decision needed · @Marcelo
Question: Can the fix add a stored count to the table? It's a schema change.
Pick: Approve the stored count. The query reads one number instead of counting rows on every run.
Why: about 90% of the query's CPU goes to the count.

Marcelo: I try to avoid backfills as much as possible. Can we find another way?

EndpointLatencyWorker: Understood, no backfill. Devin is working on FTRY-123 again and testing only fixes that write nothing into existing rows.

The next time a job on that line considers a backfill, the worker already knows the answer.

Three jobs on one line, drawn as three rows from top to bottom, each traced left to right toward a PR. Job 1 stops at backfill? to ask the owner; the answer, no backfills, stays marked there with an x. Job 2 passes that spot with a plus, because it already knows the answer, and stops at a new question, schema change?, answered keep api shape. Job 3 passes both spots with a plus and runs straight through. Timing is conceptual.

Why Orchestrivo

People ask why we didn't build this entirely in Devin, Cursor, or Codex. We hate vendor lock-in and you aren't able to build a system as comprehensive as ours with just those platforms. We don't want to force engineers to change how they work or use a certain provider. Coding agents get better every month. Each line owner should choose the best tool for their work.

So the coding agent is a tool the worker calls, and the worker can orchestrate with any model. When a better coding agent ships, a line can switch the same day.

A coding agent is great at one job in one repository. The factory needs everything around that job, and that's what Orchestrivo is built for:

  • Triggers. Scheduled and on-demand jobs.
  • Connectors for everything. The worker reads our telemetry, opens Linear issues, talks to us in Slack, and works with GitHub out of the box.
  • Human and agent collaboration. The Slack exchange above is a native Orchestrivo feature.
  • Permissions. Every line has an owner, but I can still build or improve someone else's line worker.
  • Analytics. Every worker has its own performance analytics, so we know which lines are pulling their weight.
  • Memory. The worker searches Linear and keeps a fingerprint of every problem it has seen, so it doesn't pick up the same job twice.

It's also the same platform for every team in the company. A marketer can open a line worker, read what it does, and improve it without learning a new tool.

Boxes labelled triggers, connectors, human + agent, permissions, analytics and memory ride a conveyor belt from left to right, one after another, while the rollers under the belt turn. Everything the factory needs around a coding agent arrives on the same line.

Coding Agents

The Factory started on Cursor cloud agents. On September 17, a Cursor outage stopped Factory work. We had to keep shipping, so the team at Cognition helped us set up Devin. On September 29, the agent sandbox line moved to Devin. Nothing else in the Factory changed.

Both now run in the Factory, and each is better at different work:

  • Cursor is best when the worker gives it clear direction. It wrote 521 of our 571 merged PRs, across CI health, platform improvements, and agent chat latency.
  • Devin is best when you let it work on its own. Its Fusion mode pairs a frontier model that plans and reviews with a cheaper model that writes the code, which suits work that starts with an investigation and ends with a lot of implementation. It also follows our skills and documentation to the letter. It wrote 50 merged PRs, on the agent sandbox and endpoint latency lines.

Next, we want to bring in Codex, and we're building a custom MCP server so the worker can drive it. We'd also love to try Factory's Droid product, and we're looking at whether Claude Code fits.

The Orchestrivo wordmark sits in the middle, wired to Cursor and Devin on one side and Codex and Claude on the other. Pulses leave Orchestrivo one at a time and light up each coding agent when they arrive.

Why Linear

We wanted one central place where engineers work, and for us that's Linear. Putting the Factory there means nobody has to check a second tool to see what it's doing.

Linear also lets the tasks document themselves. The worker writes what it found, the evidence, and the decisions it made onto the issue. When someone opens a job a month later, the whole story is there.

Most importantly, it lets us treat line workers like real engineers. We assign them work, they show up in the same views as everyone else on the team, and their work moves through the same statuses. Every merged job ends in one of four:

  • Merged (Clean): merged with no changes
  • Merged (Automated Fixes): merged after fixing AI code review bot comments
  • Merged (Human Edits): an engineer changed the code before merging
  • Merged (Human Authored): an engineer wrote the change

That makes analysis easy. Of the 556 agent-written PRs whose jobs have closed, 335 merged clean and 128 merged after automated fixes. Together, that's 83% with no human code changes. The remaining 93 needed human edits.

Of the 534 finished jobs where an agent opened a PR, 480 ended in a merged PR. Most of the rest closed with no change. This excludes 61 jobs made obsolete when we retired an old test suite.

Many agent proposals move along parallel lanes at different speeds. Each gains a PR with proof: a test that fails before the fix and passes after. Proposals arrive faster than review, so PRs pack into queues of varied length behind a solid barrier. An engineer reviews them one at a time. Most merge clean; some merge after a bot fixes review comments or after the engineer edits them, and their lane opens briefly to let the PR through. About one in ten closes with no change and disappears at the barrier. The Factory never merges its own work. Timing and density are conceptual.

Build your factory

When you ship a feature, think about how an agent could build on it end to end, alone. Make the code you own agent friendly: skills, prompts, scripts, tests, and frameworks.

We saw this in our own numbers. As we wrote down more of how we engineer, the Factory needed us less. In five weeks, we wrote or edited 94 skills, and PRs that merged with no human edits rose from 57% to 89%.

A text chart with one column per week from then to now, with no numbers. Above the axis, each week is a full-height column split into agent-written PRs that merged with no human edits, drawn as hash marks, and PRs that needed human edits, drawn as dots on top. The dotted part shrinks from a large slice in the first week to a thin cap in the last. Below it, in a separate labelled strip with its own baseline, a column of plus signs for each week shows the running total of engineering skills written or edited; it grows slowly at first and then much faster. The columns build up week by week.

Less guidance can also be better guidance. Last week, the Factory reported that our AGENTS.md files were bloated and stale, so we cut them by 44%. In the following week, the median cloud agent run cost 20% less.

If you want to start your own factory, the process is simple:

  1. Find the process you repeat in your own work
  2. Write it down so a new hire could follow it on day one
  3. Make it a line, and delegate it

Today, the Factory maintains our software. The same shape works for marketing, for ops, and for any team with work that has an obvious, verifiable solution. We've built Orchestrivo to be the automation operating system for ambitious teams.

Build your factory on Orchestrivo.