Product demo for AI engineers: Let your agent build and maintain it

Ship weekly for a quarter and your demo goes stale roughly thirteen times. That means thirteen rounds of recapture work that add nothing new, just bring the demo back to parity with a product that has already moved on. That is the real cost for AI engineers who ship from a repo but still use a SaaS capture tool to show the product.

The fix is structural, not tactical. If your product ships from a repo, the demo should too. Code-owned demos stay current in a way screenshot flows never will, because the artifact and the source of truth live in the same place.

What a product demo for AI engineers actually is

Why the demo belongs next to the app

A product demo for AI engineers is a code-owned artifact that ships alongside the product, not a recording trapped inside a separate SaaS. When the UI changes, the demo changes with it because the demo is built from the same components, routes, and data model as the app itself.

That matters the moment you start shipping iteratively. A SaaS-captured screenshot is frozen at the instant you took it. Your app keeps moving. The gap between them is the maintenance cost that piles up with every release.

The difference between a demo and a screenshot tour

A screenshot tour is a static sequence of images with hotspots. It cannot react to code changes, so every affected screen needs a fresh capture pass. A code-native demo is a live render: update the component, re-prompt the agent, and the demo reflects the new state without touching an editor.

A repo layout makes the ownership boundary obvious:

The `/demo` directory is part of the repo, not an afterthought. PostHog's take on giving S-tier demos makes the same point from the other direction: a demo that does not match the real product is worse than no demo, because it sets expectations the product cannot meet.

Put the demo in your repo, not in a separate tool

A folder structure you can keep alive

A repo-native product demo lives in a dedicated directory with clear ownership. One pattern that works for small teams:

Each flow file owns one path through the product. The data directory owns the fake records. Locales are flat files the agent can update without touching the flow logic. One person owns `/demo` the same way one person owns `/docs`.

What breaks when the demo lives elsewhere

When the demo lives in a SaaS tool, ownership splits the moment the product ships. The engineer who built the feature does not have access to the demo editor. The PM who owns the demo does not know which screens changed. Updates slow to a handoff cycle.

The Vercel engineering blog describes the same failure mode for any artifact that lives outside the codebase: once the source of truth and the artifact diverge, someone has to manually reconcile them on every release. For demos, that reconciliation is recapture. Colocation removes the handoff.

Generate the first interactive flow from one prompt

What the prompt should ask the agent to build

A good first-capture prompt has four parts: the entry state, the success state, the one or two branches that matter for the audience, and the synthetic data to populate it.

Short. Specific. Tied to real paths in the repo. The agent has enough context to build something runnable.

Where the agent should stop and hand back control

The agent can draft the flow, wire the synthetic data, and stub the navigation. It should stop before writing the CTA logic, the lead capture form, and any copy that makes a product promise. Those three touch the buyer's decision, so they need a human eye.

Review the output for accurate feature representation, correct entry and exit states, and any place the flow implies a capability the product does not have yet. The agent is fast at structure. You are the check on truth.

The shortest path from prototype to pitch asset

A working demo in `/demo/flows/investor.tsx` is already shareable. Wrap it in a route (`/demo/investor`), add a `<meta>` title, and deploy to a preview URL. That is the pitch asset. No second platform. No export step. No re-recording.

The Stripe agent benchmark shows the same pattern: agent-generated code is a starting point, not a finished product. The value is the 80% it handles automatically; the remaining 20% is where your judgment matters.

Use synthetic data, narration, and localization without making the demo fake

Synthetic data that feels real enough

Synthetic data should look like real data without being real data. That means realistic names, plausible numbers, and states that reflect actual product behavior, not placeholder text like "Company Name" or "User 1."

A `/demo/data/projects.json` file might contain three records: one active project with recent activity, one stale project with a warning state, and one empty project at the start of onboarding. Those three states cover most of what the demo needs to show without touching production.

Keep the data in version control. When the product's data model changes, the agent updates the synthetic records in the same commit.

AI narration that matches the flow

AI-generated narration works when it is written against the actual flow steps, not against a generic product description. Feed the agent the flow file and ask it to write one sentence per step: what the user is doing and why it matters.

The result reads like a walkthrough, not a marketing script. Each line is tied to a specific screen state, so if the flow changes, the narration changes with it in the same pass.

Localization that does not fork the demo

Localization strings live in `/demo/locales/en.json`, `/demo/locales/de.json`, and so on. The flow file references keys, not hardcoded copy. Switching language is a prop change at the entry point. It does not create a separate flow file or a separate demo branch.

When a new market matters, the agent translates the locale file. One flow. Multiple languages. No forking.

Add personalization, lead capture, and a CTA that feeds your site

Personalization that changes the demo path

Personalization at the demo level means swapping the company name, the industry-specific example, or the relevant feature branch based on a URL parameter or a form input at the entry point.

The flow reads those params and loads the matching synthetic data and copy. The underlying flow logic does not change, just the records and the strings.

What to ask for before the handoff

