Execution-verified coding workflows

A code assistant that asks for edge cases before it writes the first line looks newly practical for workflows where wrong answers are expensive. SolidCoder shows the clearest leverage point: removing the edge-case planning step drops GPT-4o on CodeContests from 77.0% pass@1 to 53.3%, a much larger loss than removing later repair steps. The same paper pairs that front-loaded planning with property-based assertions, sandbox execution, and retention of every failing test found during repair.

The build here is narrow and testable: add a pre-write edge-case pane to an IDE or PR bot for bug-prone functions, then auto-generate property checks and keep a growing regression set through each model revision. Teams maintaining parsers, data transforms, pricing logic, and API adapters would care first because they already pay for hidden boundary-case failures after merge. A cheap validation pass is to run the workflow on a fixed set of production bug tickets and compare first-pass correctness and bug reintroduction rates against a standard prompt-only assistant. The cost is higher token and API usage, so this fits review-critical code paths better than routine boilerplate.

Teams building interactive web products can now evaluate agent output with browser-run health checks instead of relying on compile status and spot review. OpenGame is a useful template because it treats generated software as a running system: it uses reusable project skeletons, a stored debugging protocol, and repeated headless verification, then scores outputs on Build Health, Visual Usability, and Intent Alignment. On 150 prompts, OpenGame with Claude Sonnet 4.6 beats Cursor with the same model by about six points on each metric.

The concrete workflow change is to add a browser-executed scorecard to internal tools that generate dashboards, microsites, onboarding flows, or lightweight educational simulations. A first version does not need full game generation. It needs page load checks, console-error capture, visible-element assertions, and a simple rubric for whether the output matches the request after interaction. The immediate user is any team already demoing agent-built front-end work and struggling with broken wiring across files, assets, and state. A cheap check is to take a backlog of recent front-end tasks, run the assistant three times per task, and compare acceptance rates before and after adding browser execution plus a small repair loop.

Prompted tests should sit next to generated code when teams want assistants to keep those tests intact through generation and editing. The doctest study makes this operational, not stylistic. Across 830-plus generated files and 12 models, inline Python doctests were preserved almost perfectly and kept high correctness, while separated Rust test blocks produced large model-to-model swings, including several Claude Opus versions that removed every provided test block. The same study also shows that temperature 0 does not guarantee repeatable outputs.

A practical build is a repo helper that rewrites generation prompts and temporary work files into inline test form before model calls, then expands them back into the team's preferred test layout after acceptance. This is most relevant for scaffold generation, utility functions, and migration scripts where teams already ask models for implementation plus tests in one pass. The cheap check is simple: pick one task family, run the same prompts with inline and separated tests across the models your team uses, and measure test preservation, pass rate, and output stability over repeated temperature-0 runs. If a model keeps dropping tests, the problem may be prompt structure before it is model quality.