The Cursor Field Engineer
Visual Field Manual

Reconstruct the enterprise SDLC

See the customer's real delivery system — not its stated methodology.

The single most common rookie mistake is to take a customer's word for how they ship. They'll say "we're agile," and you'll picture continuous flow — but the actual change still waits two weeks for an integration environment, a security review, and a Thursday change window. Day 1 trains you to reconstruct the delivery system as it truly operates, with named artifacts, owners, and the gates where work actually waits.

1 · The full lifecycle — forward path and the return loop most people forget

A feature doesn't travel in a straight line and stop at "deployed." It travels idea → production, and then a second value stream runs incident → corrective change. That return loop is a goldmine of Cursor use cases (faster triage, characterization tests, smaller fixes), and naming it sets you apart from candidates who only know the happy path.

2 · Methodology vs. lifecycle — don't confuse the cadence with the system

This is the distinction that makes you sound senior. Methodologies organize when and how much work moves. They do not replace the engineering practices of design, test, release, and operate. A team can be devoutly Scrum and still batch-release quarterly behind a CAB. Know what each framework actually contributes — and what it conspicuously leaves untouched.

3 · The artifact graph and its systems of record

Here is the field-engineer reframe that turns a process diagram into a Cursor opportunity map. Every artifact is context the AI either has access to or doesn't, and every handoff between systems is friction Cursor can reduce. Trace one change across its systems of record and you'll see both the audit trail an auditor reconstructs and the context boundaries an agent must respect.

4 · The persona map — who blocks you, and what they fear

Nine roles touch the lifecycle. Each owns something, is measured on something, and can block you for a specific reason. This map becomes the backbone of Day 6's value mapping — you'll sell a different headline to each one. Learn the fear column most: objections come from fears, and you disarm a fear by naming it before they do.

CI/CD, release engineering & the toolchain

Trace one change from commit to production and understand every control it encounters.

If Day 1 was the org chart of delivery, Day 2 is the machine. The pipeline is the executable definition of what "acceptable change" means at this company. You never position Cursor as a way around it — you position Cursor as a way to feed the machine smaller, better-tested changes that generate the evidence the machine already demands.

1 · Branching strategy — and why you must argue both directions

Branching model isn't religion; it's a trade-off between integration frequency and isolation. Elite orgs trend toward trunk-based + feature flags because it maximizes integration frequency and shrinks merge risk. But enterprises rationally keep release branches for parallel supported versions, audit comfort, and CAB alignment. A field engineer who can only sell one model looks naive; one who can explain when each is correct earns trust.

2 · The pipeline and its gates — standard vs. regulated

Memorize the canonical stage sequence, then learn what a regulated org adds on top. The difference between these two diagrams is Day 3's entire subject, previewed here. Mark every place a human must act — those red gates are where separation of duties lives and where "AI just writes the code faster" runs into reality.

Progressive delivery & the rollback truth

Know the four ways to release gradually and the one thing that breaks rollback:

3 · The toolchain map — learn the archetype, then the swaps

You'll meet a hundred tool combinations. They're variations on one archetype. Memorize the archetype and what stays structurally identical when a vendor swaps (gates, evidence, promotion logic) versus what only changes syntax (YAML dialect, plugin names).

The archetype to say out loud: GitHub + Jenkins + Artifactory + Terraform + Datadog + ServiceNow. When you hear any stack, map it onto this and you'll never sound lost.

4 · DORA — the scoreboard you don't have to invent

The four DORA metrics are the lingua franca of delivery performance, and crucially, the platform team already reports them. Anchoring a pilot on DORA means you argue on the customer's existing scoreboard instead of inventing a new one nobody trusts. Two measure speed, two measure stability — and you must always pair them, because speed without stability is not a credible enterprise story.

Governance, compliance & Cursor's control plane

The day most candidates skip — and exactly where you differentiate.

Most candidates can demo. Very few can sit across from a bank's security team and speak the language of controls and evidence fluently. Day 3 is layer 5 from the foundations: the controls the customer must keep, matched one-for-one against the controls Cursor actually ships. Master this and you stop being "an AI tool rep" and start being someone security can work with.

1 · SOX / ITGC change management — risk and evidence, not bureaucracy

For SOX-relevant services (anything touching financial reporting), auditors require IT General Controls over how code changes reach production. The point isn't paperwork for its own sake — it's to guarantee that no single person can unilaterally push an unreviewed change to a system that affects the financials. The mechanism is separation of duties.

2 · Security's seats in the SDLC — and the review where you are the vendor