Ask for one thing: an email address, or a company name if you are doing account-based outreach. Asking for five fields before the demo loads kills conversion. The goal is enough to route the lead, not enough to qualify them completely.

A pre-demo gate is a form in `/demo/components/Gate.tsx` that writes to your CRM or a simple webhook before rendering the flow. Keep it out of the flow logic so it can be toggled off for public demos without touching the flow file.

How the demo should hand off to your website

The demo ends with a CTA that routes back to your product's signup path or a calendly link. The CTA component reads from the same params the personalization used, so "Book a call with Acme" is a one-line change, not a new demo.

The HBR piece on products that grow with their users frames this well: the handoff is where the demo's job ends and the product's job begins. Make the transition direct. One button. One destination. No ambiguity about what happens next.

Update the demo with an AI coding agent when the product changes next week

What the update pass should actually do

The maintenance loop has four steps: identify what changed in the product, update the affected flow files, regenerate any narration tied to changed steps, and review the result against the live product.

The agent handles steps one through three. You handle step four. That division keeps the update fast without removing human judgment from the output.

Where drift shows up first

UI labels go stale first: button text, nav items, modal titles. They are easy to miss in a screenshot tool because the change is visual and the recapture is per screen. In a code-native demo, a label change in the design system propagates automatically if the demo uses the same component.

Flows go stale second, when a feature moves behind a paywall, gets renamed, or changes its entry point. Those require a flow file edit, not just a label swap. The agent can do it from a one-line prompt: "The analytics panel is now behind the Pro plan — update the investor flow to show the upgrade prompt instead."

What to automate and what to keep manual

Automate label updates, data refreshes, narration regeneration, and localization string updates. These are mechanical, and the agent is faster and more consistent than a human editor.

Keep manual the CTA logic, the product promise in the narration, and any branch that implies a capability the product does not fully have. These are trust-sensitive. A buyer who sees a demo that overpromises and then uses the real product notices the gap immediately. The agent does not know what the product cannot do. You do.

Where Inkly comes in

The structural problem this article describes, thirteen stale demos a quarter, recapture work that produces nothing new, ownership that splits the moment the product ships, comes from the demo living inside someone else's SaaS. The fix requires a demo that is code you own, lives next to your product, and can be updated with a prompt instead of a re-record.

Inkly is built on that premise. You capture the first demo with a Chrome extension, then the demo becomes code in your repo, not a recording in a vendor's cloud. Your coding agent (Cursor, Claude, Codex) authors and maintains it. A UI change next week means a prompt, not eight screens to recapture. The tradeoff is plain: Inkly requires a coding agent and a repo workflow, so if you are not already operating that way, the bring-your-own-agent path adds setup. But if you are, the demo lives in your repo the same way your docs do.

FAQ

Q: How can a founder or product engineer create a product demo that stays in sync with the real product codebase?

Put the demo in the repo under a `/demo` directory that uses the same components and design system as the app. When the product changes, the demo changes in the same commit, or the agent updates it from a diff. A demo that lives in a separate SaaS tool falls out of sync the moment shipping starts because there is no shared source of truth.

Q: What is the fastest way to turn a working prototype into a pitch-ready interactive demo with minimal process?

Write a prompt that specifies the entry state, the success state, and one or two branches, then let the agent build the flow file. Deploy it to a preview route and share the URL. The step people overcomplicate is the export. If the demo is already in your repo and deployed to a preview URL, it is already shareable. No second platform needed.

Q: How do you use an AI coding agent to build and maintain the demo without introducing drift?

The agent drafts structure and updates labels, data, and narration. The engineer reviews the output against the live product before the demo is shared. Drift enters when the agent updates the demo without a human checking that the flow still matches what the product actually does, especially around feature gates, paywalls, and any branch that implies a capability the product does not have yet.

Q: Should you use synthetic data, a self-contained demo environment, or an agentic demo for your use case?

Synthetic data works for most cases. It is fast to set up, easy to version, and safe to share publicly. A self-contained demo environment, a sandbox with its own database, makes sense when the demo needs to be interactive in a way that synthetic JSON cannot support, like a multi-step workflow that writes state. An agentic demo, one that responds to free-form input, makes sense when the product itself is agentic and a static flow undersells it. Start with synthetic data and move up only when the static flow breaks down.

Q: How do you update demo flows when the product changes every week?

Run a maintenance pass after each release: diff the product changes against the flow files, prompt the agent to update affected screens and narration, then review the result. Keeping the demo in the repo means the diff is visible in the same PR, so you can see exactly which flow files need attention before the release ships.

Conclusion

Build the demo once, next to the app, as code you own. Then let the agent keep it current, not by re-recording, but by re-prompting after each release. The thirteen stale demos a quarter become zero, because the artifact and the product move together.

Pick one flow in your product this week, investor pitch, customer onboarding, or a single feature walkthrough, and rebuild it as a repo-owned demo path. Then run one update pass after the next UI change. That pass is the test: if it costs a prompt, the structure is right. If it costs a re-record, the demo still lives in the wrong place.