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.
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 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 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
- Provides automated on-call incident response
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.
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%.
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. 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.
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 read the traces and database, find the 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, 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 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.
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.
- 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. We hate vendor lock-in. 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 Gumloop 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 Gumloop 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.
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.
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 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.
How Factory PRs merged, by week
- Human edits
- Automated fixes
- Clean
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%.
Skills written or edited vs. PRs with no human edits
- Skills written or edited · 94
- PRs with no human edits · 89%
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.