Demo, objections & the interview loop

The demo is a risk-removal exercise performed live, not a feature tour.

Every minute you spend showing speed without showing a control is a minute spent confirming the buyer's fear. Walk in believing that and your whole rhythm changes.

The people in the room have sat through a hundred AI demos that all looked the same. A todo app scaffolded in ninety seconds, a wave of applause, then nothing they could ever ship. Your job on performance day is to be the opposite of that.

Look boring in the most reassuring way possible: reviewable, governed, evidenced with a paper trail. The wow comes from a serious enterprise change happening inside their guardrails, not from raw token velocity.

Anchor on THEIR stack, never a clean-room toythe single biggest credibility lever

Demo on a fresh Next.js scaffold and every senior in the room mentally files it under "toy," then stops listening. The repo you drive must look like their world: a 15-year Java monolith, a Spring app with a 4,000-line service class, a nine-minute build, a test suite that fails intermittently on integration. Messy is the point. The harder and uglier the repo, the more the audience leans in, because that's the codebase they actually have to live in on Monday.

Unstructured demos drift. You start in Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code., someone asks a question, twenty minutes evaporate and you never named a single control.

The fix is two nested structures:

• A macro frame (tell→show→tell) wrapping the whole thing.
• A micro arc that every individual segment runs through and ends the same way.

The macro frame: tell → show → tell

1. 1Tell - state the claim and the control before you touch the keyboard. "I'm going to take a real ticket through to a reviewable PR and the whole time the agent is fenced by your Project RulesVersion-controlled instructions in the repo that every Cursor agent interaction inherits, so standards are encoded once.." The audience now knows what to watch for.
2. 2Show - run the workflow. Narrate what you're doing and why, not just what's on screen. Let them see the agent think, plan and get corrected.
3. 3Tell - close the loop. "So what just happened: a ticket became a reviewed PR with tests and a BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. pass and at no point did the agent step outside the rules you'd configure. The control there was the Project Rule plus the human approval gate."

The micro arc: every segment runs pain → workflow → guardrail → metric → NAME the control

This is the discipline that separates a field engineer from a demo monkey. Each chunk of the demo is a complete little story:

1. 1Open on a pain the audience feels.
2. 2Show the workflow that addresses it.
3. 3Surface the guardrail that keeps it safe.
4. 4Point at the metric it moves.
5. 5Name the control by its enterprise term.

That last step is non-negotiable. "See, it's safe" does nothing for them. Say "that's separation of dutiesNo single person can author, approve and deploy the same change. The core control AI autonomy has to respect." or "that's your ITGCIT General Controls. The baseline IT controls auditors check: who can change what, how changes get approved and how systems are run. evidence" out loud, in the words their risk committee uses.

One canonical run hits every persona at once:

• The developer sees speed.
• The staff engineer sees reviewability.
• Security sees guardrails.
• The auditor sees evidence.

Memorize it cold so you can improvise around interruptions without losing the thread.

The spine of the run is a real ticket taken to a defensible PR. You're not coding for the sake of coding. You're walking a value streamThe end-to-end path a change takes from idea to running in production. from work-intake to merge-gate, surfacing the control that lives at each station. Below is the order and the table after it maps each step to the persona it lands on and the control it names.

1. 1Start from a ticket. Pull a real Jira/Linear item into context. The work begins with intake, not a blank prompt and that signals you respect their value streamThe end-to-end path a change takes from idea to running in production..
2. 2Explore in Ask modeA read-only mode for asking questions about a codebase without changing files; the safe way to explore unfamiliar or legacy code.. Use Ask (read-only) to map the relevant code, the call graph, the blast radiusHow much breaks if a change goes wrong; the scope of potential damage. of the change. No edits yet. This is the 'understand before you touch' beat that wins seniors.
3. 3Generate a reviewable Plan. Have the agent produce a plan a human approves before code is written. The plan is the separation-of-duties artifact: intent reviewed before execution.
4. 4Make a small change under Project RulesVersion-controlled instructions in the repo that every Cursor agent interaction inherits, so standards are encoded once.. Keep the change tight and let the audience watch the agent constrained by .cursor/rules: coding standards, forbidden patterns, architectural boundaries it cannot cross.
5. 5Write meaningful tests. Not snapshot fluff. A test that actually pins the behavior you changed. This is where you separate from 'AI writes garbage.'
6. 6Produce a diff → PR with evidence. Open the diff, then the PR with a description, the linked ticket, the tests and AI-authorship tracking attached. The PR is your evidence package.
7. 7Run BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. under human reviewers. Let Bugbot review the PR and be explicit that it advises while humans approve. Bugbot doesn't merge; it surfaces. (June 2026: average review time is ~90 seconds, down from ~5 minutes.)
8. 8Triage a deliberately failing CI check. Have a CI gate fail on purpose, then show the human-in-the-loop triage. The failing gate proves the pipeline catches problems and that the human, not the agent, holds the merge key.

