A coding model learns to make watercolor-style images

The painting experiment trains a coding model to produce artwork through JavaScript drawing tools. Its open implementation uses TRL and OpenEnv, with model execution, scoring, and training artifacts connected across Hugging Face services.

The interesting shift is the target of the generated code. Instead of checking only whether a program runs, the loop evaluates the image that program produces. That makes reward design central: a model can improve the measured objective without necessarily matching every human aesthetic preference.

Begin with the published examples and environment rather than a full training launch. Inspect the reward setup and reference pool, then compare outputs from the different reward mixes. The author distinguishes this open reproduction from the original artistic project and credits that inspiration.

Why generating a program is a different creative task

A model that produces drawing code does not directly choose every final pixel. It chooses instructions that a renderer interprets: shapes, positions, strokes, colours and their order. That extra layer can make a result editable, but it also introduces another class of failure. A plausible-looking program may not run, and a valid program may draw something unrelated to the intended composition.

Imagine asking for a simple flower study. A useful first target is not a perfect painting. It is a program that produces a visible flower, stays within the canvas, and finishes reliably. Only then does it make sense to compare qualities such as balance, variation in colour or the softness of the result. Otherwise, artistic scoring can conceal basic execution problems.

Separate three kinds of feedback

The first question is whether the program executes. A controlled rendering environment should have a time limit and capture errors. Rendering untrusted generated code on a personal machine is not the same as evaluating text; the environment should expose only what the task needs.

The second question is whether the image matches the request. A visually appealing landscape is still a failure if the request was for a close-up flower. Keep subject adherence separate from style so that a training signal cannot reward attractive but irrelevant output.

The third question is whether the result has the desired aesthetic. This is the hardest signal to define. A scoring model, a reference-image comparison and human preference can disagree. Treat the chosen score as an imperfect measurement, not a complete definition of creativity.

Build a comparison you can trust

Before any training, render a fixed set of prompts with the starting model. Save the prompts, generated code and images. Repeat the same exercise after training with the same rendering conditions. Include prompts that differ from the examples used to construct rewards; otherwise the experiment may demonstrate familiarity rather than broader improvement.

For a small project, a contact sheet is often more informative than one showcase picture. Put successful, mediocre and failed outputs together. Check whether the trained model became more repetitive, whether it relies on a narrow colour palette, and whether execution failures increased as the programs became more elaborate.

What this opens up

Code-based image creation is especially interesting when someone wants to keep editing the result. Changing a colour or moving a shape may be easier in a program than in a finished bitmap. That does not make it a replacement for every image-generation method. The useful lesson is narrower: an executable environment provides measurable feedback, and that feedback can connect language-model training to creative tools while leaving an inspectable artifact behind.