Build It Yourself: Prototyping & Technical Fluency
The hands-on bar - prototype with AI tools, reason about architecture
Prototype-with-AI as a core skill
After this you can build a working feature slice fast using AI coding tools.
Cursor's PM job description says it plainly: you build the first version of a feature yourself, get it in front of users and iterate. The prototype is not a mockup someone else codes later. It is the artifact you hand to engineering.
This reframes the whole role. At a company with no traditional PMs and no project managers, a spec that ends at a Figma file is half a deliverable. The bar is a thin slice a real user can click, running on a stack you can deploy without fumbling. Most of your interview prep for this role is reps at exactly that.
Cursor's growth team has a phrase for the shift: deliver demos, not memosThe shift from writing a text spec to building a live, clickable prototype to convey product intent; what gets cheap to make moves the leverage to vision and taste.. The build step is collapsing, so the leverage moves to expressing product vision concretely and fast - a live, clickable prototype you hand to engineers and designers instead of a text PRDProduct Requirements Document. The spec describing what to build and why. they have to imagine.
Deliver demos, not memosThe shift from writing a text spec to building a live, clickable prototype to convey product intent; what gets cheap to make moves the leverage to vision and taste..
The onsite small project is where this gets tested live. Treat it as a prototype-with-AI exercise even if the prompt is written as a spec, because that is how the team actually works.
Cursor's growth team is blunt about why a live build beats a static mock: the agent can stand up a fully functioning, interactive web app faster than you can wire an interactive prototype in Figma, and a URL to a clickable demo communicates an idea more directly than a text PRDProduct Requirements Document. The spec describing what to build and why. or a flat screen. Don't abandon written specs, but lean toward the shareable running thing - deploy it to an internal system or Vercel and send the link.
The reason Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. pays off for non-engineers: you carry years of pattern-matching in your head, and the underlying models are smart but don't know how you do your work. So you brain-dump the problem and what good looks like, let the agent research the docs and codebase and write a Markdown plan, correct it, then let it execute and test on a few examples. The modes are worth knowing by name: agent (the default), plan (start a task and scope the approach), ask (read-only, safe for onboarding and analysis), and a meta-agent layer that babysits parallel agents.
A lot of it just came from brain-dumping - the models are so smart, but they often don't understand the way we do our work.
It's a lot easier to build those than it would be to create an interactive prototype with something like Figma, because the agent can just build a fully functioning web app.
Open Canvas from the plus menu and it renders rich visualizations straight from a prompt - no “build it in React” or brand-guideline instructions, it uses Cursor's own UI frameworks. Ask it to “walk through and display the different user journeys of my app” and it produces a journey matrix; ask it to document how a codebase is built and it gives you an interactive view. One Cursor field engineer fed it the product docs to generate a getting-started pamphlet for a new enterprise customer. People have built slides and dashboards from it.
This is like diagrams on steroids - enriched UI Cursor comes up with based on whatever you want to see.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Two steps are gates: a scoped slice you can say in one sentence and a running stub on screen inside the first hour.
The prototype loopscope, scaffold, run, demo
- 1Scope a thin slice. Pick the single end-to-end path that proves the idea. One user, one action, one visible result. Write that sentence down before you touch the agent - it is the thing your demo has to make real.
- 2Scaffold with the agent. Open Cursor's Agent, describe the slice and the stack and let it generate the skeleton: a route, a component, a fake data source. You are steering, not typing every line.
- 3Run it locally. Get it on screen within the first hour. A running stub beats a beautiful plan and it surfaces the real problems early while you still have time to cut.
- 4Demo it. Rehearse the click path until it works every time. The win is a user reaching the result, not the breadth of what is half-built behind it.
Prompting is a product skilldecompose, steer, verify
How you drive the AI is itself graded. A PM who can decompose a fuzzy idea into buildable steps and verify the output is doing the core of the job a generalist builder does here.
Break the feature into small, checkable steps.
Give the agent one concrete task at a time, not the whole app.
Name the stack and constraints up front.
Read the diff before accepting it.
Reject and re-prompt when it drifts.
Point it at the file or function, not the whole repo.
Run the code, do not trust that it works.
Click the demo path yourself.
Hardcode an edge if it makes the path real.
Have a default deployable stackfluency beats novelty
Pick one stack you can stand up from memory and rehearse it cold. Setup friction is the most common way candidates lose time live and it reads as a builder who does not actually build. The specific stack matters less than your fluency in it.
npx create-next-app@latest demo --ts --app cd demo # build the slice with Cursor Agent, run locally npm run dev # ship a public URL so the demo survives a flaky onsite network npx vercel --prod
When you get the onsite project, narrate your scope cut in the first ten minutes: “Here is the full idea, here is the one slice I will get working in the time and here is what I am deliberately faking.” That sentence shows shipping bias and judgment before you have written a line, which is exactly the builder-PM signal the loop is looking for.
Do not let the agent run the session. Accepting large diffs you have not read produces a demo that breaks under the first question. Steer in small, verified steps so you can always explain what every part does.
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.
- 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.). 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.
- 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. 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 and why. 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.
- 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. (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. - 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.
- 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.
- 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.”
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.
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.
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.
Takeaway. Your deliverable as a Cursor PM is a running slice, not a mockup. Rehearse the scope-scaffold-run-demo loop on a stack you can deploy cold - plan first in Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. (free to edit, catches PRDProduct Requirements Document. The spec describing what to build and why.-vs-codebase gaps), execute cheap with 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., verify in the built-in browser and tweak by clicking in Design mode - and treat prompting - decompose, steer, verify - as the core product skill it is.
Self-check
QOn the onsite small project, you have a feature idea that is too big for the time box. What is the strongest opening move?
Reason about architecture with engineers
After this you can hold a credible technical conversation about how a feature is built.
The JD's bar is explicit: navigate a codebase independently and reason through technical architecture with engineers. Not for them, with them. You are a peer in the design conversation, not a translator standing outside it.
This is the differentiator that screens most PM candidates out at Cursor. You do not need to write the production code. You need to discuss data flow, APIs, latency and failure modes without hand-waving and make scope tradeoffs that an engineer respects.
Get into an unfamiliar codebase fastthe explicit bar
- Get the app running first - a baseline you can poke beats reading files cold.
- Use Cursor itself to map the slice you care about: symbol search, jump-to-definition and Agent explanations of one path.
- Trace one request end to end: what the user does, which call fires, where state lives, what comes back.
- Inventory what already exists so you extend a primitive instead of inventing one.
Two ways a PM enters the workbuild from scratch vs engage an existing repo
Cursor's PM growth team sees two standard workflows, and naming which one you're in keeps you honest about what the tool is for.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
Build-from-scratch leans on the prototype loop; engaging an existing repo leans on codebase access to produce planning artifacts and ship small changes.
Cursor as an Oracle engineerask it before you ask a human
The most useful mental model for the second workflow: Cursor is an Oracle engineer with the full context of your codebase. It's like ChatGPT, except it knows your repo. The operating habit at Cursor is simple - any time you'd normally walk over to ask an engineer or a data scientist a question, ask Cursor first. Answering questions is one of the agent's strongest uses, and it's exhaustive about the things a human would take hours to assemble.
Cursor is really just this Oracle engineer that can answer any question. It's like using ChatGPT but it has the full context of your codebase - essentially a mini senior engineer baked into it.
This is the highest-leverage discovery move for a PM. When you're reasoning about a product funnel - say onboarding and activation for a feature - brainstorm directly with Cursor because it can describe the status quo more exhaustively than you could: every feature-flag nuance, the data states a user can fall into, whether an analytics event is instrumented a particular way, why an inconsistency shows up in the data. Instead of pulling a data scientist or staring at code for hours, you get grounded answers in near real time to feed the decision.
I'm just brainstorming with Cursor on that, because it can tell me what the status quo is very exhaustively - much more than I could.
The product judgment isn't replaced here; it's accelerated. You still decide what to build. The agent removes the hours of archaeology between a question and a grounded answer.
A reproducible explore-to-spec sequenceAsk mode, then Agent - no code written by you
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.). 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 - “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. and ask it to “outline the simplest way to incorporate geography into the logic.” You're scoping, not building.
- 5Generate the spec (Agent mode). 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 - executive summary, background, context - that becomes the artifact you hand to engineering.
Orchestrate agents, don't just chat with oneLinear, Slack, cloud agents, P2/P3 ownership
Once you can read a codebase, the next leverage 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. 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 - so you use Cursor as 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. A cloud agent is, in plain terms, an engineer with a laptop in the cloud - you kick off a task and it works while you don't watch. Cursor's surfaces (Slack, Linear, the IDE) are all ways to orchestrate that cloud developer. For a PM, getting cloud agents set up early is one of the highest-leverage investments you can make.
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 - the P2s, the P3s, 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 background agents wired to Linear: small tickets get completed by background agents, BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. reviews the output, and you test locally. The payoff is less deliberation - 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 and why. 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 and why. as a file in the codebase - include how to break the project into PRs, the stages, 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.
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.
- Concept
- Context / retrieval
- What it is
- Which code gets pulled into the model's window
- The product tradeoff
- More context improves answers but costs latency and tokens; what to retrieve is a design choice
- Concept
- Latency budget
- What it is
- How long a user waits for Tab or a chat token
- The product tradeoff
- Autocomplete must feel instant; a slow suggestion is worse than none
- Concept
- Streaming
- What it is
- Showing tokens as they generate
- The product tradeoff
- Hides latency and feels responsive, but complicates undo, edits and verification
- Concept
- Model cost vs quality
- What it is
- Bigger model versus a faster, cheaper one
- The product tradeoff
- A smarter model that is slow or pricey may lose to a snappy good-enough one for inline edits
- Concept
- Eval
- What it is
- How you measure if outputs are actually good
- The product tradeoff
- Without evals you cannot tell a model swap from a regression; correctness is the trust currency
| Concept | What it is | The product tradeoff |
|---|---|---|
| Context / retrieval | Which code gets pulled into the model's window | More context improves answers but costs latency and tokens; what to retrieve is a design choice |
| Latency budget | How long a user waits for Tab or a chat token | Autocomplete must feel instant; a slow suggestion is worse than none |
| Streaming | Showing tokens as they generate | Hides latency and feels responsive, but complicates undo, edits and verification |
| Model cost vs quality | Bigger model versus a faster, cheaper one | A smarter model that is slow or pricey may lose to a snappy good-enough one for inline edits |
| Eval | How you measure if outputs are actually good | Without evals you cannot tell a model swap from a regression; correctness is the trust currency |
These are the levers a Cursor PM trades off every time they shape a feature.
Make tradeoffs, do not just relay thembuild 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, 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 - “what breaks if retrieval times out and what does the user see then?” - not pretending to have every answer. 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.
Takeaway. You debate architecture as a peer: trace one request end to end, ground every AI term in its product tradeoff, take a position on build-vs-buy and scope and treat “let me pull in an engineer on this” as a strength, not a gap.
Self-check
Instrumentation & metrics partnership
After this you can define how you'd measure whether a developer feature succeeded.
The JD names this directly: partner with data science on instrumentation, metrics and measuring whether a launch actually succeeded. Measurement is part of the build, not a report you write after.
Wire the events when you scope the feature, not after launch. If you ship first and instrument later, your first read on whether the thing worked is a guess and you have already lost the window where the signal is cleanest.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
The JD's bar is a feature developers use every day - so rank metrics by how close they sit to that, not by how easily they move.
Primary metrics for a developer featurewhat 'it worked' actually means
- Metric
- Activation
- What it captures
- Share of users who try the feature once
- Why it matters here
- Tells you discovery and the first-run experience are working
- Metric
- Retention
- What it captures
- Users still using it days or weeks later
- Why it matters here
- The truest signal it earned a place in the daily workflow
- Metric
- Daily active use
- What it captures
- How often it shows up in a normal workday
- Why it matters here
- The JD's bar is a feature developers use every day, so this is the target
- Metric
- Acceptance / keep rate
- What it captures
- Share of AI suggestions the user keeps
- Why it matters here
- For Tab and edits this is the trust signal - kept code is value delivered
| Metric | What it captures | Why it matters here |
|---|---|---|
| Activation | Share of users who try the feature once | Tells you discovery and the first-run experience are working |
| Retention | Users still using it days or weeks later | The truest signal it earned a place in the daily workflow |
| Daily active use | How often it shows up in a normal workday | The JD's bar is a feature developers use every day, so this is the target |
| Acceptance / keep rate | Share of AI suggestions the user keeps | For Tab and edits this is the trust signal - kept code is value delivered |
Pick one primary metric the feature is really for; the rest are supporting.
Guardrails catch the silent damagewhat could the launch break
- Latency regression
- Did Tab or chat get slower? A correct feature that adds lag erodes the core experience.
- Error / undo rate
- Are users undoing edits or hitting failures more? Rising undo means the suggestions are wrong.
- Trust signals
- Disable rates, opt-outs, support tickets - the quiet ways developers vote against a feature.
A primary metric can climb while a guardrail quietly tanks the product.
Read a real signal with a staged rolloutdesign the experiment
- 1Ship behind a flag to a small percentage of users, so a regression hits few people and is easy to roll back.
- 2Hold a control group that does not get the feature, so you can attribute the change to the feature and not the week.
- 3Watch the guardrails first. If latency or undo rate spikes, stop the rollout before you chase the primary metric.
- 4Expand in steps as the primary metric holds and guardrails stay flat, widening the cohort until it is fully on.
Total suggestions generated or feature impressions are vanity metrics - they go up just by shipping. Tie every metric back to “used every day”: a kept suggestion a developer relied on is worth more than a thousand they ignored. If a number can rise while the product gets worse, it is not your primary metric.
When asked how you'd measure a feature, answer in three layers without being asked: one primary metric tied to daily use, two guardrails that would make you halt and the staged rollout that lets you read the signal cleanly. That structure signals you've actually shipped and measured, not just drawn a funnel on a whiteboard.
The ticket is the brief - and where the metric livesdescribe the what, not the how
Instrumentation discipline starts upstream of the dashboard, in how you write the work. In an agent-driven team a detailed Jira/Linear/Notion ticket becomes the agent's brief - the structured context that determines output quality, and the new home of what prompt engineering used to be. A good brief states user stories, requirements, data models and UI but deliberately not the implementation steps, leaving the agent to reason about the how.
- Put the success definition in the brief, not in a follow-up. The same ticket that scopes the feature should name its one primary metric, its guardrails and the events to fire - so measurement ships with the work instead of being bolted on after launch.
- Let the agent pull the ticket in (MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs.). With an Atlassian or Linear MCP connected, “implement GRAPH-59” is enough: the agent recognizes the Jira ticket, fetches the full issue, plans and builds - so the quality of your brief is doing the work a long prompt used to.
- Keep data access read-only. Wire data tools (a read-only SQL or Databricks MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs.) so an agent can fetch the numbers to instrument against but can never drop a prod table - least privilege as a default, not an afterthought.
Describing the what (the behavior, the data model, the success metric) rather than the how is the same discipline that makes a prototype demoable: it forces you to state, up front, what “it worked” means. If you can't put the primary metric and its guardrails in the ticket, you don't yet know what you're building - and the agent, like an engineer, will fill that gap with a guess.
Takeaway. Instrument when you scope, not after launch. Pick one primary metric tied to daily use, set guardrails for latency, undo rate and trust and read the signal with a flagged, staged rollout against a control. Treat the ticket as the agent's brief - describe the what, not the how, and put the success metric and its guardrails in the brief itself, with data access kept read-only.
Self-check
QA new autocomplete change raises total suggestions accepted by 20%, but average Tab latency rose and undo rate ticked up. Is the launch a success?
Drill: spec-to-prototype rep
After this you can run a timed rep that mirrors the onsite project.
Reading about the prototype loop will not get you through the onsite. Reps will. This is a timed drill you can run end to end in an evening, then again until it is muscle memory.
Pick a real Cursor gap you have felt as a user - a paper cut in Tab, a missing affordance in Agent, a rough edge in how chat shows multi-file edits. The fact that you can name a real pain is itself the product judgment the loop rewards.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
One gate: the demo has to run cold in under two minutes before the rep counts as done.
The 90-minute repspec, build, demo, measure, iterate
- 1Write a one-page spec (15 min). Who hurts, when and the one slice you will build. State the user, the action, the result and what you are explicitly not building.
- 2Build a thin prototype (45 min). Scaffold with Cursor Agent on your default stack. Time-box hard and narrate every scope cut and tradeoff out loud as if an interviewer is in the room.
- 3Make a demo script (10 min). Write the exact click path that shows the user value in under two minutes. Rehearse it until it works every time.
- 4Capture the metric and rollout (10 min). Name the one primary metric you'd watch, the guardrails and the staged rollout you'd run to read the signal.
- 5Get one round of feedback (10 min). Show it to an engineer or PM friend, take the sharpest critique and note the single change you'd make next.
What 'good' looks like at the endthe artifacts you should hold
One end-to-end path a user can click.
Edges faked, not faked-out - the demo never breaks.
Opens with the problem in one line.
Shows the user reaching the result, not a tour of code.
One primary metric tied to daily use.
Guardrails and a staged rollout you can name.
What you cut and why.
What you'd build next and what would change your mind.
Problem (1 line): <who hurts, when> Demo path: 1. user does <action> 2. feature shows <result> # the moment that lands Faked for the demo: <what is hardcoded and why> Primary metric: <activation | retention | keep-rate> Guardrails: <latency | undo-rate | trust> Next: <the one thing you'd build after the slice>
“I noticed that when Agent edits five files, you can't tell at a glance which change matters most. I built a slice that ranks the edits by blast radiusHow much breaks if a change goes wrong; the scope of potential damage. so you review the risky one first. It's faked past the top file, but here's the path. I'd measure it on review-completion time and watch undo rate as a guardrail.”
Can you run the demo cold, on a fresh machine, in under two minutes without it breaking? Can you say the primary metric and the cut you made in one breath each? If not, the rep is not finished - that fluency is the whole point.
Takeaway. Run the rep until it's muscle memory: one-page spec, 45-minute prototype, a two-minute demo that never breaks, a named metric and rollout and one round of feedback. Hold all four artifacts and you've rehearsed the exact onsite.