A Cursor Workshop on Agent PRs

By Rogier Muller09.07.26

The Hacker News thread and Lauren Tan clip this piece cites were not stored as links. Treat the PR numbers as reported, not independently verified here.

A Hacker News thread surfaced Lauren Tan’s Cursor workshop on agent-written PRs and the systems behind them.

A Hacker News post looking for people who design systems to ship code with AI agents is really about a shared workshop clip featuring Lauren Tan from Cursor. The post points at a practical question: what does it take to ship many agent-written pull requests without personally writing every line? The answer is not a better prompt; it is a better operating environment around the agent. For anyone using this as cursor training, the interesting part is the system: harnesses, constraints, rules, skills, and review loops that make agent work inspectable.

The clip landed because it did not sound like a keynote. It sounded like someone who had been tired in the exact way agent infrastructure makes you tired: less “watch the model code” and more “why did this PR pass the wrong boundary again?” That is a more useful story than most AI coding demos.

Notice what the human stopped doing

The striking claim in the Hacker News discussion was that Tan described systems that ship hundreds of PRs per month without her touching the code directly. The human work moved upstream. She worked on the environment, the harness, the constraints, and the rules where the agents operate.

That shift matters because it changes what “good at AI coding” means. The scarce skill is not typing a perfect one-off prompt. It is designing a workspace where an agent can pick up a task, find the right context, make a small change, run checks, and leave a diff a human can review.

A Cursor skill is reusable task knowledge that an agent can invoke when the task matches its description. In a real Cursor workflow, that might mean one skill for adding an API endpoint, another for updating a React component, and another for writing migration-safe database changes.

Don't measure agent work by how magical the chat looks. Chat is the least durable part. The durable parts are files in the repo: AGENTS.md, Cursor rules, skills, subagent definitions, scripts, and tests.

Treat rules as rails, not reminders

The workshop story is useful because it frames rules as infrastructure. In Cursor, rules can carry repository-specific guidance: architecture boundaries, coding conventions, testing requirements, and review expectations. They are not decoration for the agent. They are the rails the agent keeps hitting as it works.

A small example: imagine a payments service with a strict boundary between billing calculations and invoice rendering. A root AGENTS.md can describe the broad repo norms. A nested Cursor rule near services/billing/ can say that fee logic must not import UI rendering code, and every fee change needs a unit test with rounding cases.

That local scope is the whole point. The closer the rule sits to the code it protects, the less the agent has to guess. It also gives reviewers a plain place to ask, “Is this rule still true?”

Don't write rules like inspirational posters. “Write clean code” will not save you. “Do not add network calls under billing/core; call adapters from billing/integrations instead” has a chance.

---
description: Billing-domain rules for agent changes under services/billing
alwaysApply: true
---

- Keep fee calculation code inside services/billing/core.
- Do not import UI packages or invoice rendering modules from billing/core.
- For any rounding, tax, discount, or fee change, add or update table-driven tests.
- Run: pnpm test services/billing -- --runInBand
- In the PR summary, list the billing invariant you changed or preserved.

This is not glamorous. That is why it works.

Make subagents narrow enough to review

The phrase “agent-written PRs” can sound like one giant autonomous worker. The safer version is smaller. Cursor subagents and custom agents are most useful when they have a narrow job, a narrow permission surface, and a predictable handoff.

For example, a migration-reviewer subagent should not redesign the product. It should inspect schema changes, check for backward compatibility, look for missing rollback notes, and report risks. A test-fixer subagent should repair failing tests after a known change, not silently rewrite application behavior to make green checks happen.

That narrowing is what makes the human review feasible. You are not reviewing the agent’s personality. You are reviewing a bounded diff against a stated job.

Watch for naming a subagent after a role that is too broad, like senior-engineer or fullstack-builder. Those names invite sprawling output. Prefer names that sound almost boring: api-contract-updater, lint-cleanup-agent, storybook-snapshot-checker.

A useful handoff note from a subagent can be tiny:

Agent: api-contract-updater
Task: Add cursor-based pagination to GET /customers
Touched: api/routes/customers.ts, api/schemas/customer.ts, tests/api/customers.test.ts
Checks run: pnpm test tests/api/customers.test.ts
Needs human review: pagination defaults, backwards compatibility for old clients
Did not touch: database indexes, billing queries, auth middleware

That receipt is often more valuable than a long chat transcript.

Use skills when the same mistake repeats

Cursor skills are a good place to package workflows that agents need more than once. The workshop lesson is that repeated agent mistakes are design signals. If an agent keeps forgetting a migration checklist, that checklist probably belongs in a skill, not in your memory or in a Slack thread.

A practical cursor training exercise is to watch your next three agent PRs and write down the repeated correction. Did the agent forget to update generated types? Did it run the wrong test command? Did it miss the local fixture pattern? Turn one of those into a skill with a clear name and description.

A skill should have a sharp activation surface. “Backend tips” is vague. “Add a tRPC procedure with schema validation and tests” tells the agent when to use it and what good output looks like.

Don't turn skills into a junk drawer. A skill that contains every repo convention becomes another unread handbook. Keep it focused enough that a reviewer can tell whether it applied.

This is also where Subagents and skills is worth keeping close. The interesting question is not whether Cursor can run an agent. It is whether your repo gives that agent the right small capabilities at the right moment.

Try the workshop lesson safely

You do not need hundreds of PRs to learn from this story. Try one narrow loop in a low-risk part of a repo. The goal is not autonomy. The goal is to see whether the environment can make an agent’s work boring enough to review.

Use a small issue like “add empty-state copy to the settings page” or “add validation for one optional field.” Avoid auth, billing, migrations, data deletion, and broad refactors for the first pass.

Copy this checklist into the issue before you start:

Pick one task that should touch fewer than five files.
Add or confirm one local Cursor rule that names the boundary.
Add one skill only if the task follows a repeated workflow.
Ask the agent for a plan before code.
Reject plans that cross unrelated directories.
Let the agent make the change in a reviewable diff.
Run the exact test command named in the rule or skill.
Ask for a handoff receipt: files touched, checks run, risks, and untouched areas.
Review the diff first, not the chat.
Save the repeated correction as a future rule or skill.

This is the smallest useful version of the workshop idea. It turns agent output into evidence: a plan, a diff, a test run, and a receipt.

There are limits. Rules can be stale. Skills can overfit. Subagents can still make confident mistakes. The win is not trust without review; it is a workflow where review has handles.

For a related angle on where agents run, especially when local control matters, see Cursor Self-Hosted Machines Run Agents Locally.

Next step

Watch one agent PR from plan to diff to receipt, then write down the first correction you repeat. That correction is probably your next Cursor rule or skill.