Billogram's factory opened about 1,100 PRs in eight weeks, and an 85-day ticket fixed in ten minutes still took 22 days to ship

Lezgin Zilan writes up the software factory at Billogram, a Stockholm payments company with about 40 engineers. A Jira ticket or Slack message goes in, a cloud coding agent does the work, and a PR comes out. It never merges on its own: another agent reviews it, then the person who asked, then a developer merges. From 31 August to 22 October the factory opened about 1,100 PRs. About 40% were right the first time, about 50% needed rework that the factory pushed itself after a reviewer tagged it with feedback, and about 10% were closed, usually because the ticket was a poor fit or under-specified. The busiest week had 245 sessions and 219 merged PRs.

Two engineers spent about six days building the core by hand. After that the factory mostly built itself: 596 of 639 merged PRs in its own two repositories were factory-opened. A retro pass after each run files improvement tickets, and when a PR merges an agent turns the reviewers' comments into guidance in that repository's AGENTS.md, so the next run doesn't repeat the mistake.

Why it matters for code review

This is steady, harnessed throughput with the compounding step written down: every review comment becomes standing instruction instead of a one-off fix. It also complicates the speed story honestly. A ticket that sat 85 days got two PRs in ten minutes, but reached production 22 calendar days later, because nobody on the owning team had reserved time to review a PR from outside the team. Big agent PRs are still the unsolved part: reviewing a 2,000-line, four-PR dashboard took about as long as writing it. Their partial fixes are a "Decisions and assumptions" section on every PR, a cleanup pass before opening, and stacked PRs for large work. Read beside Traycer's factory build log and Kiln's factory, where the human yes became the queue.