Skip to lesson
Exit
Build It Yourself: Prototyping & Technical Fluency1 / 3

1 min lesson

A worked example: the loop with the real surfaces

Use "The loop with the real surfaces" to describe the practical rule.

Step 1 of 3

A worked example: the loop with the real surfacesscope to demo, using the tools by name

The loop above is the shape; here is one rep run with the actual Cursor surfaces you'd reach for, so it reads as something you've done rather than something you've read.

Learn more

Full explanation

Design mode changes what a PM can build

  1. 1Plan before you build (Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition.). Don't scaffold blind - run Plan mode first. It researches the whole indexed codebase, follows existing paradigms and outputs an editable, hyperlinked Markdown plan: scope, implementation, tests, to-dos. Editing that plan costs zero tokens because it's just Markdown, so you tighten scope for free before a single line is written.
  2. 2Let the plan catch the gaps. Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. Press Enter for the full definition. interactively asks the scope questions you'd otherwise discover at hour five - single column or summary cards, does the list need search and sort. It also pauses on contradictions: in one workshop 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. said “use authenticated users” but the agent saw no auth in the app and asked how to handle the gap - build full auth now, or ship a local-first V1. That clarifying question is a feature, not friction.
  3. 3Execute cheap. Plan with a frontier/thinking modelA reasoning model (shown with a brain icon in Cursor's picker) that spends extra compute before answering; reach for it on complex, nuanced work and a standard model for fast, simple tasks. Press Enter for the full definition. (it only reasons), then hand the to-dos to ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. Press Enter for the full definition. - Cursor's own coding model, near-frontier at roughly a tenth the cost and fast enough to keep you in flow. Letting the expensive model write every line burns your budget before the demo.
  4. 4Verify visually in the built-in browser. Cursor ships a full browser inside the editor that renders your running app. Give it a plain-language directive - “increase the padding of the heading on the overview page” - and watch it render while Cursor surgically edits only the necessary files. Agents can self-test here too, clicking around and taking screenshots.
  5. 5Tweak by clicking, not describing (Design mode). Design mode lets you target a UI element directly in that browser instead of describing where to look - which also saves the agent from burning tokens searching the DOM. Select a palette and say “adhere to proper contrast ratios,” or “lowercase this and give it rounded corners.”
Design mode changes what a PM can build

Most build-skill advice is written for engineers. Design mode is the lever a PM gains the most from: it lets non-engineers - PM, BA, design - propose or communicate a change visually, by clicking the element, before any engineer implements it. For the onsite prototype it means you can polish the demo path by pointing at what's wrong instead of writing a paragraph about it, which is both faster and exactly the cross-functional move the role rewards.

Learn more

Full explanation

Ship in the flow of work, not just the IDE

Ship in the flow of work, not just the IDEasync, over Slack, human-in-the-loop

The prototype loop isn't confined to the editor. Cursor connects to Slack, and PMs make changes from a thread without opening the IDE at all. One worked case: there were no docs for an AWS Bedrock integration. The PM dropped that into Slack, Cursor read the code and wrote the docs, an engineer replied in-thread flagging two things that were wrong, Cursor was told over the same thread to fix them, and it shipped. The whole loop took about 15 minutes, entirely in Slack.

The pattern to name

What makes that 15-minute case work isn't speed for its own sake - it's that the human review stays in the loop. The agent drafts, a domain expert corrects in-thread, the agent revises, then it ships. In an interview, describe async agent work this way: who reviews, where the correction happens, what gate ships it. That reads as someone who has run the workflow, not just heard about it.