Workflow

Clean-Room Bug Reproduction With Disposable VMs

"Can't reproduce" is sometimes an honest finding and sometimes a confession about your own machine. Months of accumulated fixes, config tweaks, and half-remembered workarounds on your daily dev environment can mask — or alter — the exact bug a user is reporting. A disposable workspace removes that variable entirely, not by trying harder, but by not carrying any of it in the first place.

Your dev machine is a bad reproduction environment, structurally

This isn't about sloppiness — it's what any long-lived environment does over time. A library you upgraded six months ago and forgot about, a config file you patched once to work around a different issue, a system package version that's drifted from what most users actually have: none of it shows up as a decision you remember making, and any one of it can be the reason a bug that's real for users simply doesn't happen on your machine. "Works on my machine" is frequently true and irrelevant — the machine in question isn't representative of anything.

The workflow

Start from a base image, not your daily driver — ideally one that matches what the bug report actually implies about the affected system, not your own accumulated setup.
Install only what the bug report specifies — the exact dependency versions, the exact steps, nothing extra carried over from habit.
Attempt to reproduce, exactly as described. If it doesn't reproduce here either, that's real information — the bug likely depends on something the report didn't capture, not on something wrong with your usual machine.
Debug from there, once it does reproduce, with confidence that what you're looking at is the actual bug and not an interaction with six months of your own machine's history.
Discard the workspace when you're done, rather than keeping the patched-together reproduction environment around — the next bug deserves the same clean starting point, not this one's leftover state.

Why disposal matters here specifically

The temptation is to keep a working reproduction environment around "in case you need it again" — but that's exactly how a second dev machine slowly accumulates the same problem the first one had. A debug flag left flipped, a temporary patch you forgot to revert, a log level turned up and never turned back down: all fine for the bug you were just chasing, all potential noise for the next one if the environment sticks around. Discard it, and the next reproduction starts from the same clean base image again, not from wherever this one ended up.

How this differs from the QA/DevOps case

The QA/DevOps disposable VM workflow covers a related but distinct problem: systemic test flakiness, root-caused to state a test suite assumed was reset but wasn't. This is narrower and more individual — one specific bug report, reproduced once, debugged once, discarded once. The underlying mechanism is the same disposability this whole blog keeps coming back to; the trigger for reaching for it is different.