This note is a reading of Lauren Tan's X article How I Use Cursor (@poteto, 25 May 2026). Unless I say otherwise, the product claims below are hers. I have not installed pstack or used Cursor 3's Agent Window.

What she says she noticed

Tan writes that she had never used Cursor before her onsite. At Meta she was paying $200 a month for a personal Claude Code plan, liked how fast it felt, and had started wrapping it in her own orchestrator. The two-day interview project was still on Cursor's Editor Window, before Cursor 3. She missed the CLI at first. Three things stood out to her: switching Opus and Codex in one project (including mixed-model subagents), much faster context compaction than Claude Code, and a GUI that could open the app and edit it in Design Mode.

Those are interview impressions, not a benchmark. She does not give timings for compaction, and she does not claim Opus or Codex scored higher on a named eval inside Cursor.

The argument she actually wants

After joining at the end of March, she worked on Cursor 3's Agent Window. Claude Code, she says, is simple enough that people keep building orchestrators on top of it. She quotes Boris Cherny on latent demand: ship something open-ended, watch how people abuse it, then build for the abuse. Her reading is that a CLI leaves the human as the orchestrator. Putting several CLIs in a GUI does not change that.

The job she wants is trust. She compares agents to new hires who arrive with some skills and none of the team's memory:

Agents are like new hires in a constant state of amnesia and idiocy. They don't remember what you tell them, and they never really learn anything new.

Rules, skills, tools, and long-term memory are the approximation. Without rigor, she says, agents will write whatever you asked for, in volume. The line I keep:

Naive parallelization just makes them write slop faster.

What pstack is for

She open-sourced pstack as the skills she uses to build Cursor. I checked that the marketplace page exists. I did not run /add-plugin pstack. She says these skills are among the most used on the Cursor team. That is an internal claim I cannot verify.

The center is /poteto-mode: a higher-order skill that picks a playbook for the task. She writes that the goal is maximum impact with the least amount of code, not maximal lines. Debugging is the example she works through. Form hypotheses, binary-search the space, force a repro if the bug is flaky, add instrumentation, and rule causes out instead of guessing.

Playbook groups she names: skill authoring and evals, working autonomously, bug fixes and runtime forensics, feature development, visual parity and prototyping. On-demand skills she lists include /how, /why (MCP queries across source control, issues, docs, chat, observability, error tracking, analytics), /architect, /arena (N parallel attempts, keep the best parts), /interrogate (adversarial multi-model review), /tdd, /unslop, /reflect, /figure-it-out, and /show-me-your-work (a commit-able TSV of decisions). /automate-me mines recent transcripts and drafts a personal mode skill that still routes through pstack.

She says pstack can sit on any agentic coding tool and works especially well where several models are first-class. That is a design claim for Cursor. It is not a portability test.

Verification, then a factory

In her words, the bottleneck is that agents write a large amount of code quickly and making sure it is correct is hard. True agent parallelism, like in a dark factory for software, might be possible after that, so she wants depth first.

Maintenance is the second half of the essay. Agents now write so much code that bugs, perf issues, and feature requests pile up. Her example is Benny, a Cursor cloud automation she has given the same pstack skills. She is explicit that Benny is still a work in progress.

The loop she describes: Slack reports from Cursor dogfooding, including images and video; explore the codebase; ask the reporter for repro steps; file a ticket after checking git history, Slack, and Notion (bug versus designed behavior). A second Benny run uses /orchestrate: reproduce through computer use (Cursor Cloud Agents driving a desktop, including CDP-style control of their own products), fix if the repro is consistent, take CPU traces and heap snapshots on perf, spawn workers to verify against the ticket, record before-and-after video, open a PR with the video in the description.

Her closing condition is that you cannot automate a process until an agent can own the problem end to end, including verification. Parallelizing agents you do not trust yet wastes tokens and adds slop.

In a same-day follow-up she adds a price note. Multiple agents, especially frontier ones, burn expensive tokens. She hopes later Composer versions change that. I have no independent token numbers.

Editorial

Steal the order, not the plugin

I did not run pstack. What I trust in the essay is the sequence, not the slash-command catalog. Encode how you actually debug. Require a real artifact (a failing test, a repro, a trace, a click through the UI) before you call the work done. Only then spawn more workers. That order is the opposite of most agent demos I see, which start with a roster and hope verification appears later.

pstack itself looks like Lauren's private style dumped into a plugin: one mode skill so you do not have to remember twenty playbooks, plus a pile of principles I did not restate here because they live in the repo, not in this article. Copying the roster onto another tool without the verification loop would just rename the slop. /arena and /interrogate are width. They sit after the playbook, which is the point.

Benny is the part people will screenshot. She already flags it as unfinished. A factory that files tickets from Slack and opens PRs with videos is a Cursor-shaped encoding of trust, not proof that trust exists. The transferable piece is narrower: if the agent cannot demonstrate the break, it is guessing. I have watched that guessing in my own agent sessions. More parallelism would have made it worse.

The Cherny quote is product advice. Tan's twist is harsher. If the interface is a CLI, you are still managing the work. Skills are how you stop re-explaining the job to an amnesiac every morning. I buy that. I do not buy that shipping more agents is the same as teaching them.