Security shows up in the pipeline as automated gates (SAST, DAST, SCA, secrets scanning) and as human review gates for sensitive changes, plus supply-chain concerns (SBOM, provenance, the SLSA vocabulary). But on Day 3 there's a second security story: the vendor security review of Cursor itself. A bank will run you through a questionnaire — data-flow diagrams, SOC 2 evidence, sub-processors, retention. You must be able to answer it from memory and then verify against the docs.

3 · Cursor's control surface, mapped to what the customer asks for

This is the table you should be able to reproduce on a whiteboard. For every customer control requirement, name the Cursor control that answers it. Group it into five families: identity, data, policy, network, visibility — plus Organizations as the cross-team admin plane.

4 · The trust equation — what turns a blocker into an ally

Senior engineers and security become blockers when AI changes are unreviewable, undisclosed, or unaccountable. The same people become allies when each of those is inverted. Memorize this as a transform:

5 · "10 hard questions" — and the two where honesty wins

Your strongest trust signal is admitting a limit and pairing it with a mitigation. Prepare honest answers; here are worked examples of the genre — note the two that concede a real limitation.

Cursor team workflows in a shared repository

Move from individual prompting to governed, repeatable, repository-grounded team workflows.

A clever prompt helps one person once. The unit that matters for an enterprise is a repeatable, reviewable workflow encoded close to the repository. This is the day you stop thinking "AI assistant" and start thinking "encoded team standards that happen to be executed by an agent." That reframe — rules and shared context turn 50 individual prompters into one team — is governance, not convenience.

1 · The progression from ad-hoc to governed

Teams climb this ladder whether or not anyone plans it. Your job is to make the climb deliberate. Each rung moves capability out of one person's head and into shared, version-controlled artifacts the whole team inherits.

2 · Context strategy in large repos — an engineering problem, not a prompt-length problem

In a Java monolith plus dozens of TS services, "just paste more" fails. Context quality comes from system design: let codebase indexing and search discover code, give exact artifacts when you know them (@-mention files, symbols, docs), pull external context via MCP (Jira, Confluence), and exclude sensitive or irrelevant paths with ignore controls. Start from the task and the system boundaries, not from a wall of text.

3 · Change-shaping discipline — "done" ≠ "ready to merge"

The phrase to repeat: "Agent completed the task" does not mean "the change is ready to merge." Shape every change toward reviewability: small diffs, explicit constraints, tests as verifiable targets, isolated branches/worktrees, plan-before-implement, and a clear handoff to human review. The explicit anti-goal is the one-enormous-AI-rewrite PR no human can responsibly approve.

4 · The agentic surface — each step up in autonomy needs a step up in guardrails

Know what runs where, and which admin controls and audit visibility apply at each layer. The mental model is a staircase: as you move from tab-complete to autonomous cloud agents, autonomy rises — and so must the guardrails, in lockstep.

The four prompt patterns worth memorizing verbatim

These encode change-shaping discipline directly. Practice them until they're muscle memory — they double as demo narration on Day 7.

The capability × SDLC-phase one-pager (your whiteboard asset)

Map each Cursor capability to a lifecycle phase and to the enterprise control that governs it. This is what you draw from memory when someone says "show me where this fits."

AI-assisted review, testing, CI debugging & anti-patterns

Design AI assistance around independent verification and existing PR controls — and know exactly how teams break trust.

The unit of trust in an enterprise is the PR. Everything Cursor does should land as a well-scoped, well-described, well-tested PR — so that nothing downstream of the merge has to change. Day 5 is about adding AI as an independent signal inside the review process the team already trusts, never as a replacement for required human approval — and about naming the ways teams destroy trust before anyone asks.

1 · Layered review — AI is one independent signal, not the gate

Review in a serious org is layered. Each layer catches a different class of problem, and in regulated orgs the final human approval is mandatory — separation of duties survives intact. AI slots in as an extra, independent pass that improves what reaches the human, not as a substitute for them.

2 · Test generation with verification discipline

The trap: generated tests that mirror the implementation instead of asserting intended behavior — they pass, prove nothing, and lock in bugs. The discipline: tests must assert intent; write characterization tests before a refactor to pin existing behavior; treat coverage as a gate input, never the goal. Coverage-as-goal is how you get 90% coverage of meaningless assertions.

3 · Cursor in the CI loop — the bright line

Cursor's CLI/agent can triage failing builds from logs (/debug), generate tests to clear coverage gates, and draft fixes as normal PRs; it can run headless inside controlled automation. The bright line you must articulate clearly:

The 5-step CI break-fix workflow you'd teach a customer team

