1 min lesson
A reproducible explore-to-spec sequence
Talk this through in your own words. "You need a spec for a change in an unfamiliar repo, and you will not write the code yourself. Which sequence matches the explore-to-spec flow?" Finish with the next move.
Step 1 of 2
A reproducible explore-to-spec sequenceAsk mode, then Agent; you write no code
Here's a full PM flow you can run on any unfamiliar repo, demonstrated live and copyable end to end. None of it requires you to write code.
- 1Orient (Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code. Press Enter for the full definition.). Pull the target folder into context and ask 'what is this app, and what are its key components?' Ask mode is read-only, so it can't change anything while you learn.
- 2Understand the mechanism. Ask 'how does this system work?' for the part you care about, then ask Cursor to render a Mermaid diagram of it so you can see the flow.
- 3Probe a gap. Ask a pointed question, such as 'does the system include EMEA, APAC and Americas in the analysis?' In one run this surfaced that the data existed but the logic never used it.
- 4Outline the fix, still read-only. Stay in Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code. Press Enter for the full definition. and ask it to 'outline the simplest way to incorporate geography into the logic.' You are still only scoping.
- 5Generate the spec (Agent modeCursor's full-capability mode: the AI can read the codebase, write and edit files, move them and run terminal commands. Contrast with Ask mode, which is read-only. Press Enter for the full definition.). Switch to Agent and say 'create a project doc for this update in a Markdown file.' In the demo this produced a long, structured spec with an executive summary, background and context, and that spec becomes the artifact you hand to engineering.
Learn more
Full explanation
Orchestrate agents across your tools
Orchestrate agents across your toolsLinear, Slack, cloud agents, P2/P3 ownership
Once you can read a codebase, the next useful step is running work through it instead of asking it questions. An MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. lets a Cursor agent talk to external systems. With the Linear MCP connected, the agent can read tickets, comment on them, and create tickets and projects. That makes Cursor a front-end to your tracker.
Point the agent at a project: 'look at all the tickets and mark the ones that are solved as done.' For each ticket it pulls the context, jumps to the code, checks git history for relevant commits, decides whether the problem still exists, updates the comments, and surfaces open questions back to you. That's hours of manual triage turned into a review pass.
You can have Cursor go one by one and determine whether the problem in a ticket has actually been solved.
The same orchestration runs in the background: you kick off a task and a cloud agent works while you get on with something else. Slack, Linear and the IDE are all surfaces for orchestrating that cloud developer. Cloud agents come with Premium and above, and on a plan that has them, setting them up early is one of the most useful steps a PM can take.
Think about it like an engineer with a laptop in the cloud. That's what a cloud agent is.
Put those together and a real shift opens up: PMs and designers can own and ship the small things the team never gets to, such as the P2s, the P3s and the minor UI tweaks. At Cursor, product and design own a lot of the frontend and UX and iterate on it autonomously. The setup is a dev environment plus cloud agents wired to Linear: small tickets get completed by cloud agents, BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. reviews the output, and you test locally. The payoff is less deliberation, because anyone with an opinion can just make the change and judge it in the product.
Because you point the agent at a ticket or PRDProduct Requirements Document. The spec describing what to build, for whom and why, before implementation starts. Increasingly the artifact you hand an AI agent as the source of truth for a feature. Press Enter for the full definition. first, you rarely begin from a blank page. You start from an agent's investigation, often a plan, an architecture diagram or a PR that's roughly 90% complete, and take it from there.
Every time someone starts building, they can essentially start with 90% of the PR complete, or an entire plan or architecture diagram.
Two practices make this run cleanly. Write the PRDProduct Requirements Document. The spec describing what to build, for whom and why, before implementation starts. Increasingly the artifact you hand an AI agent as the source of truth for a feature. Press Enter for the full definition. as a file in the codebase. Include how to break the project into PRs, the stages and the architecture, so the agent can use it as a source of truth and an engineer can have multiple agents working off it. You can even run code review on the PRD itself to iterate on it. And keep a standalone prototype instance for UX work: Cursor's design team built 'baby Cursor,' a fully standalone, backend-simple but feature-rich instance used purely to try new UX patterns. Duolingo and other consumer companies have done the same. It's a clean way to express an idea with a prototype instead of a PRD.
Speak the AI-product stackthe vocabulary engineers expect
An AI code editor lives or dies on a handful of technical levers. Know what each one is and the product tradeoff it forces, so you can debate it concretely.
Learn more
Full explanation
The AI-Product Stack
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
The levers a Cursor PM trades off. Eval sits on top because it is what tells you the layers below are actually working.
Make the tradeoff call yourselfbuild vs buy, scope, sequencing
- Data flow
- Can you draw where the request goes and where it can stall or fail?
- Failure modes
- What happens on a bad suggestion, a timeout or a wrong edit, and what does the user see?
- Build vs buy
- Use a model API versus self-host; reuse an existing index versus build retrieval. Defend the call.
- Scope order
- Which slice ships first, which is cut and what that costs the user.
Be ready to take a position on each, then defend it under push.
Reasoning with engineers includes knowing when to pull one in. The skill is asking the right question, such as 'what breaks if retrieval times out and what does the user see then?' Engineers trust a PM who is precise about what they do not know far more than one who bluffs.
Buzzword fluency without mechanism is the tell. Saying 'we will use RAG' means nothing; saying 'we retrieve the open file plus its imports because that is the context the user is actually editing' shows you understand the why. Always ground a term in a concrete product reason.
Learn more
Optional practice