Code Is Not the Artwork

A common misconception in generative art is the belief that the artwork is the code itself. In reality, code is often not merely a tool but a medium. Just as paint is to a painter, code serves the same role in this form of production: a component of the process, but not the final outcome.

Reducing an artwork solely to the tools used to create it can be misleading. Just as we would not equate an oil painting with tubes of paint, reducing an algorithmic work to its source code alone creates an incomplete perspective.

In this context, code defines a set of rules and creates a field of behavior. However, the resulting work often becomes visible through the behaviors generated by this structure. Color choices, compositional decisions, the boundaries of randomness, the data being used, and the relationships established by the artist form an aesthetic decision-making space that extends beyond the code itself.

Sol LeWitt and the Connection to Conceptual Art

This way of thinking structurally has a strong parallel with the Conceptual Art movement of the 1960s, and especially with the practice of Sol LeWitt.

In LeWitt's Wall Drawings series, the artist does not physically intervene on the wall; instead, he creates written instructions composed of strict rules. The artwork emerges in the physical world through the application of these instructions by others.

Similarly, in this system-based approach, the written code functions as the digital equivalent of such instruction sets. The true value does not lie in the lines themselves, but in the network of relationships they create and the space of possibilities they guide.

Art as a Space of Possibilities

The same system can generate different outcomes every time it is executed. One iteration may produce intense visual complexity, while another may create a minimal composition. Here, the artist does not design a single image; instead, they construct a space of possibilities, a field containing all visual outcomes that the system is capable of producing.

In some cases, the artist selects specific outputs from this space. This selection process, made among hundreds or even thousands of possibilities, becomes an essential part of the work. At this point, the artist is not only a "generator" who creates this field of possibilities, but also a "curator" who filters the infinite universe produced by their algorithm, defines boundaries, and determines the final aesthetic direction.

Example: A Simple Rule Set

Let us consider a simple example I wrote in Processing:

String[] L= {"·", "|", "•", "–", "—"};
void setup(){size(1280,720);background(0);noLoop();}
void draw(){for(int i=0;i<1200;i++){
float x=random(width),y=random(height),n=noise(x*.005,y*.005),f=n*48+8,b=f*1.2;
noFill();strokeWeight(random(.2,3));stroke(255,30);rect(x-b/2,y-b/2,b,b);
noStroke();fill(255,40);textSize(f);textAlign(CENTER,CENTER);
text(L[(int)random(5)],x,y);}}

The outputs generated each time this code is executed are temporary and momentary manifestations of a dynamic system. The image changes with every iteration; what remains constant is not the individual outputs, but the network of relationships that generates them.

An Important Exception: The Aesthetics of Code Itself

Code itself can also carry aesthetic qualities. The aesthetics of code are not only visible in its functionality, but also in its internal structure. Concepts such as Clean Code and Elegant Code, commonly used in software development, describe not only whether a piece of code works, but also its simplicity, readability, and mathematical elegance.

However, this aesthetic quality is not the same as the art produced by the code. The elegance of code concerns how the system is constructed; art emerges through the behaviors and experiences generated by that system.

In my own practice, systems often behave less like fully designed structures and more like organisms that evolve and transform throughout the process. Writing code here becomes not only a way of implementing a predetermined idea, but also a method of discovering the idea itself.

This approach shares certain similarities with working methods sometimes referred to as "Guerrilla Coding" in the software world. Guerrilla Coding focuses on creating fast, flexible, and creative solutions; it often prioritizes the most effective solution for the current problem rather than following strict architectural plans. Within this process, shortcuts, unexpected behaviors, and even some "errors" can sometimes be viewed not as flaws to be removed, but as elements that shape the behavior of the system.

Similarly, in my own production process, code functions less as a perfectly designed closed structure and more as an evolving process shaped through experimentation, exploration, and feedback. Unexpected results or technical deviations can sometimes become part of the aesthetic decision-making process rather than problems that need to be corrected.

Beyond Code

Perhaps the more accurate question to ask is:

Is code itself an artwork, or is it the system that makes the artwork possible?

In most cases, the second option provides a more explanatory perspective. Rather than producing a single image, code defines behaviors, possibilities, and relationships. What emerges is the visible result of this underlying structure.

To understand this approach, it is not enough to look only at the screen or the editor. The essential question is how the system of rules behaves, which possibilities it opens, and what these possibilities make possible.