Kiro Crew at 1,000 PRs a week: one readiness verdict, and a retrospective that stops a ten-line fix growing into a subsystem
The Kiro Crew team's follow-up says human line-by-line review lasted less than a day; confidence now comes from a single PR Readiness check that means every check ran and passed, tiered findings, reviewers split by role and model family, and a loop that looks back after several rounds and recommends stopping, reverting or simplifying.
Source: Keeping a software factory stable at 1,000 PRs a week
Zejiang (Joe) Guo, Bolin Chen and Zezhen Xu (Kiro) follow their 1,000-PRs-in-a-week post with the question they got most: how does that not break everything? Their reframe is whether a person can be responsible for PRs they didn't write and didn't read line by line. Their answer is that they're responsible for the review record CI writes on every PR (each finding, how it was fixed or answered with evidence, every check result, and the final verdict), and they spend about 20% of their time on the infrastructure that produces it.
Reviewing every change by hand lasted less than a day, back in March. After that, quality came in five stages. A rule that every AI comment must be resolved became churn: fix five, get four new ones on untouched code, and each fix drew comments of its own. Tiering fixed part of that (blocking findings in this PR, nits become follow-up issues), plus a multi-pass reviewer told to surface everything in one round. Moving to GitHub brought end-to-end tests and reviewers split by role (design, first-principles, UX) and by model family, "because a model reviewing its own family's code shares its blind spots." A finding only blocks if it names a location, quotes evidence, and gives a trigger and a consequence. Design concerns stay advisory unless they describe a choice that can't be undone.
Then the human became the bottleneck, so they closed the loop. A skill drives each PR until a single PR Readiness check is green, and that check means every expected action ran and passed, because "no failing checks" and "nothing has run yet" look the same on a new PR. Simple-tier PRs auto-merge; the rest get an agent-written description that CI checks against the diff.
The failure they call the biggest source of waste is over-engineering. A reviewer flags an edge case, the agent adds a mechanism, the next round flags the mechanism, and five rounds later a ten-line fix is a small subsystem. Their fix is a retrospective after several rounds on the same area that asks whether the change is converging, and recommends a stop, a revert or a simpler approach. A second "conductor" agent makes the first call so the loop doesn't stall waiting for a person. Security findings get the same treatment: fix the user-reachable problem with the smallest change, after review rounds kept tightening the sandbox until normal builds failed. These are Kiro's own numbers and practices, and Kiro sells the product.
Why it matters for code review
An always-on loop doesn't only fail by merging bad code. It also fails by never converging, as reviewer and author agents keep adding to each other's work. Kiro's answer puts the stop condition in the harness, not in a human's patience. That's the same lesson as the overnight PR that cycled fifty times in the Claude Code team's review process, and it pairs with Morozov's harness that never believes the agent: the readiness verdict, not the agent's report, is what a person signs.