What each station actually does under the hood

The spine only lands if you can narrate the real product behavior at each station, not a hand-wave. Here is the mechanism behind the four stations that win or lose the room:

The most trust-building moment in an enterprise demo is when something goes slightly wrong and you recover calmly, inside their guardrails. Engineers don't trust magic. They trust people who handle the failure case in front of them.

A demo where the agent nails every prompt first-try reads as a toy problem or a rehearsed lie. Seniors have written enough code to know real work doesn't go that way. So you engineer a moment of imperfection: the agent's first plan misses an edge case, its initial change trips a Project Rule, a test fails. Then you show the loop. You correct it, it adapts, the guardrail holds. That recovery is the demo.

How to stage a recovery without it looking staged

1. 1Pick a spot where the agent realistically stumbles on their messy repo: a hidden coupling, an untested path, a naming convention buried in their rules.
2. 2Let it stumble. Don't rescue it instantly. Let the room see the imperfect first attempt.
3. 3Correct it the way a real engineer would. Refine the prompt, point at the rule, add the missing context. The audience watches the agent prove it's steerable rather than autonomous-and-hope.
4. 4Name what just happened: "That's the human-in-the-loop. The agent proposed, I reviewed, I corrected, the guardrail held. That's exactly the workflow your team would run."

Objections are buying signals to be honored, not attacks to be deflected. The master move on every single one is the same: concede what's true first, then counter. The concession earns you the right to be heard.

The seven, with the concede-first answer

The sourced facts behind each concession

Concede-first only works if the prove step is exact. Below are the load-bearing facts behind the four objections that get probed hardest. Get these right verbatim or you lose the technical buyer.

Two skills separate the people who pass the loop from the people who don't:

• Compress your whole worldview into 90 seconds.
• Close by interviewing the buyer rather than pitching at them.

The 90-second point of viewyour worldview, compressed

You will be asked, in some form, "why does this matter / what's your take on AI in the enterprise?" The answer is a rehearsed-but-natural 90 seconds built on the spine:

• The shift is from ungoverned velocity to governed velocity.
• The unit that matters is throughput per governed engineer.
• The mechanism is a value streamThe end-to-end path a change takes from idea to running in production. where the AI accelerates every station and a human owns every gate.

Land it with a proof point (64% of the Fortune 500; Box at 30–50% throughput) and a control like the audit log or separation of dutiesNo single person can author, approve and deploy the same change. The core control AI autonomy has to respect..

Close by interviewing THEM

Amateurs end a demo by asking "any questions?" Field engineers turn the table into a discovery conversation instead. You've earned credibility. Now spend it learning their constraints so your follow-up is laser-targeted. The questions you ask reveal as much competence as the demo you ran.

• "Where does code review actually bottleneck for you today - is it reviewer availability or scope of changes?"
• "Who owns the merge gate and what evidence does your audit team need to see on every PR?"
• "What's your blast-radius rule - which repos or modules would you fence off first with an allowlist?"
• "If you ran a pilot, what's the one metric that would make your VP say yes - cycle time, change-failure rate, onboarding time?"
• "What killed the last tool you tried - was it security review, senior pushback or it just wrote garbage?"

FE vs FDE: where the interview emphasis differsknow which loop you're in

"Copilot is basically free in our enterprise bundle" is the objection you cannot beat on the spreadsheet - so don't try. Concede the price, then move the entire comparison onto what the bundle can't do.

Bundled pricing is real and hard to argue with. The reframe is that you're not buying autocomplete - you're buying a governed agent: Plans, Project RulesVersion-controlled instructions in the repo that every Cursor agent interaction inherits, so standards are encoded once., BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs., Cloud AgentsAgents that run in a Cursor-managed virtual machine, check out the repo, do the work and open a pull request, then shut down, with no load on your laptop. with artifacts, audit logs. The question is throughput per governed engineer, not seat cost. But two product facts do the real differentiation work, and neither is about price.

Fact 1: model neutrality is a strategic moat, not a feature

Output quality comes down to two levers - which model you use and what context you supply, weighted roughly 60/40 or 70/30 toward model choice. Being locked to one provider's model is therefore a structural disadvantage. Cursor lets you pick Claude, OpenAI, Codex, Grok, open-source or 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. and switch in seconds as new state-of-the-art models ship monthly. A bundled single-vendor tool can't follow the frontier; you can.

Fact 2: the harness is real cloud infra, not a wrapperthe hard number that ends 'it's just a wrapper'

The OpenClaw analogy: MacBook vs build-your-own-PC

When a buyer compares Cursor's automations to a raw open-source agent runner like OpenClaw, reach for the hardware analogy. OpenClaw hands you the raw components - RAM, CPU - to build your own PC. Cursor automations are a MacBook with everything built in: more secure, runnable immediately, no assembly. OpenClaw runs on your machine and needs a computer left open; Cursor runs in the cloud with artifacts, repo-navigation tools and the best agent harness.