A Cursor Workshop on Agent PRs

By Rogier Muller09.07.26

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, Anysphere’s AI code editor. 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. Devin Workshop is part of Harness Institute.

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.

The trap is measuring 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?”

The trap is writing 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.

The trap is 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.

The trap is turning 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 the related training topic 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.

Common questions

Is this mainly cursor training or an agent infrastructure story?

It is both, but the source story is about agent infrastructure first. The training value comes from seeing what the human actually designed: rules, harnesses, constraints, skills, and review loops. A good takeaway is to train on one bounded PR workflow before trying to scale agent output.

What are Cursor skills good for?

Cursor skills are best for repeatable workflows that need more context than a short prompt. Use them for patterns like adding an endpoint, updating generated types, or preparing a migration checklist. If the instruction applies everywhere, consider a rule; if it applies only when a task matches, consider a skill.

When should I use a Cursor subagent instead of one normal agent?

Use a Cursor subagent when the job has a stable specialty and a reviewable boundary. Good examples are contract review, test repair, migration inspection, and docs synchronization. Avoid broad subagents that can justify touching anything; the narrower the remit, the easier the handoff is to trust.

Do I need Cursor MCP before this becomes useful?

No, you can learn the core loop with repo-local rules, skills, tests, and PR review. Cursor MCP becomes useful when the agent needs controlled access to outside systems such as issue trackers, internal docs, design files, or code hosting metadata. Start read-only where possible, then expand carefully.

How do I know an agent PR is safe enough to review seriously?

Treat it as reviewable when it has a stated plan, a small diff, passing relevant checks, and a handoff receipt that names risks. The number to watch is not lines of code; it is boundary crossings. A small diff that touches auth, billing, and storage is not small in practice.

Best ways to use this research

Best for: Cursor users who already get useful agent output, but want fewer surprise diffs and cleaner PR review.
Best first artifact: A local .mdc rule for one sensitive directory, with a required test command and a short PR-summary expectation.
Best comparison angle: Compare prompts, rules, skills, and subagents by durability. Prompts help one task; repo files help the next ten.
Best next experiment: Pick one repeated correction from an agent PR and turn it into either a Cursor rule or a focused skill.

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.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.