Software Factory
Agents that autonomously find, fix, and prove product improvements
Programming, as we once knew it, is over. At a high-growth startup, an engineer spending their time programming is a poor business decision. Today, the job of an engineer is to prescribe the correct architecture and delegate the implementation to coding agents. The best engineers today are prolific in this regard.
Our product team at Gumloop 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 is work with an obvious, verifiable solution that doesn't move the business on its own. The high leverage work, the work that pushes the business and the product forward, happens when engineers can find the time to sit down and focus.
We believe our engineers should be doing high leverage work exclusively, so we built a system that takes the low to medium leverage 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 that an engineer can review it quickly, and an engineer always merges it. We call it the Factory, and its workers live in Gumloop.
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
- 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
Factory PRs merged per week
- Platform improvements
- Other lines
- Endpoint latency
- CI health
- Agent chat latency
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. This week, it merged 107 PRs by Wednesday. These counts include only PRs written by coding agents.
An engineer could have done any of this work if they sat down and focused for a few days. We think that would have been a waste of their time. The engineers who would have spent those days on these problems built product for our customers instead. 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%.
Weekly merged PRs by Factory line owners
- Factory PRs from their lines
- Their own PRs
The Factory caught queries we had missed that left customers waiting nearly four minutes to open chat history or find shared files. Its fixes made those requests 24–44 times faster in controlled replays against production data, cutting the waits to 5–10 seconds. One fix reduced rows scanned from 45 million to 40,000. An engineer reviewed and merged both fixes. Those were two of ten slow pages the Factory fixed between October 20 and 27.
Time to load, before and after the fix
- Before
- After
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.
Database CPU for three queries the Factory fixed
How the Factory started
Gumloop 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.
Rahul Behal, 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 investigate: read the traces, read the database, find the conditions that make the agent slow to start, find the root cause, and propose a fix.
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, he noticed what most of the work had been. Once an agent had enough information about the cause, the right fix was usually easy to see. He spent most of his time waiting for agents to respond, and most of the time they were right. So why was he the one in the middle? Shouldn't the agent just fix these problems and identify the themes, so Rahul could make a broader design change when necessary to prevent similar bugs from ever arising again?
We talked it over and landed on the shape that let us do just that: a Gumloop 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.
Time to an agent's first step
What the Factory is
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. A job is one problem on a line. Jobs run side by side, and each one gets its own branch.
Every job runs the same way:
- A trigger fires. Some lines run on a daily schedule and read production telemetry. Others start when someone pings the agent with a problem.
- The trigger opens a Linear issue for the job, and the issue starts the factory worker.
- The worker is a Gumloop agent. It reads our engineering skills, our conventions, and the line owner's preferences, then hands the job to a coding agent. Each line uses the coding agent its owner prefers, today Cursor or Devin.
- When the worker needs a judgment call, it asks the line owner in Slack and remembers the answer for every job after.
- 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.
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.
Why Gumloop
People ask why we didn't build this entirely in Devin, Cursor, or Codex. Truthfully, we hate vendor lock-in. We don't want to force an engineer to change the way they work, or to use a certain provider. Coding agents get better every month, and the best one today might not be the best one next month. The best should win, and the person responsible for overseeing the work should decide which one that is.
So the coding agent is a tool the worker calls. Each line owner picks Cursor or Devin, and the worker can orchestrate with any model. When a better coding agent ships, a line can switch the same day. Swap the tool, and the factory keeps running.
A coding agent is great at one job in one repository. The factory needs everything around that job, and that's what Gumloop is built for:
- Triggers. A line can run on a schedule, or start when someone pings it.
- 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 thread above is a native Gumloop feature. The worker asks, the owner answers, and the worker remembers.
- 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. Honestly, we don't think about it much. It just works.
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. More on that below.
Cursor and Devin
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, because the coding agent is just a tool the worker calls.
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.
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 meta 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. It's just a good form factor for engineering.
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.
How Factory PRs merged, by week
- Human edits
- Automated fixes
- Clean
Build your factory
The job of an engineer is changing. When you ship a feature, your job is to think about how an agent could build on it end to end, alone. Your job is to 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%.
Skills written or edited vs. PRs with no human edits
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:
- Find the process you repeat in your own work
- Write it down so a new hire could follow it on day one
- 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 Gumloop to be the automation operating system for ambitious teams. We want every department to have a factory. This is the future of work, and Gumloop is built for it.