Cursor Engineer Details 2,000-PR Workflow

Cursor engineer Lauren Tan said in a video posted to X on September 22, 2026, that 2,000 PRs—requests to merge code changes—went to production over the previous month. The X post title listed 2,500, but the video’s opening screen and spoken remarks said 2,000. The 38-minute video drew more than 4 million views in a month. Tan said agents merge their own PRs, with no human review. The average size of PRs, rollback rate, incident count and costs were not disclosed, and it is unclear whether people had no involvement in every PR.

Tan’s pstack repository organizes workflows through documentation, skills and situation-specific playbooks. After reviewing the video and repository, the author applied similar mechanisms to an agent academy repository. The approach shifts review work to pre-PR validation, an independent judging agent, code structure and automated checks rather than eliminating review.

Tan said teams should establish ways to verify results before adding agents. If results cannot be trusted, people must check them again; adding agents while human oversight is still needed can increase low-quality PRs and regressions. Recalling a period spent tracking performance problems, he said, “I am the bottleneck.” A style guide alone leaves people responsible for remembering rules and flagging violations in review. Tan said recurring feedback should be built into code or automated checks instead of relying on memory.

Tan listed five layers for applying corrections: the codebase; static analysis such as linters, compilers and CI; rules and Bugbot; skills; and style guides. Enforcement weakens toward the lower layers, so a style guide is followed only when a reviewer points out a violation. The pstack verification guide advises setting completion criteria before work starts and creating app-specific verification skills. Those skills describe how to launch an app, check its state, operate it like a user, record evidence and clean up. In the video, a feature map shows where features are and how to access them, while a CLI lets an agent launch and operate the app. The workflow aims to prepare evidence that a change works before a PR is opened.

The deployment playbook assigns each PR a verification agent that did not write the code and asks it to run the change like a user, then record PASS, PASS+NOTES or FAIL. It rejects the authoring agent’s verdict because that agent is checking what it intended to build. A green CI result or an approving bot review also does not count as verification by a user who has tried the change. Merges proceed from the lowest PR upward; a PR above an unverified one waits. If a rebase changes commits, the workflow compares git patch-id values to check whether the earlier verdict still applies to the new code.

The pstack interrogate skill sends the same changes, intent and evaluation criteria to models from different families for review. When both independently flag the same issue, the workflow treats it as a reliable signal and classifies the result as fix now, investigate, log only or reject. It records reasons for rejection and does not apply any finding automatically. Bugbot comments are sorted into fix, reject or ask a human. Security, privacy and data concerns, as well as ambiguous findings, go to a person because missing a real data or security bug costs more than overlooking a minor code-quality issue.

Tan said agents repeatedly used nearby comments to justify workarounds instead of fixing underlying problems. He warned that copied workarounds can become the de facto standard within days. In the Grok bot codebase, his team created the Dune framework for agents and prohibited comments. It also added lint and build checks before review to catch incorrect imports, direct RPC calls that bypass required contracts, and increases in file size. The comment ban was presented as that team’s choice.

The pstack correct skill reads recent commits, reverted commits and review comments to group mistakes that occurred more than once, then tries to prevent them at the highest possible layer. It first uses code structure to make mistakes impossible, then types, lint and CI, followed by tests; documentation comes last. New checks must be tested against past real mistakes to ensure they fail. Tan said that instead of repeating the same review comments, teams should turn them into rules and act as “gardeners” who catch bad patterns early.

People remain responsible for the final result, Tan said, and pstack directs hard-to-reverse decisions involving security and data to humans. Lint exceptions require a reason, an expiration date and human approval. The show-me-your-work skill records agents’ reasoning in a table so a person or another model can check it later. In this arrangement, people set verification criteria, turn recurring mistakes into structural safeguards and take responsibility for the outcome, rather than reading every line of code.

In the author’s repository, a commit hook checks mess

Cursor engineer Lauren Tan said in a video posted to X on September 22, 2026, that 2,000 PRs—requests to merge code changes—went to production over the previous month. The X post title listed 2,500, but the video’s opening screen and spoken remarks said 2,000. The 38-minute video drew more than 4 million views in a month. Tan said agents merge their own PRs, with no human review. The average size of PRs, rollback rate, incident count and costs were not disclosed, and it is unclear whether people had no involvement in every PR.

Tan’s pstack repository organizes workflows through documentation, skills and situation-specific playbooks. After reviewing the video and repository, the author applied similar mechanisms to an agent academy repository. The approach shifts review work to pre-PR validation, an independent judging agent, code structure and automated checks rather than eliminating review.

Tan said teams should establish ways to verify results before adding agents. If results cannot be trusted, people must check them again; adding agents while human oversight is still needed can increase low-quality PRs and regressions. Recalling a period spent tracking performance problems, he said, “I am the bottleneck.” A style guide alone leaves people responsible for remembering rules and flagging violations in review. Tan said recurring feedback should be built into code or automated checks instead of relying on memory.

Tan listed five layers for applying corrections: the codebase; static analysis such as linters, compilers and CI; rules and Bugbot; skills; and style guides. Enforcement weakens toward the lower layers, so a style guide is followed only when a reviewer points out a violation. The pstack verification guide advises setting completion criteria before work starts and creating app-specific verification skills. Those skills describe how to launch an app, check its state, operate it like a user, record evidence and clean up. In the video, a feature map shows where features are and how to access them, while a CLI lets an agent launch and operate the app. The workflow aims to prepare evidence that a change works before a PR is opened.

The deployment playbook assigns each PR a verification agent that did not write the code and asks it to run the change like a user, then record PASS, PASS+NOTES or FAIL. It rejects the authoring agent’s verdict because that agent is checking what it intended to build. A green CI result or an approving bot review also does not count as verification by a user who has tried the change. Merges proceed from the lowest PR upward; a PR above an unverified one waits. If a rebase changes commits, the workflow compares git patch-id values to check whether the earlier verdict still applies to the new code.

The pstack interrogate skill sends the same changes, intent and evaluation criteria to models from different families for review. When both independently flag the same issue, the workflow treats it as a reliable signal and classifies the result as fix now, investigate, log only or reject. It records reasons for rejection and does not apply any finding automatically. Bugbot comments are sorted into fix, reject or ask a human. Security, privacy and data concerns, as well as ambiguous findings, go to a person because missing a real data or security bug costs more than overlooking a minor code-quality issue.

Tan said agents repeatedly used nearby comments to justify workarounds instead of fixing underlying problems. He warned that copied workarounds can become the de facto standard within days. In the Grok bot codebase, his team created the Dune framework for agents and prohibited comments. It also added lint and build checks before review to catch incorrect imports, direct RPC calls that bypass required contracts, and increases in file size. The comment ban was presented as that team’s choice.

The pstack correct skill reads recent commits, reverted commits and review comments to group mistakes that occurred more than once, then tries to prevent them at the highest possible layer. It first uses code structure to make mistakes impossible, then types, lint and CI, followed by tests; documentation comes last. New checks must be tested against past real mistakes to ensure they fail. Tan said that instead of repeating the same review comments, teams should turn them into rules and act as “gardeners” who catch bad patterns early.

People remain responsible for the final result, Tan said, and pstack directs hard-to-reverse decisions involving security and data to humans. Lint exceptions require a reason, an expiration date and human approval. The show-me-your-work skill records agents’ reasoning in a table so a person or another model can check it later. In this arrangement, people set verification criteria, turn recurring mistakes into structural safeguards and take responsibility for the outcome, rather than reading every line of code.

In the author’s repository, a commit hook checks mess