How Goblins' small engineering team merges 5x more pull requests with Capy
Watch the video2:42- a week, with the same small team
- 5x more merged PRs
- built or reviewed by Capy
- 98% of merged PRs
- by Capy on Goblins pull requests
- 14,000+ reviews
“The engineering culture changed at Goblins once we adopted Capy, we just ship way more.”
Goblins merges 300+ pull requests a week, five times what it merged before Capy, with the same small engineering team. Its engineers used to spend most of their time writing code. Now they spend most of it reviewing what Capy built.
Goblins lets students speak and draw to learn math. A teacher uploads a photo and a voice recording, and Goblins builds an avatar of them. In class, each of the 30 or so students works with that avatar, which gives feedback on every problem, while the real teacher walks the room and helps the students who need it. Goblins serves students, teachers and the district administrators who roll it out, and it works with some of the largest school districts in the US. Alp Karavil is the co-founder and CTO, and Matt Reed is a founding engineer.
The laptop set the limit
Once coding models could handle several work streams at once, Goblins' engineers ran them side by side on their laptops, and the laptops ran out of memory. Upgrading to 64 GB MacBooks didn't fix it. Matt, on a 32 GB machine in a large monorepo, topped out at two or three agents, and he carried his laptop around the office half open so they wouldn't stop running.
To fit more work onto one machine, Matt ran all his agents on a single branch and sorted their commits onto separate branches by hand. The team also spent a few weeks trying to build cloud development environments in-house. Those kept going down, and when they did, the work in them was lost.
With so few agents, the team had to pick a focus. Goblins was getting more bug reports as it grew, and time spent on bugs was time the product didn't move.
Every agent got its own machine
Capy runs each agent on its own cloud machine with Goblins' app running inside it, so the number of agents no longer depends on anyone's laptop. The team moved long-running backend work first, where an agent could write the tests, make them pass and open a pull request. Work that needed a human eye, like getting an animation to feel right, stayed on the laptop.
Front-end work followed once Capy could check its own: it tests the change in a browser against the Figma mock and attaches a video to the pull request. Today Goblins hands Capy basically all of its full-stack work, from infra and security to front end and back end. Matt can give a hard bug his full attention while Capy builds a feature in parallel.
Capy drives each pull request to merge-ready
After a pull request opens, Capy stays on it through failing checks, merge conflicts and review comments. Engineers stop shepherding pull requests and define them instead: what done looks like, and how to test it. They can now leave a nitpick without a second thought, because Capy picks up the comment, makes the fix and runs the tests again. The team still leaves its comments on GitHub, and Alp gets a Slack message when a pull request is ready.
One GPU now runs two copies of the avatar model
Goblins hosts its own open-source diffusion model for the live teacher avatars. As built, one A100 GPU could run only one copy in real time, which wasn't enough for the number of students on Goblins. Matt asked Capy to try any variation of the model it wanted. Capy ran the experiments on separate machines and found a version that just fits two real-time generations on one GPU. Matt says that would have taken much longer on his laptop.
Five times the pull requests, with the same small team
From September 10 to October 10, 2026, Capy opened or pushed to 1,252 of the pull requests Goblins merged, and reviewed 1,171.
The bottleneck moved to review
A person still reads every pull request before it merges, so more pull requests meant more to read.
“It used to be the case that we were writing code 90% of the time, reviewing code 10% of the time. … Now we spend 90% of our time reviewing code.”
Capy review checks whether each function does what it claims, so the engineers spend their review time on product sense, code hygiene and how a change will hit their infrastructure. Alp says the team tried several review tools, and Capy review was the least noisy and the one that understood Goblins' product context. Capy has run more than 14,000 reviews on Goblins pull requests through October 10, 2026. Every few hours it also posts the open pull requests to Slack, ranked by which to review first.
Once a day, a scheduled Capy check reads everything merged since the last run together. It catches risks no single review can, such as three stacked pull requests that are each fine alone but expose something together. Goblins handles student data, which is why Alp calls this the most valuable automation the team has built.
Bug reports become fixes without pulling an engineer off their work
When a teacher writes in because a student can't log in, someone on the product team asks Capy about it in Slack. Capy reads Goblins' session replays, errors, logs and traces, finds what went wrong for that one student, and proposes a fix. Matt says it gets there on its own nine times out of ten. An engineer reviews the fix and merges it.
The engineers wouldn't have had time for this before. Debugging one student's problem meant dropping their own work in the middle of the day.
“Oh, you just reported this bug this morning? We just shipped a fix like an hour after you reported it.”
Alp says that speed surprises teachers, because an edtech vendor usually won't even respond, and when one does, the fix can take months or never come.
Capy runs across the company
People outside engineering bring their questions to Capy in Slack. They ask how the app or the code works without going through an engineer. When someone has a product idea or needs a deeper data analysis, they prompt Capy, and it posts its work back in the thread with images and video of what it built. Most people never leave Slack or open a coding tool. When the result is right, an engineer reviews it and takes it to merge.
Scheduled Capy runs work for the business side too. A weekly market report checks the news, Goblins' CRM and its sales data. When Goblins has just made a sale in a state that announced a new grant, the report suggests mentioning the grant and that customer to other prospects in the state.
“If Capy disappeared tomorrow, I think our product and sales team would be really unhappy because they rely on all this work that is done for them because of the productivity boost that Capy provides for the whole company, and especially engineering team.”
Building fast is satisfying again
Matt is one of the engineers who liked writing code. When coding agents arrived, he used them to keep up and found them frustrating. Capy was the first time working that way felt satisfying.
“I would miss the satisfaction of just building fast.”
How to run a small team on agents
- Run more work streams than feels comfortable. Alp's advice is to start more agents than you think you can drive, then notice where you get overwhelmed and why.
- Let the agent own the pull request. Once an agent handles checks, conflicts and review comments, the only thing left to judge is the finished pull request.
- Give it read-only access to your debugging data. Capy reads Goblins' replays, errors, logs and traces, and it can't change the database.
- Put recurring checks on a schedule. A daily security pass over merged work catches what single reviews miss.
Run as many agents as you have work for
Capy takes each pull request through CI, merge conflicts, and review.
