2 min lesson
Build the demo environment itself with the agent
Explain the practical point behind "Build the whole arc of the demo into the environment, not just the starting state."
Step 1 of 2
Build the demo environment itself with the agentblank editor to bespoke repo
Field engineers at Cursor don't keep a shelf of pre-baked demo templates. They open a brand-new window on a blank editor and have the agent build the exact environment the call needs - a COBOL repo to refactor, a service with the prospect's compliance constraints, whatever the scenario demands. You describe the environment, why it's set up that way and the workflow it should let you show, and a runnable repo appears in minutes instead of the days of hand-wiring dependencies it used to take.
Now I can just prompt Cursor to build me out a repository that can facilitate a certain outcome.
Don't let the agent deploy straight into the blank repo. Speak a verbose prompt - text-to-speech is fine, messy is fine - then run 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. so a reasoning model turns the rambling explanation into a clear, production-grade plan and asks clarifying questions to fill the gaps: what's the refactor target, the industry, the compliance context. Plan with the reasoning model, then switch to an execution model to build it.
Because 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. lets you edit before anything runs, you can preempt the plan to set up downstream beats. Planning a security-scan demo later in the call? Ask the agent to seed deliberate vulnerabilities into the generated repo now, so the "scan for vulnerabilities" step has something real to find. Build the whole arc of the demo into the environment, not just the starting state.
One move shows up in almost every field session: after a high-level pass over the codebase, prompt build me an architecture diagram written in Mermaid and saved to a Markdown file. The agent scans the repo broadly and produces a visual asset, then you preview it with ⌘⇧V in Cursor's Markdown preview. The visual breakdown proves the agent actually understands the dependencies in a complex or legacy codebase - and the same preview renders a generated demo narrative cleanly.
Learn more
Full explanation
Two versions: the script behind the curtain, the clean repo on screen
Two versions: the script behind the curtain, the clean repo on screen
The delivery craft is keeping two copies of the same scenario. One lives behind the curtain: a demo narrative with natural-language beats (here's what we're looking at, here's what we're going to do) plus the exact prompts to run. The other is a cleaned-up repo with the Markdown narrative and prompt references stripped out - that's the one you actually share on screen. During the call you paste prompts in live, so it never shows you're reading them out of the repo. Ask the agent to write the demo narrative for you as part of the initial build prompt.
I'll have one that's behind the curtain. It'll have a demo narrative. It'll have the prompts that I want to run. And then I'll actually share my screen showing a kind of cleaned up version.
The same blank-editor-to-runnable-app reflex pays off past the demo. Cursor's own field, TAM, GTM and product teams build and maintain internal tools in a shared field monorepo - a trial tracker, usage and scoping calculators, a feedback aggregator over call transcripts, a feature-request tracker - all in Cursor, maintained agilely. The team actively encourages new field engineers to find an internal project and own it.
We can also solve problems internally by building even if it's just a lightweight dashboard or an application or some type of data aggregator.
Creativity is graded, not optional
The role explicitly prizes creative, cross-disciplinary work and building novel automations of your own workflow. A demo that pulls an idea from outside engineering stands out in a feed full of TODO-app tutorials. The point isn't novelty for its own sake. It's that a surprising frame is what makes a developer stop scrolling.
"I built a todo app with the Agent SDKA programmatic interface for running Cursor agents from your own scripts, services or CI, locally or in the cloud. Press Enter for the full definition.."
Correct, reproducible and instantly scrolled past. There's no beat.
"I wired Cursor's CLI agent into my git hooks so it writes the changelog entry and the migration note on every merge - here's the diff it produced for this PR."
A real workflow, automated, with a concrete artifact you can inspect.
A flashy GIF with no reproducible path behind it reads as a stunt and engineers punish stunts harder than they reward polish. If the only thing the viewer can do after watching is feel impressed - not run it, not learn the move - the demo failed the role's bar even if it gets likes.
In the work-trial presentation, open on your whoa moment in the first 30 seconds, then rewind to show how you got there and the judgment calls along the way. Reviewers grading an 8-hour build want to see taste under time pressure: what you chose to cut is as revealing as what you shipped.