For engineers who ship with agents

You love your coding agent.That's the problem.

It opens more pull requests in a day than you can read in a week. RUNOUT turns each one into five sharp questions about the change. The code with your name on it stays code you can defend.

diff · jobs/nightly.py · +14 −2 · your agent's PR
Your agent wrapped the nightly job in an advisory lock. What breaks without it?
Nothing. The lock is defensive.
A slow run overlaps the next one, and both charge the same customer.✓
The job runs slower without a lock.

“I merged it. I can't explain it.”

Your agent wrote it. The tests passed. You approved it in forty seconds. Six weeks later it pages you at 2am, and you read your own file like a stranger's.

“They merged it. Nobody can explain it.”

Four engineers, an agent each, one codebase. Every pull request got an approval. Not one of them got a reader.

Instead of

Reviews got longer. Reading got shorter.

Nobody reads a 900-line agent diff at 6pm on a Friday. People skim it, they approve it, and the codebase gets one more room that nobody has walked into.

RUNOUT asks the small question the approval was meant to answer: do you know why this changed? Five questions. Two minutes. No queue, no blocking check, no comment thread that dies over the weekend.

A quiz belongs to the repository, not to the person who opened the pull request. So you can take the quiz on a change you did not write. It is the fastest way to learn what a teammate shipped.

Try it

A question RUNOUT might ask you.

Pick an answer. Some of these come from your own pull requests, some from a teammate's, and one from the Friday quiz on the whole repository. None of them ask whether you can read code.

diff · PaymentClient.charge() · +12 −4 · your agent's PR
This PR replaced 3 fixed retries with exponential backoff capped at 30 s. Why?

Why this matters

It's about the trade-off. Fixed retries can amplify an outage; backoff capped at 30 s eases off exactly when the provider is already struggling. RUNOUT scores the why — not a definition you could paste from the docs.

Want questions like this about your code?

Try for free →
How it works

It reacts to change. Then it asks why.

Every pull request triggers a quiz

Connect the GitHub App. When you open a pull request, or mark one ready for review, RUNOUT reads the diff. Then it explores the code around the diff to find what actually matters.

The questions are about why

Five questions for a small change, ten for a big one. Each one asks why a decision was made, or what breaks if an invariant fails. Never “what does this method do.”

Your misses come back

Miss a question and the explanation appears on the spot. About half of your next quiz re-tests the areas where you are weakest.

And on Friday morning, every repository gets one quiz about itself as a whole — so a quiet week still asks you something.

Measure it

Watch comprehension, not commit count.

Every finished quiz becomes a point: the share of questions you got right, with a rolling mean over the top. One line per repository, because a repo you stopped following falls behind on its own. A falling line means you ship faster than you understand.

If you own the account, you see these lines for the whole team. That is how you find the repository everybody approves and nobody understands.

Rolling comprehension · 3-quiz mean
78%
▲ +9 pts / 8 wks
100% 50% 0%
wk 1wk 4wk 8
payments-api · 78% checkout-web · 54%
your code RUNOUT shallow-clones your repository into a temporary workspace and deletes it the moment the quiz is written — we never store your source. Only the diff and the excerpts the agent reads on the way are sent to the model, and they are never used for training. Privacy policy →

Ship it. Then prove you get it.

Connect a repository. Your next pull request comes back with five questions.

Try for free →