Agent fleet self-reviews (Cursor model: error → fix → converge)

The Cursor model is a self-review pattern where an agent doesn't just write code - it runs the code, reads the error output, identifies the root cause, writes a fix, runs the code again, and repeats until all checks pass. The review is not a separate step that happens after code is written; it's integrated into the generation process as a continuous feedback loop.

The cycle is: write → run → observe errors → fix → run → observe errors → fix → ... → all tests green → converge. Each iteration is a self-review: the agent examines its own output against the specification (tests, linter, type checker) and makes corrections. The agent stops when the specification is fully satisfied.

At L5 (Self-improving), this pattern runs at fleet scale. Hundreds of agents are simultaneously working on different tasks, each running its own error → fix → converge loops. The "review process" is internal to each agent's loop, not a separate human-facing step. Agents that converge successfully produce Green PRs that auto-merge. Agents that can't converge (the task is genuinely ambiguous, requires external information, or hits a hard constraint) escalate to human review as a Red PR with a detailed explanation of where they got stuck.

Cursor's internal research on this model has documented meaningful improvements in first-pass correctness: agents that iterate through 3-5 error → fix cycles produce substantially fewer post-merge defects than agents that make a single pass and submit. The compounding of test-driven error signals into each iteration is the core mechanism.

At fleet scale, the aggregate effect is a stream of well-verified changes arriving continuously at the auto-merge queue, with humans only engaged when the problem is genuinely hard.

August put bounds on the loop. MCR-Bench (August 27) found that LLM defect detection degrades across successive review rounds - the model finds less on round three than on round one - so a converge loop that simply iterates longer is not converging on correctness, it is converging on the subset of problems the model can still see. And the loop must not close on itself. Addy Osmani's rule in Practical Loop Engineering is that a drafting agent never self-approves: the verifier is a separate agent or a separate gate. The "self" in self-review means the agent checks its work against a machine-checkable specification, not that it grants itself approval.

There is now population-scale data on what happens when the reviewer is also an agent. A study of 248,641 AI-attributed pull requests that received at least one AI-attributed review (August 21) found cross-product AI-to-AI review running at about 1.6% of agent-authored PRs but growing two orders of magnitude between 2025-Q1 and 2025-Q3, with median response latency of 1.2 minutes cross-product against 4.7 minutes same-product. Two findings bear directly on fleet design: same-vendor reviewer and author pairs produce 58-65% more comments, and CodeRabbit labelled 35.0% of its comments on Claude Code-authored PRs as refactor comments against 10.5% on Copilot-authored ones. The reviewer's provenance visibly shapes the review, which argues for making the verifier a different product from the author rather than the same model wearing a different prompt. Keep Dare Obasanjo's framing of the whole arrangement in view - a "verification ratchet", where using AI creates problems fixed only by using more AI - because the exits are limited: more automated verification, less agent velocity, or lower standards.

One honesty note about this level. "Agent fleet" is a pattern whose vendor enthusiasm runs well ahead of practitioner adoption; it barely registers in developer discussion. Treat what follows as the design of a frontier practice that a small number of organisations genuinely run, not as a consensus the rest of the industry is behind on.

Agent self-review through error → fix → converge loops changes the quality economics at L5:

• First-pass correctness improves dramatically - An agent that iterates until all tests pass is producing code that has been tested by definition, not just code that was intended to pass tests. The difference between "I wrote code that should pass" and "I ran the code and it passes" is the difference between L3 and L5 quality.
• Review is never a bottleneck - The agent reviews itself continuously during generation. There's no "submit and wait" period. By the time the PR is created, the agent's review is complete.
• Review scales with the fleet - Each agent handles its own review loop. Adding 100 more agents to the fleet adds 100 more parallel review loops. Human review capacity doesn't need to scale with agent fleet size.
• Error messages become specification - The agent uses compiler errors, type errors, test failures, and lint violations as feedback about its own code's correctness. This is a qualitatively different use of the quality gate than humans use: the agent reads error messages as a specification of what needs to change, not as news to act on later.
• Architectural guardrails are self-reinforcing - Custom lint rules (from L3) become part of the agent's feedback loop. When the agent's generated code violates an architectural constraint, the lint rule fires, the agent reads the error, and the agent fixes the violation. Architecture is enforced through the agent's own iteration, not through separate review.

The prerequisite for this model at L5 is everything that came before: TORS > 95% (so test failures are real signals, not noise), comprehensive lint rules (so architectural violations fire reliably), and a well-configured auto-merge system (so convergence results in ships without human intervention). The agent fleet model depends on the entire L1-L4 stack functioning correctly.

The agent self-review model emerges from capability investment at L3-L4, not from a single new tool:

1. Ensure your quality gate produces actionable error messages - Agents learn from error output. CI failures with messages like "Tests failed in module auth" are less useful than "UserService.login returns 500 when email is null - missing null check at line 42." Improve error message quality across your test suite, linter, and CI checks.
2. Configure agents to run tests locally before submitting PRs - In Claude Code, Cursor Agents, or your agent framework of choice, include an instruction: "Before creating the PR, run the test suite and lint. If anything fails, fix the issue and re-run before submitting." This adds the inner convergence loop to single-agent work.
3. Instrument convergence metrics - Track: how many iterations does the typical agent task take before convergence? What's the most common failure mode in the loop (lint errors, test failures, type errors)? This data reveals which parts of your quality gate produce the clearest signals for agents.
4. Design tasks with verifiable acceptance criteria - Agents converge on tasks that have clear, machine-checkable success criteria. "Implement the UserProfile endpoint" with a corresponding test suite is a convergent task. "Improve the readability of the auth module" is not - there's no machine-checkable criterion. Structure agent tasks for convergence.
5. Handle non-convergence gracefully - Some tasks don't converge: the agent hits a hard problem that requires external context, hits an ambiguity in the requirements, or reaches a maximum iteration count. These tasks should escalate to Red (human review) with the agent's explanation of where it got stuck. The escalation path is as important as the happy path.
6. Scale the fleet after validating the single-agent model - Before running 100 agents simultaneously, validate that 1 agent converges reliably on a range of task types. Fleet-scale deployment of a broken model produces fleet-scale failure.

Agents converging to the wrong solution. An agent can satisfy all tests while implementing the wrong behavior if the tests don't specify the right behavior. Tests that test what the code does (not what it should do) enable circular convergence: the agent writes incorrect code, the tests pass because they were written against the incorrect behavior, the agent converges. This is the L1 "circular testing" problem at L5 scale. The solution is acceptance tests written by humans (or from requirements) before agent implementation.

Infinite loop convergence attempts. Agents iterating without progress (fixing one error, causing another, reverting, causing the first again) can spin indefinitely without a termination policy. Implement maximum iteration counts and escalation paths for non-convergent tasks.

Ignoring the signal from non-convergent tasks. When agents consistently fail to converge on a category of task, it's a signal about the quality gate, the task design, or the agent's context. Track non-convergence rates and investigate root causes - they often reveal gaps in tests, ambiguous architectural constraints, or task specifications that need improvement.

Confusing convergence with correctness. An agent converging means the agent's code satisfies its quality gate - not that it satisfies the product requirement. Convergence is necessary but not sufficient. Human acceptance testing of requirements satisfaction is still needed at L5 for new feature development.