phygen

An agent-driven research environment for evolving executable artworks, with versioned code, visual feedback and an evaluation pipeline that can be inspected.

2026

Coding Agents · Evaluation Design · Creative Tools

Year: 2026
Role: Concept, system design, development
Tools: Coding Agents, Evaluation Design, Creative Tools

Updated 20 October 2026

Phygen's early interface showing a parent simulation, three agent-generated variants and the coding agent's explanation of its source changes — Early tree prototype: a parent program, three generated variants and the agent's rationale. Later iterations replaced this branching interface with a forward chain.

Independent research / System design, agent orchestration, evaluation and interface

I built phygen to explore how a coding agent can change a visual system over many iterations without losing the link between source code, rendered output and evaluation.

The starting point is a seeded physarum simulation: particles sense and deposit trails, producing a changing transport network. Agents edit its JavaScript simulation, renderer and configuration. The result is a lineage of executable programs, not a folder of generated images.

Node.js / React & TypeScript / SQLite / three.js / Playwright

Fine white trails branching from a dense central transport network against a black field — Radial transport network

Dark branching trails radiating across a white field, with fine marks gathered at the perimeter — Light-field network

Two saved versions of the simulation, with different approaches to density and contrast.

From a judging tree to a forward chain

Early iterations generated three variants per step and used a blind vision judge to rank their captures. A subsequent version added novelty thresholds and an archive for choosing parents. This exposed the central design problem: a more elaborate selection procedure was not, by itself, a better definition of artistic quality.

Two colored cellular network variants in the early graph interface, with the selected agent's source-change explanation in the right-hand inspector — Tree-era comparison: candidate renders and source-change explanations share one graph, so visual differences can be read alongside the agent's intent.

I then removed the ranking stage. Each step made one child of the newest working version and retained it if technical checks passed. That reduced candidate fan-out and made the history easier to follow, without treating a model’s preferred image as proof of progress.

Two research iterations: three variants ranked by a vision judge, and one candidate retained after technical validation — Two research iterations, not an A/B benchmark. The forward chain removed automatic ranking; it did not guarantee aesthetic improvement. Open the diagram to inspect it.

Make every change inspectable

Each step works on a copy of its parent, receives recent rendered frames, and is checked against the allowed edit surface and package contract. The controller publishes an immutable, content-addressed snapshot before rendering a fixed-seed, fixed-step sample.

A working copy passes validation, is published by content hash, is verified and then rendered under a fixed seed and step count — The capture comes from the published snapshot, not a workspace that may still be changing. Source hashes tie the visual result to the code that actually ran.

SQLite connects versions, captures, agent notes and usage. A replayable event stream exposes progress in the interface. Correctable faults get one bounded repair attempt; a failed step does not replace the last working version.

A large violet and orange network render beside a live agent feed listing file reads, edits, writes and usage counts — An early run in progress: the active render stays beside the live agent feed, file operations and usage counters.

Generated code is treated as untrusted. The browser preview uses a separate artwork origin, a script-only sandboxed iframe and a restrictive content security policy. This is a browser boundary, not a substitute for the stronger container capture mode.

An overview of captured network variants in light and dark palettes, with candidate states and an agent explanation visible in the original tree interface — Captured versions in the original tree interface. The overview makes repeated structures and changes in palette visible across a run.

Calibrate the gate, not a claim about taste

Later work added image measurements for coherence, novelty and failure diagnostics, with a blind vision judge reserved for borderline cases. Thresholds were fitted from 124 saved versions, captured at 1024 x 1024, seed 1337, step 1000.

The gate defaults to warning mode: it records verdicts without rejecting versions. Evaluation becomes a visible, adjustable layer rather than an unexamined source of authority. This calibration uses known-kept frames, not a held-out human-preference benchmark. Cross-driver image reproducibility also remains unmeasured.

A dense web of fine gray filaments enclosing irregular cells against black — Cellular mesh

Pale green and white network fragments layered across a dark field, interrupted by open cells and a luminous green accent — Fragmented network

Branching white trails and luminous clusters layered over violet, red and orange fields — Layered trails

Translucent cyan and blue cellular layers crossed by fine green trails — Cyan cellular field

A blue geometric field of polygonal cells crossed by a fine yellow-green network — Geometric structure

A dense web of luminous white and cyan trails woven through angular blue, violet and pink fields — Interwoven fields

Selected saved versions show the range of the evolving program, not a ranking of artistic quality.

What the project established

The useful unit of creative agent work is not the prompt. It is the executable change together with its render, provenance, cost and failure record. phygen brings those pieces into one environment so that the system can be debugged and its evaluation choices questioned.

Next project: 1275K →