Cursor Ships Declining Review as a Feature. Write Down What Pulls a Human Back In.

“Early on, you review each PR closely. As the fixes hold up, you review less, and the coordinator keeps working through the migration on its own.”

That sentence is from Cursor’s own announcement of Projects, a vendor post describing a product Cursor sells. Governance programs treat exactly that behaviour as drift to be detected. Cursor prints it in the product copy as the expected shape of a healthy workflow.

The same page says the Project “is on track to touch 20 to 100 PRs a day.”

What the Page Actually Describes

Strip the announcement down to mechanics and four things stand out.

The coordinator does not write code. In Cursor’s words, it “doesn’t write code itself but directs other agents that do. Because it delegates rather than executes, it is never blocked and is always responsive to direction.” Delegation is the reason it can hold a migration open across many PRs.

Subscriptions attach it to events. A coordinator “can watch a Slack channel, run on a schedule, or follow all your PRs, fixing CI and acting when they open or merge.” Read the CI clause on its own. The same automated party that produces the changes also repairs the gate that judges them. In any other control environment that is a separation-of-duties question, and the page does not answer it.

Shared context files “sync across every cloud and local machine its agents use.” Agents write to those files. Those files then govern every future agent in the Project. The page describes no review step for that context, no provenance for who wrote a given line, and no expiry.

The compounding rule is the sharpest of the four. The coordinator “scans every new PR, extracts components that belong in the design system, and adds a lint rule whenever it sees the same mistake twice.” A lint rule is a policy. Cursor describes no human approval step before that policy lands.

Controls may exist behind all four. The claim here is narrower: the page states none of them, while describing a workflow whose stated success condition is a human reading less over time. Cursor also positions the Project for work that “will outlive a single chat, whether that’s a feature with several PRs, a migration, or a job you want handled while you’re away.” Long-running and unattended are the exact conditions under which an unstated threshold matters most.

Where the Governance Reflex Misfires

The reflex of a governance program is to treat declining review as a failure to detect: dashboards for approval latency, alerts when diff size per approval climbs, a quarterly audit of rubber-stamped merges.

PostHog aims somewhere else, and says why plainly. “If you are generating 20 PRs per day, reading every line and running them by hand is unrealistic.” Their engineering newsletter names the bottleneck directly: “With the volume of changes coming from agents, this quickly becomes a bottleneck,” referring to the work of evaluating what agents produce. PostHog reports its own telemetry here, not an industry measurement. Over four months, agent-opened PRs moved “from around 20% of our monorepo PRs being opened by agents to 70%.”

At that volume, line-by-line reading stops being a control and becomes a ritual. We have argued before that comprehension is the real bottleneck rather than verification. The volume numbers in both of these posts are what that argument looks like when it arrives at an actual team.

So attenuation is going to happen. The interesting question is what replaces the thing it removes.

The Artifact Worth Copying

PostHog’s answer is one sentence:

“It wasn’t auto-approved because the review found 2 ‘must fix’ issues.”

That sentence is a written, auditable trigger condition. It states why a human is in the loop for this change and, by implication, why a human was not in the loop for the others. It can be queried. It can be disputed. It can be tightened next quarter and the change can be diffed.

Read the limits of it as well. PostHog publishes this one line, not the full threshold, so must-fix findings may be one route among several. What the line establishes is that a threshold exists as a named artifact rather than as a weekly feeling about how much the agents have earned.

PostHog is careful about what stays human for a different reason too. On scoping work themselves: “At best, my agents would have taken many more tokens to get to the same solution. At worst, they would have introduced bugs and attack vectors.” And on where the effort migrates: “The consequence of this is engineers doing more work on the system that builds the product than the product itself. They build the software factory rather than the software.”

The trigger condition is factory work. It belongs to the system that builds the product, and somebody has to own it there.

Written Beats Implied

A written trigger is a control. An implied one is a habit with good intentions, and a habit survives no audit, board review or customer questionnaire.

The difference shows up the moment something goes wrong. With a written condition, the post-incident question is answerable: the change did not meet the escalation criteria, here is the criteria, here is why it did not fire, here is the amendment. With attenuation by vibe, the only available answer is that the team had stopped reading closely, which is true of every team and explains nothing.

We have already argued that a review claim has to be tested before it counts, and that the kind of bug an agent can be trusted to catch depends on whether the oracle is binary or architectural. Both of those are about the quality of the automated review. This is about the other half: the rule that decides when automated review is not enough, and who wrote it down.

Do This Now

Take the last 30 agent-authored merges in your busiest repository. For each one, answer in a shared document: what would have pulled a human into this change? If the honest answer for most of them is “nothing specific, someone would have noticed,” you have attenuation without a trigger, and you have it today, regardless of which vendor’s product you run.

Then write four lines and put them in the repository, not in a wiki nobody opens:

The escalation condition. Name the finding class, the touched path, or the blast radius that forces a human. PostHog’s version is a must-fix count. Yours can be simpler, as long as a machine can evaluate it and a person can read the result.
The separation rule for the gate. If an agent can repair CI, state which failures it may repair and which ones it may only report. An agent that can turn its own build green has removed the only independent judge in the pipeline.
The lifecycle of shared context. Who may write to the files that steer every future agent, who reviews those writes, and when they expire. Unreviewed shared context is a policy change with no changelog.
The reversal trigger. The condition that raises review back up: a production incident, a rollback, a failure rate above a stated line. Attenuation with no path back is a one-way door with a pleasant sign on it.

Cursor is selling a coordinator that works while you sleep, and the pitch is honest about what that costs you in attention. PostHog is running the same attention problem and published the sentence that manages it. Take the sentence.

This analysis synthesizes Introducing Projects (Cursor, 2026) and What happens to engineers when AI writes all the code? (PostHog, September 2026).

Victorino Group helps engineering organizations write and enforce the escalation conditions that keep human judgment in agent-driven delivery. Let’s talk.