Code got ten times faster. The queue did not.

A founder asks for a button label to change. Writing it takes two minutes, with or without an agent. The change goes live two weeks later. Nothing in between was slow. Everything in between was a queue.

Writing code is something like ten times faster than it was two years ago. Argue the multiple if you like; nobody argues the direction. What has not changed is what happens after the code is written. The same backlog, the same review, the same engineers deciding what is safe. This piece is about the three ways teams move a change to production, and why only one of them fixes the wait.

The old way: every change goes through the whole team

You know this one. The request lands in the backlog. It waits for sprint planning. A PM writes the ticket, a designer mocks it, an engineer estimates it, QA tests it, and if anything is off it goes back round the loop. Two weeks is a good outcome.

This process was built for a world where writing code was the expensive step. If every change costs an engineer-day, batching them into sprints and gating them with ceremonies is rational. It stops being rational the moment writing the change costs two minutes.

The current way: one line, everyone at once

Agents collapsed the writing, and the best teams responded by collapsing the handoffs. Idea, backlog, everyone collaborates in one channel, shipped. PMs, designers and support people now open pull requests instead of tickets. Three public examples, all from 2026:

• epilot opened its 219 repositories to the whole company in February. In 60 days, 40 of 629 merged PRs came from 11 non-engineers. Every PR gets a live preview link, and engineers review and merge.
• At Dune, designers "now push 5–15 PRs per week, which is historically an engineering metric." The standard path still requires engineering review.
• At LTV.ai, the company's coding agent opened 84 PRs in July and 45 merged. The agent cannot merge, and every PR arrives with a recorded browser session showing the feature working.

These are real wins and I do not want to undersell them. But look at the shape. Everyone can now write. Every change still ends up in the same review queue, in front of the same engineers. epilot's author puts it plainly: non-engineer contributions "don't reduce what we expect from engineers. They amplify it." Dune's retrospective says more designer PRs add to engineers' review load and calls that an open problem.

The queue did not get shorter. It got longer, and more of what is in it is small.

Why "small" is the wrong sorting key

The instinct is to fast-track small changes. Rootly's CTO, Quentin Rousseau, explained in May why they dropped their two-year-old small-PR rule: "The small-PR rule was optimized for human writing speed." They replaced it with risk labels on every PR, low, medium or high, where the label answers what happens if the change breaks, not how big the diff is. A 3,000-line feature behind a flag with no migration, rolling out to internal users first, is low risk. A 12-line change to an index on a 50-million-row table is high.

Rewind reached the same conclusion from the other direction. Their AI approval system grades every PR from what the reviewers find, not from line count, and a deterministic rule decides who must approve. Authentication, secrets, infrastructure and anything that changes who can approve always go to a human. On early, small-sample data they report about 40% of PRs approved without a human and zero incidents linked to those approvals.

Route by risk, not by size. A copy change should never wait behind a migration, and a migration should never ship because it was short.

The Hybrid way: check first, then route

Here is the third way. The change is made in a draft, on a private copy of the product, by whoever had the idea. Before it joins any queue, it is checked against the Rulebook: the list your engineers wrote of what is sensitive, such as payments, login, pricing and user data, and the user journeys that run through those areas.

Two things can happen. If the change touches nothing on the list and every measured outcome stays the same, it ships, with a filmed before and after and a record of what passed. If it touches something that needs judgment, it goes to an engineer already specced, with a note on exactly which rule fired and why. Engineers decide where the line sits, and they can pull any category back with a single rule edit.

The difference from the "one line" model is where the sort happens. In the current way, risk is assessed at the end, by a tired reviewer, after the change has already waited. In the Hybrid way, it is assessed first, by a rule, before anyone waits at all.

How to start, this quarter

You do not need to flip a switch. The teams above all started the same way, and so can you.

1. Approve everything at first. In month one, nothing ships without an engineer. The point is to see the verdicts next to real reviews, not to act on them yet.
2. Write down what is sensitive. Payments, login, permissions, pricing, user data, and anything that changes who can approve. Rewind's always-human list and Rootly's flagged categories (migrations, security, core workflows) are good starting points. This is one afternoon with your CTO.
3. Shadow the verdicts. For every change, compare the rule's verdict with the engineer's decision. Rewind set 90% agreement as the bar before going live and reported about 99%. The disagreements are your list of rules to fix.
4. Open one category at a time. Copy and translations first; epilot's non-engineers shipped 116 German translation improvements in their first two months. Then colours and spacing, then settings. Each category is one rule edit to open and one to close.

One caution from epilot is worth repeating. Early on, a non-engineer with full push access deployed to production without review. Nothing broke, but it led to tighter permissions and a written governance guideline. Lock down merge rights before you widen who can write.

The two weeks were never the typing. They were the queue. Sort the queue by risk and most of it disappears.

See how fast your team could be moving.