Automation & Agents

Make Your Preview Button Catch Bugs: Reuse the Production Code Path

Most "preview" features are built as a separate, approximate version of production logic. It looks convenient, but the user trusts the preview while the real output diverges. Here's how to make the preview call the exact same code path as production, swapping only a small input — and pick up a free regression test in the process.

09/23/2026 ｜ 4 min read

One Core Idea

The biggest risk in a preview feature isn’t that it’s crude — it’s that it’s a second system running parallel to production logic.

As long as the preview is written separately (even if the logic looks similar), it can always drift from the real output, and that drift is hard to spot by eye because both codebases “feel” like they do the same thing. The only real fix: make the preview call the exact function production actually executes, swapping in a small fixed input (a test string, test parameters) instead of writing a second version that tries to approximate what production would produce.

How To Do It

Step 1 | Find the core function behind production output

Locate the function or call chain that actually produces what the user ends up seeing or hearing. It usually looks like: accept a set of parameters → run the real computation / call the model → return a result.

If you’re not sure where your “production output” entry point is, paste your route/API definition to an AI and ask: “I want to add a preview feature to this system. It must generate results through the same code path as this production endpoint below, only swapping the input for a fixed test value — tell me which function to reuse and what parameters to watch for.”

Step 2 | Extract a fixed test input

Pick one fixed input that represents “normal usage” (a fixed preview sentence, a default parameter set). Every option needs to be tested with the same input so users can compare across choices.

Step 3 | Make the preview endpoint call the production function, input swapped

Add a “preview” endpoint or function that directly calls the production function found in Step 1, only swapping the input for the fixed test value. Do not write any “simulate / approximate” logic here — the moment you catch yourself writing code that “pretends” to show what the result would look like, you’re repeating the old mistake.

Step 4 | Add caching so repeat clicks don’t re-run everything

The preview result for a given option is usually fixed, so cache it after the first generation and read from cache afterward. Better UX (instant open) and it saves compute.

Step 5 | Use a background job if production output is slow

If production output itself takes time (e.g. running an AI model), the preview will be just as slow since it takes the same path. Return a job ID on submit, poll every second or two from the frontend, and show the result once it’s done — don’t leave users staring at an unresponsive button.

Step 6 | Test: confirm the preview actually equals production

Pick a few options, click preview once, then run the full production flow once, and compare the two directly. After Steps 1–5 you’ll assume they match, but only an actual side-by-side comparison confirms it.

Pitfalls You Will Hit

1. Preview is slow and users think it’s broken: if production runs a large model, the preview will be just as slow. Make sure to add the in-progress state from Step 5, plus the caching from Step 4.
2. Forgetting the cache, re-running production logic on every click: if production logic is expensive (paid API, heavy compute), a user clicking preview repeatedly by accident stacks up unnecessary cost.
3. Fixing the bug without checking how long it existed: when a preview feature accidentally catches a production bug, don’t just fix it — go back and check the blast radius, i.e. how many past production runs already produced the wrong result.

This principle was validated on a real case: a voice-cloning feature’s preview button used the browser’s built-in speech synthesis to fake a similar-sounding preview, completely separate from the real cloning logic. After switching the preview to call the exact same code as production, it not only made the preview accurate — it also caught a production bug that had been sitting there for days: a reference audio file for one voice character had somehow gotten contaminated with noise, because nobody had ever actually run that code path and listened to the result closely.

When You Get Stuck, Ask an AI

Paste this into Claude or ChatGPT, fill in your situation, and paste the full error message verbatim (don’t summarize it):

I'm a beginner adding a "preview" feature to my project. The goal is to make
the preview directly reuse the production code path instead of writing a
separate approximate version.

My system is: [briefly describe your project, e.g. a FastAPI backend + web frontend]
The production feature is: [describe, e.g. user submits data, system calls an
API to generate text/image/audio]

I'm stuck at: [where you're stuck, e.g. not sure how to share code between the
preview endpoint and the production endpoint]
If there's an error, the exact text is: [paste the full error, not a summary]

Guide me step by step, one step at a time. Ask about my current code before
giving suggestions.

One-Line Summary

Wherever you can reuse production logic, don’t write a second “close enough” version — that only sells yourself a false sense of “I tested this.” Any real gap will eventually surface as a bug your users find. Let the preview walk the production path instead, and you get a free layer of regression testing.