a tactical breakdown of pstack and what we learned applying it to our own repo
2,500 pull requests to production in one month.
That’s what Lauren Tan, who goes by poteto online, shared in her talk on X.
The first-order story is more agents and faster models. The second-order story is trust, and from what I can tell, 2,500 PRs is what falls out once everything an agent does is checkable enough to run a lot of them at once.
As a founder, I’m always thinking about shipping velocity. I spent the last month running the startup from my van, so anything that lets me trust more agents at once gets my attention.
That trip also handed me my first outdoor V9 and a decision about my 100 mile ultra I didn’t see coming. I’ll get to both at the end.
Shout out to Lauren for open-sourcing the whole thing.
Jonathan and I talked about it on our recent podcast, so here’s the tactical version for AI builders.
TL;DR
The philosophy behind pstack, from my lens, is to make every piece of agent work verifiable, and compound from there to parallelize and scale up agentic work.
poteto ships 2,500 PRs a month this way, and our own experiment on the Clarity API repo already surfaced several areas where we can find gains in velocity. One key tactic: giving every agent the same verify command.
I encourage you to try pstack. I can see us getting a lot of leverage from this.
On Cursor, it’s one line: /add-plugin pstack. Anywhere else, paste this into your coding agent. We modeled it on my Codex port and tested it in Codex and Claude Code:
Port pstack (https://github.com/cursor/plugins/tree/main/pstack, MIT, by Lauren Tan aka
poteto) into your own native skills, then prove the port works. Don't change my global
agent config, and if skills with these names already exist, stop and ask before
overwriting.
1. Source: shallow-clone https://github.com/cursor/plugins to a temp dir. Read
pstack/README.md, docs/guide/, every skills/*/SKILL.md with its references/,
playbooks/ and scripts/, and agents/*.md. Note the commit SHA.
2. Scope: project scope unless I say user scope.
Codex: .agents/skills/<name>/ (user: ~/.agents/skills/)
Claude Code: .claude/skills/<name>/ (user: ~/.claude/skills/)
If your sandbox blocks writes there, build the same layout in ./pstack-port/, run
every check against it, and end with the exact copy command to install it. If writing
there needs my permission, ask; don't route around it.
3. Copy every upstream skill folder in full, plus pstack's LICENSE into each. Rename
poteto-mode to start-work, keep setup-pstack, prefix the rest pstack-<upstream-name>.
Update cross-skill references to the new names.
4. Frontmatter: `name` must equal the folder name (lowercase, digits, hyphens).
`description` is one line under 200 chars (skill lists get truncated) that says when
to use it. Drop Cursor-only keys (mode, icon, color, reminder, is_background).
start-work's description credits "ported from pstack's poteto-mode by Lauren Tan
(poteto), MIT". Where upstream sets disable-model-invocation: true, Claude Code keeps
the key; Codex gets agents/openai.yaml with `policy: allow_implicit_invocation:
false`.
5. Adapter: write start-work/references/adapter.md mapping each Cursor-only piece to
your real tools: Task/subagent_type/run_in_background to your subagent tool
(sequential passes if none), AskQuestion to a plain question,
~/.cursor/rules/pstack-models.mdc to start-work/role-models.json, /add-plugin and
Cursor built-ins (create-skill, cursor-team-kit deslop) to your equivalent or
"unavailable". Every ported skill that dispatches work reads the adapter first, and
start-work opens leaf SKILL.md files by path (leaves with disable-model-invocation
are hidden from the model's skill list).
6. Models: port setup-pstack to write start-work/role-models.json covering every
upstream role. Use only model IDs you've confirmed you can invoke here; otherwise
"inherit". Never write unverified Grok/Opus slugs.
7. Subagents: keep interrogate's one-reviewer-per-configured-model panel. Port
agents/*.md as Claude Code subagents in .claude/agents/<name>.md (name, description),
or Codex custom agents in .codex/agents/<name>.toml (name, description,
developer_instructions).
8. Write start-work/source-manifest.json: commit SHA plus path and sha256 of every
upstream file, so we can resync.
9. Add a 3-line pointer to start-work in AGENTS.md (Codex) or CLAUDE.md (Claude Code).
No skill bodies there.
10. Verify with evidence, not claims:
a. List the installed skill folders and check every name matches its folder.
b. Confirm counts against upstream: all skills, all 23 playbooks.
c. Run setup-pstack and show role-models.json.
d. Use start-work on a read-only Investigation ("how does this repo start?") and show
the playbook it picked.
e. Run pstack-create-verification-skill on this repo and drive one real user-facing
feature end to end. Show the command and its output.
If a step can't run, say exactly why and continue. End with a pass/fail table.five moves you can make this week
I had 13 agents go rogue in a goal loop recently and all 13 created their own way to verify a feature. Complete waste of tokens.
2. Collapse verification into one command. We now have one harness verify command. It spins up a disposable Postgres, runs the migrations and every test, and dumps it all into one pass/fail table, and every agent uses it.
The way I put it on the pod we recorded recently, is that if you ask a team of 50 engineers to test and verify something, you want to give them the same way all the other engineers are verifying.
That consistency compounds across the team.
Good software = good margins = good enterprise value = good business = flywheel to improve customer experience and compound market share
3. Turn the rules agents ignore into checks.
Tell me if this is familiar:
You have an AGENTS.md or a CLAUDE.md file, but sometimes your agent, especially with Claude Opus 5 in our experience, doesn’t give a flying shit about your typed out rules in your fancy markdown file.
It’s basically like, “Hey, I read those rules, I don’t care.”
So we turned them into two lint rules and pinned the CI Node version locally, so agents aren’t testing on different versions of Node. Fix repeat mistakes as high up as you can, and docs go last.
That last one matters a lot when you have 20 or 30 agents handing work across orchestrators.
And that number will only increase, as will the importance of common verification.
4. Write a feature map. One file per user-facing feature, starting with your top 3 to 5, listing every way a user can get to it.
I said this on the episode and I still feel it: the feature map is the foundational part.
To an engineer, multiple PRs or parts of the codebase can be a “feature”.
One customer may describe the feature differently than another customer.
Marketing and Sales may position the feature differently than how Product thinks about it.
So I’ve always been an advocate for a shared language of what features actually are, and the feature map makes that language the thing every agent checks against when it verifies.
That’s a key part of pstack, to me.
5. Make verification drive every real entry point. Have an agent drive your real app the way a user would, with a read-only check first that it’s the right build on the right port, and evidence saved after.
This is what really sold me: “a proof that drives one convenient entry point is incomplete when the map lists others.”
For AI builders out there, the meta here is verification first and speed second. You can’t have the latter without the former.
As your agent swarms grow, verification becomes the most foundational step to get right.
We’re still applying a lot of this ourselves, and I’ll share what changes as we go!
Build In Public
This is where I share the behind the scenes with the business and my life.
I’m back home after 30 days running the startup from vanlife.
Kenji and I went adventuring with a Starlink, from the Eastern Sierras, to Oregon, to Washington, and up to Squamish BC.
I’ve now spent the last week trying to become a real person with stable routines again. Sleeping in my own bed and working from my quad monitor workstation has been super welcome after questing so hard.
I know I’ve been behind with newsletter updates. It’s been difficult to juggle the weekly podcast (which has solid traction!) and the newsletter.
For now, I’m going to write when I feel like it ad-hoc, until I figure out a good cadence that works for me with both podcast + newsletter.
My current thought is to automate my weekly newsletter from the weekly podcast, with minimal edits, to serve as the written companion piece.
Then I can focus on writing deeper, more thoughtful, and more technical essay pieces once a month.
That would mean the weekly newsletter you receive has mainly signal from this week in AI, minor build in public updates, while I also ship a monthly newsletter that has deeper dives.
Let me know what you think of this direction! I’d love feedback!
$10M ARR
We’re making great progress on the Clarity Harness
We have a production app, our Clarity Harness, which we’ve been evolving quickly to register all of our agents and their runs so that any agent run by anyone on the team makes the next better for everyone.
We’ve been in progress on shipping the open source version of this Harness, which has gotten a lot of interest (200+ waitlist signups so far!) after I started sharing clips of how we use the Clarity Harness internally.
I see this as the first step of our value ladder, which will reduce cost of customer acquisition.
The idea being:
Create something valuable, open source with an open standard Our ICP(AI Builders) use it for personal/hobby projects They champion it into their company or organization ??? Profit
This move will also make delivery and fulfillment cheaper and more easily repeatable for us, which will improve our AI native services gross margins (currently sitting around 67%, improving towards 80% I hope by end of year).
On the content side, I met up with my friend Hamel Husain during my trip, the AI Evals God, in Portland where we tried to context-maxx.
I interviewed him on evals, and we shot three podcast episodes: an OpenAI DevDay recap, an agent swarm deep dive, and an evals best-practices episode done meme style, because Hamel is Hamel. 😂
If you’re an AI builder trying to get the latest meta for building better AI products, subscribe to the pod because you don’t want to miss this!
The goal for next year is still $10M ARR.
We’re at 1M of services revenue for this year, and I am hopeful to land our first ARR by end of this year to set us up for 2027. We have a few case studies and opportunities baking right now to empower this goal.
We gotta really grind through end of year to even have a chance at $10M ARR.
We got this. 💪
Side Quests
V10 Bouldering
Remember that V9 I mentioned up top?
I sent my first V9 outdoors!
I climbed in Squamish for the first time, and damn I get why climbers flock here during spring, summer, and fall.
You roll out of your car and walk 5 minutes and you’re in the midst of TONS of world class boulders
More on the climbing quest…
My V9 send was Bee Professor V9.
It took 3 sessions, which was much faster than anticipated for my first of the grade.
It’s also not really my style: slopey, full body compression, heel hook-y.
I thought it was soft but I’ll take 9 because other stronger climbers than me took 9 points for it.
Here’s the send footy.
V10 is absolutely in sight.
In fact, after making quick work of this one, I believe 100% that I have the capacity to send a V12 outdoors.
Just gotta keep trying hard.
100 Mile Ultra
Some photos from my trail running quests:
I’ve been running for about a year and a half now. I’ve now done 3 ultras:
31 miles 33 miles 50 miles
Next up is 100 miles.
And here’s the ultra decision I teased.
I had originally wanted to run my unsupported 100 mile ultra when I got back from my “startup from vanlife” trip, but the days are getting darker sooner.
One of the reasons I’ve fallen in love with ultrarunning is seeing so much during the journey of the run itself.
So I decided to delay it.
I honestly had some mixed feelings and counter thoughts when I had the initial thought of delaying my 100 mile run:
“Am I a little bitch?”, I asked myself.
After much contemplation, I decided no I’m not.
(😂 ridiculous, I know)
I realized that the journey itself is really what I’m after.
I’m in peak condition to run the 100 mile, I did the 50 only ~3 months ago for my birthday and have kept up with my running.
But, I want to max out the views of the experience and the enjoyment of the journey itself.
Not just check off a box.
So, I’m now kicking it out to next year targeting my 35th birthday on June 28th, 2027. Daylight will be maximal.
Additionally, I’ll be able to PT and train my body so that I’m actually ready for 150 miles so 100 miles won’t feel too bad and will be quite enjoyable.
Dog Dad Update
Kenji was with me for all 30 days of the trip. He LOVED vanlife. It made him a better dog too.
Lots of new stimulus everyday:
New people New places New smells New experiences New EVERYTHING
Vanlifing with me has noticeably made him way calmer in all sorts of environments and situations.
I love my good boy (:
All in all, the “run startup from vanlife” experiment went really well.
With the routine disruption, there were many days where I didn’t feel like doing anything to be honest.
But that’s what discipline is for.
Discipline beats “feeling like it”.
I was able to work, run, and climb even on days I didn’t “feel like it”.
Because of discipline, I made progress on all the quests and feel super fulfilled.
I imagine telling my younger self that he’d get first ARR in the pipeline while vanlifing and adventuring on the road.
He’d never believe me. 😂
I wonder what my future self will get up to.
P.S. If you haven’t yet, go give poteto a follow and watch the talk. Matt Pocock also did a live Q&A with her that’s really good. And if you try create-verification-skill on your own repo, I’d love to hear how many fake failures it turned up, because I’m genuinely curious whether our 9 to 13 fake failures per lane is normal.
P.P.S. Jonathan and I break all of this down in an upcoming episode of Weekly AI Clarity, our series bringing AI tech executives and builders signal from the frontlines of AI. New episodes weekly on YouTube, Apple Podcasts and Spotify.
Follow me on..
references
Tan, Lauren (@poteto). “here’s how i shipped 2,500 PRs last month to production.” X, September 21, 2026.
Tan, Lauren. “pstack.” GitHub repository, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “pstack README.” GitHub, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “pstack guide.” pstack, GitHub, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “poteto-help.” pstack, GitHub, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “setup-pstack.” pstack, GitHub, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “create-verification-skill.” pstack, GitHub, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “poteto-mode.” pstack, GitHub, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “figure-it-out.” pstack, GitHub, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “Investigation.” poteto-mode playbook, pstack, GitHub, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “Bug fix.” poteto-mode playbook, pstack, GitHub, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “Perf issue.” poteto-mode playbook, pstack, GitHub, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “Hillclimb.” poteto-mode playbook, pstack, GitHub, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “Feature.” poteto-mode playbook, pstack, GitHub, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “Shipping.” poteto-mode playbook, pstack, GitHub, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “Opening a PR.” poteto-mode playbook, pstack, GitHub, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “prove-it-works.” pstack, GitHub, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “interrogate.” pstack, GitHub, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “correct.” pstack, GitHub, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “reflect.” pstack, GitHub, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “maintain-verification-skill.” pstack, GitHub, cursor/plugins. Accessed October 11, 2026.
Tan, Lauren. “encode-lessons-in-structure.” pstack, GitHub, cursor/plugins. Accessed October 11, 2026.
Pocock, Matt. “LIVE: Poteto (creator of pstack) on shipping 1,000’s of PR’s a month.” YouTube video, October 2, 2026.
Ta, Robert, and Jonathan McCoy. Self Aligned (Weekly AI Clarity), episode recorded October 7, 2026. Coming out soon.