1. Summarize the failure — have the agent read the logs and state what failed, citing evidence.
2. Separate primary from secondary — one root cause usually cascades; isolate it from noise.
3. Reproduce — propose the minimal reproduction steps before touching code.
4. Identify likely causes & state uncertainty — ranked hypotheses, not false confidence.
5. Smallest safe fix as a PR — minimal diff, tests added, normal review path.

4 · The anti-pattern taxonomy — know ~9 cold, each with its guardrail

A candidate who says "here's how teams misuse this and how I'd prevent it" reads as field-experienced. One who only lists features reads as a fan. Learn each anti-pattern as a triple: the failure → who loses trust → the preventing guardrail.

Discovery, value mapping & the 90-day pilot

Diagnose before demonstrating; then turn a useful tool into a controlled organizational change. The core of the job.

Everything before this was preparation; this is the job. A field engineer who leads with a demo is a sales engineer doing it backwards. You diagnose first — uncover how work moves, where it waits, what security needs, and who decides — then prescribe a bounded, measurable, governed pilot. The deliverable from this day, a 90-day rollout plan for a SOX-constrained 200-dev org, is your single best interview asset.

1 · A discovery framework you own — and label everything

Run discovery across seven dimensions. For every answer, tag it fact hypothesis unknown — that labeling discipline is what separates discovery from a pitch in disguise.

2 · Value mapping — pain → capability → metric, per persona

This is where Day 1's persona map and Day 4's capability map combine. For each persona, trace a line from their pain to a Cursor capability to a metric they'd accept. Then translate it for the economic buyer in engineer-hours, cycle time, and new-hire time-to-first-commit — the only dialect that funds a deal.

3 · The maturity ladder — stage capabilities, not just users

The subtle rollout insight: most people stage users in waves. You also stage capabilities in rungs. Different teams advance at different rates, and you never lead with the highest-autonomy rung in a low-trust environment.

4 · The 90-day pilot for 100–500 engineers

Representative-but-motivated cohort (2–3 teams including one legacy codebase). Guardrails day one. Enablement you can cite from Box. Baselined metrics. Pre-agreed expand/modify/pause/stop criteria. Here's the shape:

Discovery question bank — the openers that work

Demo, objections & the interview loop

Performance day. Combine discovery, governance, workflow, and value into credible field execution.

Everything compounds here. The demo, the objection handling, and your point of view are where six days of system-thinking either land as credible field execution or evaporate into a feature tour. The bar: if your audience walks away remembering features, you failed. They should be able to retell the problem, the workflow change, the preserved controls, and the next decision.

1 · Demo craft — anchor on their world, not a todo app

Anchor on their stack and a realistic repo (a 15-year-old Java monolith, never a toy). Structure every segment as tell → show → tell, and run the whole demo on one arc:

The 15–20 minute Northstar demo, in order

1. Jira-style ticket — business context, acceptance criteria, constraints, out-of-scope.
2. Explore current behavior (Ask mode) — read-only, cite files, separate fact from assumption.
3. Reviewable plan (Plan mode) — smallest change, unknowns surfaced, you approve before code.
4. Small bounded change under Project Rules — show where the rules changed the output.
5. Meaningful tests — asserting intent, then run them.
6. Local diff review → PR with risk & test evidence in the description.
7. Bugbot review layered under the required human reviewers.
8. Triage a deliberately failing CI check → smallest safe fix.

2 · Objection fluency — the canonical seven, concede first

Answer each in ~30 seconds, and always concede what's true before you counter. The concession is what makes the counter land; skip it and you sound like a brochure.

3 · Your 90-second point of view

Interviewers remember a thesis and forget feature recitals. Have an opinionated, specific, yours view ready. A strong default, in your own words:

Demo design rules (the checklist)

Capstone, the interview spine & self-assessment

The structures you fall back on when a question is ambiguous — and the drills that prove you're ready.

The one-page interview spine

For any ambiguous enterprise question, answer in this order. When you're nervous, this sequence is your safety rail — it forces you to diagnose before you prescribe, exactly like the job.

The 10 capstone drills (spoken, 10–15 min each)

Have your second assistant challenge assumptions and ask follow-ups, then grade on enterprise realism, technical accuracy, honesty about limits, persona-awareness, and structure. Pass bar: 8/10 fluent with specifics — named controls, named Cursor features, named metrics. Each drill maps to the day that arms it.

Final self-assessment

Score each 1–5; anything under 4 is a follow-up target for the morning. Tick the ones you can already do fluently, out loud, with specifics.

Portfolio artifacts — your interview evidence

Referencing these unprompted ("I built a 90-day pilot plan for a hypothetical SOX-constrained 200-dev org — here's how I structured the guardrails") beats any credential. Build them as you go.