2 min lesson
The 15–20 minute Northstar demo, in order
Walk through the important items in "The 15 to 20 minute Northstar demo, in order" and give the practical point of each.
Step 1 of 3
One canonical run hits every persona at once:
- The developer sees traceable speed from ticket intake → read-only Ask-mode exploration.
- The staff engineer sees reviewed intent in the Plan → a small change held inside Project RulesVersion-controlled instructions in the repo that every Cursor agent interaction inherits, so standards are encoded once. Press Enter for the full definition..
- QA and security see a meaningful test → a PR with an auditable diff and evidence.
- The auditor and release lead see BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. under human review → a failing CI gate that is diagnosed and fixed while a person keeps the merge key.
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. Keep the order simple: ticket → Ask-mode explore → reviewable Plan → small change under Project RulesVersion-controlled instructions in the repo that every Cursor agent interaction inherits, so standards are encoded once. Press Enter for the full definition. → meaningful test → PR with evidence → BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. plus human review → failing CI triage. At the last station, diagnose the failure, rerun or fix the check and leave the merge decision with the human.
Learn more
Full explanation
The 15–20 minute Northstar demo, in order
- 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. Press Enter for the full definition..
- 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. Press Enter for the full definition.. 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. Press Enter for the full definition. of the change. No edits yet. This is the 'understand before you touch' beat that wins seniors.
- 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.
- 4Make a small change under Project RulesVersion-controlled instructions in the repo that every Cursor agent interaction inherits, so standards are encoded once. Press Enter for the full definition.. Keep the change tight and let the audience watch the agent constrained by
.cursor/rules: coding standards, forbidden patterns, architectural boundaries it cannot cross. - 5Write meaningful tests. Not snapshot fluff. A test that actually pins the behavior you changed. This is where you separate from 'AI writes garbage.'
- 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.
- 7Run BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. 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.)
- 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.
Learn more
Optional practice