Cursor for Sales Engineers and Field Engineers

Because it collapses the demo factory. A custom demo used to mean pinging an engineer and waiting a week or two, so most calls got a pre-baked template instead of the thing the prospect actually pictured. With a Cursor license, an SE who can vibe code folds bespoke demos into the normal cadence of calls, no engineer dependency.

The leverage is not only external. Field engineering, technical account management and GTM teams at Cursor also use it to build and maintain internal tools. Demos, RFP answers and internal apps are the three jobs this guide walks through.

Start from a completely blank editor and let the agent populate it. Open a new window, open a new project named for the scenario (say a COBOL repo you want to refactor for a financial-services prospect), then describe the environment, why it's set up that way, and the workflow it should facilitate. Instead of hand-wiring dependencies for days, you get a runnable repo in minutes.

Don't let the agent deploy straight into the blank repo. Dictate a verbose, slightly messy explanation — voice-to-text is fine here — then run Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes.. Cursor interprets the mess into a clear, production-grade plan and asks clarifying questions to fill gaps: what's the refactor target (modernize to Java with Spring?), the compliance context, the industry. You can preempt the plan to set up later beats — ask it to seed deliberate security vulnerabilities so a "scan for vulnerabilities" step lands later in the demo.

1. 1Open a blank project named for the scenario (cobol-se-demo).
2. 2Speak or paste a verbose prompt describing the environment, why it's built this way, and the workflow to showcase.
3. 3Run Plan modeA mode that makes no edits: it researches the codebase and produces an editable plan you review before any code changes. with a reasoning model so Cursor builds a clear plan and asks clarifying questions.
4. 4Preempt downstream beats — e.g. seed vulnerabilities so a later security scan has something to find.
5. 5Switch to a fast code model to execute the plan and populate the repo.
6. 6Ask the agent to write the demo narrative (beats + the exact prompts) as part of that first prompt.

Keep two copies of the same scenario. One lives behind the curtain with the demo narrative — 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 cleaned up, with no Markdown narrative and no prompt references, and that's the one you actually share on screen.

During the call you paste each prompt in live, so it never shows you're reading them out of the repo. Because you asked the agent to write that narrative as part of the initial build, the whole staged demo comes together in a few minutes instead of an afternoon.

Two land in almost every legacy-modernization conversation. First, the analysis prompt against tribal knowledge. The people who built or maintained a legacy COBOL or Java codebase have often left, so dependencies are opaque. One prompt cuts through it.

Second, turn that analysis into something visual. Ask the agent to "build me an architecture diagram written in Mermaid and saved to a Markdown file." It does a broad scan of the repo, then you preview the result inside Cursor with ⌘+⇧+V. Markdown preview renders the diagram (and your generated demo narrative) as an appealing visual breakdown — proof Cursor actually understands the dependencies in a complex or legacy codebase.

Connect Cursor to your product's real repositories — subject to your version-control access — and query them in plain English. This is the most supercharged docs you could ask for, and it's the highest-leverage SE use case in the whole workflow.

Use Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code. for this. Ask gates the agent from writing code, generating code or making any tool calls — you can only ask natural-language questions. That makes it perfect for two SE jobs: answering specific RFP and security questions (data retention, "does this leave our cloud environment," how indexing builds vector embeddings, whether a feature is deprecated or feature-flagged), and onboarding yourself onto unfamiliar tech so you can speak to a bespoke scenario confidently to any industry.

• RFP and security answers — query the connected codebase and cite the actual implementation, not marketing.
• Self-onboarding — ask the agent to teach you COBOL or an unfamiliar architecture before you demo against it.
• Deep reports — for complex questions, send a background agent with a 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 scans the whole repo over ~10–15 minutes and returns a robust readout.

Start with Auto and only override when you need a specific model's traits. Auto modeA router that reads your prompt and picks a model for you, defaulting to Composer; you steer it with cues like "quickly" or "carefully". is a managed Cursor service that dispatches your prompt to a short list of frontier code-generation models based on which have open capacity, prioritizing runtime speed. It offboards model selection entirely, which is why it's the daily driver.

When you turn Auto off, decide thinking vs non-thinking first. Reach for a thinking (reasoning) model to build plans, analyze complex environments, or run security and codebase scans — it's the smartest option but slower, and overkill for simple edits. Then consider traits: GPT-5.x is verbose and can overthink a small task, but it's excellent at writing documentation and clear natural-language explanations. Use a fast, purpose-built code model (Cursor's in-house 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. models) to execute a plan. That's the whole "plan slow, build fast" split.

Open a new chat per task and keep each context window to one topic. Every model has a finite context window, shown as a percentage and measured in tokens (a token is a unit of volume, like a megabyte, of input a model can receive). Fill one chat with unrelated topics and you trigger context rotThe quality drop that happens when one chat accumulates unrelated tasks or tangents, burying the signal the model needs in a haystack of stale context..

The discipline is to treat each chat as a task-by-task agent. Build foundational architecture in one agent, open a new chat for the landing page, another for a feature. "Stay modular and stay lightweight." A fresh chat discards prior history, which is to your benefit, and switching tasks is a natural moment to switch models too. You can also manually @-add the relevant files to a prompt — that shortcuts the agent's inference step and makes context use more efficient than letting it scan everything.

Yes — with manually-applied Project RulesVersion-controlled instructions in the repo that every Cursor agent interaction inherits, so standards are encoded once.. Beyond global team rules and per-developer rules, you can write a Markdown rule with a directive ("keep it simple," or a strict code-review directive) and @-tag it into a specific chat. That agent follows the rule; untagged agents don't inherit it.

So one agent becomes a code-reviewing agent, another a planning agent, another a simple-prompting agent — a clean way to showcase instructed, governed agent behavior on a call. The three rule scopes below are the full picture.

By treating Cursor as a way to solve problems internally, not just to demo the product. Cursor's field engineering, TAM, GTM and product teams commit internal tools to a shared field monorepo called FieldSphere — a trial tracker, usage and scoping calculators, a feedback aggregator over Gong call transcripts, a feature-request tracker. There's a deliberate council and culture encouraging onboarding SEs and TAMs to find a project, even a lightweight dashboard or data aggregator, and maintain it agilely.

The heavily-used example is a usage calculator: feed it an account name or a team ID and it returns a granular breakdown of how that account uses Cursor by token and by model, so GTM can forecast usage scope and trends. It's embedded as a tab inside Salesforce, prefiltered to the relevant account or opportunity — built and maintained entirely in Cursor, taking continuous feature requests.

1. 1Build it locally with the agent — import a CSV snapshot, render on localhost to answer your own question.
2. 2Host it (e.g. on Vercel) the moment a colleague asks "can you send me a link?"
3. 3Wire live data via webhooks or a proxy query connection to your data warehouse, instead of stale CSV imports.