Demo, objections & the interview loop

The demo is not a feature tour. It is a risk-removal exercise performed live. Every minute you spend showing speed without showing a control is a minute you spend confirming the buyer's fear. Walk in believing that and your whole rhythm changes.

The people in the room have seen a hundred AI demos that all looked the same: a todo app scaffolded in ninety seconds, a wave of applause, and then nothing they could ever ship. Your job on performance day is to be the opposite of that — to look boring in the most reassuring way possible. Reviewable. Governed. Evidenced. The wow comes from the fact that a serious enterprise change just happened inside their guardrails, not from raw token velocity.

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

If you demo on a fresh Next.js scaffold, every senior in the room mentally files it under "toy" and 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 build that takes nine minutes, a test suite with flaky integration tests. 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 mode, 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, and 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. You open on a pain the audience feels, show the workflow that addresses it, surface the guardrail that keeps it safe, point at the metric it moves, and then — this is the non-negotiable part — you name the control by its enterprise term. Not "see, it's safe." You 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.

There is one canonical run that hits every persona at once: the developer sees speed, the staff engineer sees reviewability, security sees guardrails, and 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, and at each station you surface the control that lives there. Below is the order; 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 with a blank prompt — this signals you respect their value streamThe end-to-end path a change takes from idea to running in production..
2. 2Explore in Ask mode. 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 is 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 see 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, humans approve. Bugbot doesn't merge; it surfaces. (June 2026: ~90% of runs finish in under 3 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 is the proof that the pipeline catches problems — and that the human, not the agent, holds the merge key.

The most trust-building moment in an enterprise demo is when something goes slightly wrong — and you recover calmly, in 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 either a toy problem or a rehearsed lie. Seniors have written enough code to know that's not how real work goes. So you engineer a moment of imperfection: the agent's first plan misses an edge case, or its initial change trips a Project Rule, or 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 context. Show the agent is steerable, not 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 not attacks to be deflected — they're buying signals to be honored. The master move on every single one is the same: concede what's true first, then counter. The concession is what earns you the right to be heard.

The seven, with the concede-first answer

Two skills separate people who pass the loop from people who don't: the ability to compress your whole worldview into 90 seconds, and the instinct to close by interviewing the buyer instead of 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 that uses the spine as its skeleton: the shift is from ungoverned velocity to governed velocity; the unit that matters is throughput per governed engineer; the way you get there 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 (audit log, 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 end by turning the table into a discovery conversation. 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