From pull request to product demo, automatically

The feature shipped Tuesday. By Thursday someone in sales wants to demo it. The product is real, the screens exist, but the walkthrough that shows them off doesn't — and the person who understands the change best is the engineer who wrote the pull request, not the SE who has to present it.

That PR is, it turns out, an almost perfect brief for a demo. It says exactly what changed, where it changed, and usually why. So we taught MyAISE to read one.

Connect GitHub, pick a pull request, and MyAISE drafts a working walkthrough — overlays, spotlights, driven actions, the whole palette — pointed at the real screens the PR touched.

The diff is the seed; your source is the context

A diff is great at telling you where something changed and useless at telling you how to demo it. The patch for a new settings panel shows you twelve changed lines in a component file. It doesn't tell you the route that renders it, the label on the button that opens it, or whether the thing you want to spotlight has a stable data-testid or a class name that gets regenerated on every build.

So the generation isn't a single prompt over a diff. It's agentic. The model gets the PR — title, body, review notes, and the per-file patches — as a seed, and then it goes and reads the surrounding source: the components, the routes, the templates. It pulls files on demand until it understands the changed surface well enough to point at it.

Why the GitHub auth lives in the desktop app, not our cloud

Here's the part we cared about most. Reading your source means holding access to your source, and we did not want to be a company that could read its customers' private repositories — not even by accident, not even if we were breached.

The obvious architecture — broker GitHub access through our server — fails that test. If the cloud held the GitHub App key or your access token, then a breach of our infrastructure would expose every connected customer's code, and we'd technically be able to read it silently. We didn't want that capability to exist.

So it doesn't. The GitHub connection lives entirely inside the desktop app, using a GitHub App + OAuth Device Flow. The device flow is built for clients that can't keep a secret: it uses only the app's public client ID, never a client secret. You approve the app in your browser, GitHub hands a read-only, user-scoped token back to your machine, and that token is encrypted at rest with the OS keychain (Electron safeStorage). It is scoped to exactly the repositories you install the app on, and you can revoke it from your GitHub settings at any time.

MyAISE's servers hold no GitHub secret and no GitHub token. We cannot read your code, because the credential that would let us never leaves your laptop.

BYOK: your source's only three stops

The same logic applies to the AI. Understanding a PR means sending source to a language model — so the question is whose model. This is a Bring-Your-Own-Key feature: it calls the LLM provider you've configured (Anthropic, OpenAI, Gemini, or a local Ollama), with your key, from your machine.

"With BYOK, your repo source goes only to GitHub, your own machine, and the LLM provider you chose — never to MyAISE."

— The privacy line we can actually stand behind

We're deliberate about the wording. We don't say "your code never touches the cloud" as a blanket claim, because MyAISE does offer a hosted-AI option elsewhere in the product. This feature specifically uses BYOK so the claim is exact: your source goes to GitHub, your machine, and the model you picked. That's it.

Three phases: explore, storyboard, bind

A good walkthrough is a story, not a pile of tooltips. Asking a model to one-shot the whole thing produces exactly that pile. So generation runs in three passes:

• Explore. The agent reads the PR source and drives a live browser of your app — navigating, inspecting the real DOM — to build a map of the feature's actual pages and the elements that matter. It only ever uses routes it found in your source or on a page it loaded; it never guesses a URL.
• Storyboard. With that map in hand, one pass weaves a coherent click-through and chooses the right overlay for each beat from the full palette — a banner to set the scene, a spotlight on the new panel, a driven action to click through, a slideout for the detail, a number badge to count the steps. Not ten identical modals.
• Bind. A final pass walks each page on the live app and resolves every overlay to a real, unique CSS selector — preferring stable test IDs, falling back to roles and labels, targeting the label of a radio rather than the tiny input. Anything it can't anchor cleanly degrades to a centered card instead of pointing at nothing.

What you get, and what you do next

The output isn't a finished demo you have to accept blindly — it's a strong draft in the studio. Every step is a real DemoStep with overlays already placed and selectors already bound, ready for you to read through, tweak the copy, drag an overlay, or delete a beat that doesn't land. The walkthrough plugs straight into the rest of MyAISE: it runs against data faked by your ruleset, it can be shared as a viewer link, and on Team it's covered by self-healing so it survives the next release.

Generating demos from pull requests is free — it only asks for a MyAISE login and one of your own LLM keys. Download the Mac app, connect GitHub, and turn your next merged PR into a demo before the feature's even announced.