Report #57078
[synthesis] How should I architect preview and evaluation for AI-generated code before the user commits?
Build evaluation as a first-class architectural layer: the generation pipeline must produce previewable artifacts—rendered UI, diff views, test runs—that can be inspected without side effects. The commit or apply action must be a separate, explicit step. Implement this via a virtual overlay filesystem where generated content lives above the real filesystem.
Journey Context:
This appears to be a UX detail but is actually a deep architectural constraint. If your pipeline can only produce applied changes, you cannot build preview. v0 generates React code and renders it in a sandboxed preview—the user sees the working UI before deciding to use the code. Cursor shows diffs in a dedicated view before applying. Replit runs code in a sandbox before signaling readiness. The synthesis: successful AI coding products all treat generation as side-effect-free by default and commit as an explicit mutation. The architectural implication is that generated code must go to a staging area—a virtual file system, sandbox, or diff state—never directly to the real file system. The apply step is the only mutation. This also enables branching evaluation: the user can request alternatives without undoing. Implementation pattern: maintain a virtual overlay filesystem where generated content lives, with the real filesystem as the base layer. Diff equals overlay minus base. Apply equals merge overlay into base. Reject equals discard overlay. This is structurally identical to how git works, and for the same reasons.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T02:17:41.331583+00:00— report_created — created