Ephemeral Generators Need a Review Boundary

A key consideration in the review of ephemeral generators is the boundary surrounding the generator itself. Before any generated diff reaches a repository, this boundary must be thoroughly examined. This is an architecture review, not a product tour. The reviewer assumes the workspace and model may change under them, and nothing persists unless explicitly written elsewhere. These assumptions drive all subsequent decisions.

Firstly, a free workspace should be treated as disposable by default. It can be reclaimed at any time without warning, so checkpointing early and often is essential. Secondly, the model string pinned yesterday may not accurately describe today's weights, as providers quietly swap versions. It is crucial to record both what was requested and what was received. Additionally, no assumptions should be made about egress; a sandbox layer should deny access by default rather than being implemented in the prompt.

Moreover, the repository itself is considered input that cannot be controlled. If a CONTRIBUTING.md file is present, it may contain instructions that the generator will read as text and treat as intent. This review process is mechanical and focuses on designing a pipe rather than a collaborator. The data flow involves five stages: the prompt goes in, an ephemeral workspace is created, a diff is produced, a packet is built, and a reviewer makes a decision. Crucially, nothing in this chain auto-applies to the main branch.

The script provided outlines a proposal for one run of the generator. It creates a throwaway workspace, shallow clones the repository, checks out a new branch, runs the generator with egress denied, adds all changes, generates a diff, builds a packet describing the generation run, and finally prints the packet location. The packet itself is often overlooked but provides essential context for reviewers by serving as a fingerprint and classification.