Kiro's Crew team says an automated review loop grows a ten-line fix into a subsystem unless something forces it to stop

This follows the team's earlier post saying three engineers and a crew of agents merged 1,000 pull requests in one week; we did not read that post. The authors say they tried reviewing every change by hand in early March and abandoned it in under a day. They then built five stages of checks: an automated reviewer, severity tiers for comments, open-source CI with role-split reviewers, a loop that drives each PR to green, and post-merge gates. The loop reads one "PR Readiness" verdict that has to mean every expected check has run and passed, because on a new pull request "no failing checks" and "nothing has run yet" look the same. They report test coverage above 90% and about 20% of the team's time spent on automation infrastructure.

The failure they spend longest on is over-engineering. In their words, a reviewer flags an edge case, the agent adds a mechanism, and the next review flags an edge case in that mechanism. "After five rounds, a ten-line fix has become a small subsystem that wasn't needed." Their fixes are a retrospective step that checks whether a change is growing instead of converging, a second "conductor" agent that makes the first call on what the retrospective recommends, and a rule that a finding must be fixed in proportion to the problem, except for a reachable crash, security hole or data loss. They describe the same pattern in security fixes, such as sandbox rules tightened until ordinary builds failed.

Why it matters: If you let agents fix their own review findings, build the stop condition before the loop: one readiness signal, tiered findings, and a proportionality check on each fix. These are the team's own account of its own open-source product. We did not open the repository, so the 90% coverage figure and the loop's effect on waste are unverified here.