GitHub Copilot wurde zum Künstler

Dieser Artikel ist Teil der XPRT. Magazin Nr. 21

Ein wenig Hintergrundinformation

In der Ausgabe Nr. 18 dieses Magazins finden Sie meinen Artikel darüber, wie ich die manuelle 3D-Modellierung durch einen codegesteuerten Arbeitsablauf ersetzt habe – nämlich durch die Entwicklung eines p5.js-Renderers für Torusknoten, der auf einem LLM-Workflow basiert, der von einer Textanweisung zu einer plotterfähigen Konfiguration führt. Kurz gesagt: Ich bin sowohl Entwickler als auch ein großer Kunstliebhaber, und bei diesem Projekt haben sich diese beiden Seiten endlich richtig miteinander verbunden.

Die Entwicklung dieses Werkzeugs war es, die mich endgültig für die generative Kunst begeistert hat. Nicht nur visuelle Darstellungen auf dem Bildschirm – sondern greifbare Dinge. Linien auf Papier. Acryl auf Leinwand. Der Plotter verzeiht keine ungenaue Geometrie.

Nachdem ich darüber geschrieben hatte, dachte ich, ich würde eine Pause einlegen und einfach nur spielen. Keine These, kein Plan. Ich öffnete einen p5.js-Editor in meinem Browser und begann, mit verschiedenen Algorithmen zu experimentieren und Skizzen zu erstellen. Einige davon habe ich eigenständig ausgearbeitet. Bei anderen diente mir Copilot als Denkpartner – ich beschrieb, was ich wollte, erhielt einen Strukturvorschlag und wir verfeinerten ihn gemeinsam. Die meisten davon landeten schließlich auf dem Plotter.

Da ich diesen Artikel schreibe, können Sie sich sicher denken, dass die Entwicklung eine interessante Wendung genommen hat. Wohin die Experimente geführt haben, welche Rolle Copilot dabei gespielt hat und warum ich mich entschlossen habe, noch einen Schritt weiter zu gehen und einen vollwertigen Assistenten zu entwickeln – mit Agenten-Dateien, wiederverwendbaren Eingabeaufforderungen und benutzerdefinierten Anweisungen –, darum geht es in diesem Artikel.

Die Skizzen – was ich tatsächlich angefertigt habe

Lassen Sie mich Ihnen einige der Ergebnisse vorstellen, die mir gefallen haben und die ich später als Vorlagen verwendet habe, denn die Vielfalt ist ja gerade der springende Punkt.

Metaball – das Verzerrungsfeld (16. Februar 2026)

Hier habe ich mit den Konzepten von Ordnung und Chaos gespielt. Aus derselben Skizze habe ich einige Variationen entwickelt, und was Sie auf dem Bild sehen, sind drei echte Kunstwerke, die mit Acrylfarbe auf Leinwand entstanden sind. Ein geordnetes Raster bedeckt die Leinwand – strukturiert, fast mechanisch. Der Schwerpunkt lag auf Metaballs: Die Kleckse sind ausgefüllt, feste Formen, die gegen die umgebende Geometrie drücken. Der Kontrast ist der springende Punkt.

Mint – Liniendiagramm (14. Februar 2026)

Erneut der Metaball-Algorithmus – die mathematische Grundlage, die in Flüssigkeitssimulationen das Verschmelzen von Blobs ermöglicht –, doch anstatt die Blobs auszufüllen, entnehme ich Stichproben von Punkten innerhalb des Feldes und verbinde diese mittels einer „Nearest-Neighbor“-Abfrage zu einem Drahtgitter.

Sakura-Flow (18. Februar 2026)

Ein hubbasiertes Knotennetzwerk, durch das Perlin-Flow-Trails ziehen. Diese Skizze gehört zu meinen Lieblingsskizzen, weshalb ich schließlich einige Varianten davon erstellt habe.

Ein verworrenes Netz (18. Februar 2026)

Das verfahrenstechnisch komplexeste Beispiel. Zufällige Linienkandidaten werden auf die Leinwand geworfen, Schnittpunkte ermittelt, an jeder Kreuzung neue Kanten hinzugefügt, und der gesamte Graph wird physisch entspannt, bis er sich einpendelt. Drei sich überlappende Ebenen. Es wirkt handgezeichnet, obwohl es vollständig algorithmisch entstanden ist. Ich bin nie so weit gekommen, dieses Bild mit dem Plotter zu erstellen, einfach weil es für mich noch nicht fertig ist. Ich muss noch weiter daran arbeiten, damit es meiner Vorstellung hier entspricht.

Warum einen Assistenten entwickeln?

Die Vielfalt war es, die mich in ihren Bann gezogen hat. Jeder Entwurf fiel anders aus – manchmal auf schockierende Weise. Drücken Sie die Tasten „ R “, um die Samen durchzuschalten, und Sie erhalten dreihundert Variationen, von denen vielleicht zwei druckwürdig sind. Genau diese Unvorhersehbarkeit macht den Reiz aus.

Aber es geht nur langsam voran. Einen Algorithmus so gut zu verstehen, dass man ihn optimieren kann, dauert Stunden. Und jeder neue Entwurf beginnt mit denselben Standardelementen: dem Block „ CFG “, der Funktion „ regenerate() “, den Tastaturkürzeln, dem SVG-Export und dem räumlichen Hash. Nichts davon ist schwierig – es ist einfach nur ein Hindernis, gerade dann, wenn man eigentlich in den Erkundungsmodus wechseln möchte.

Wenn Sie mit Konzepten wie „Genuary“ vertraut sind, kommt Ihnen diese Dynamik vielleicht bekannt vor. Der Prozess verläuft nicht linear. Man ist auf der Suche nach neuen Formen, ohne immer genau zu wissen, wonach man eigentlich sucht. Manchmal hatte ich eine bestimmte Gleichung im Sinn. Häufiger beschrieb ich Copilot jedoch lediglich ein Gefühl, und gemeinsam lotsten wir uns zu etwas hin – wenn es funktionierte, war das wirklich aufregend, und ich starrte anschließend auf den Code, um zu verstehen, wie wir dorthin gelangt waren. Wenn es nicht funktionierte, erzeugte Copilot nach einer langen Sitzung mit guten Eingabeaufforderungen einfach etwas Falsches. Dieser Wechsel zwischen guten und enttäuschenden Sitzungen war es schließlich, der mich dazu veranlasste, etwas Beständigeres zu entwickeln.

Der Zeitpunkt war günstig, da ich über ausreichend Material verfügte. Beim Durchsehen des Ordners erkannte ich gemeinsame Strukturen, gemeinsam genutzte Elemente und wiederkehrende Parameterformen. Genau das braucht man, um einem Assistenten einen echten Kontext zu vermitteln – keine Liste von Regeln, sondern konkrete Beispiele. Ohne die vorhandenen Skizzen hätte ich das nicht versucht. Man kann keine Muster extrahieren, wenn nichts erstellt wurde.

Also begann ich mit der Entwicklung: eine Anleitung für die Arbeitsumgebung, eine Bibliothek mit wiederverwendbaren Eingabeaufforderungen sowie zwei maßgeschneiderte Agenten. Einer, um die Kunstwerke zu erstellen. Einer, um darüber zu schreiben.

Der Plan – was wir aufbauen

So sieht die praktische Umsetzung aus. Im Arbeitsbereich befinden sich nun drei Elemente, die zuvor noch nicht vorhanden waren:

.github/copilot-instructions.md — Eine Anweisungsdatei auf Arbeitsbereichsebene, die Copilot automatisch liest, sobald Sie das Projekt öffnen. Sie enthält: den Projektkontext (p5.js, Plotterausgabe, globaler Modus), die verbindlichen strukturellen Konventionen (CFG-Block, Trennung von „Regenerate“ und „Draw“, Tastaturkürzel, SVG-Exportformat), die Anforderungen an den Plotter (keine Füllungen, Strichstärkenbereiche, Richtlinien zur Liniendichte), das ästhetische Vokabular (welche visuellen Qualitäten angestrebt werden sollen) sowie die vollständige Bibliothek der bereits implementierten Algorithmen mit ihren wichtigsten Parametern.

Diese Datei erfüllt eine wichtige Funktion: Sie sorgt dafür, dass ich Copilot meinen Arbeitsablauf nie wieder neu erklären muss. Jede neue Unterhaltung beginnt damit, dass Copilot bereits weiß, dass ich für einen Plotter arbeite, dass „ LINESSVG “ jede Linie spiegeln muss und dass der „spatial hash“ das Standardwerkzeug für die Arbeit mit Graphen ist. Dieser Kontext bleibt erhalten.

.github/prompts/ — Sechs einzelne „ .prompt.md “-Dateien, von denen jede eine in sich geschlossene, wiederverwendbare Eingabeaufforderung mit einem YAML-Frontmatter-Header darstellt. Dies ist tatsächlich eine Funktion von GitHub Copilot: Eingabeaufforderungsdateien sind vollwertige Objekte, die der Editor versteht, und nicht nur Textnotizen. Jede Datei enthält ein Feld „ agent “, das auf den „Artist“-Agenten verweist, sowie ein Feld „ description “, das in der Copilot-Benutzeroberfläche angezeigt wird. Die sechs Eingabeaufforderungen umfassen:

Datei – Funktionsbeschreibung
01-new-sketch – Entdecken → vorschlagen → eine neue Skizze anhand eines kurzen Gesprächs erstellen
02-layer-algorithms - Zwei Algorithmen zu einem einheitlichen Ganzen zusammenführen
03-debug-explain - Überprüfen Sie die Funktion einer Skizze und erläutern Sie, was sie bewirkt und warum
04-add-element - Fügen Sie eine neue visuelle Ebene hinzu, ohne den bestehenden Code zu verändern
05-explore-algorithm - Einen Algorithmus vorschlagen und umsetzen, der noch nicht im Arbeitsbereich vorhanden ist
06-intensify-density - Erhöhen Sie die Liniendichte und die visuelle Intensität, ohne den Algorithmus zu ändern

Alle sechs Eingabeaufforderungen werden an den „Artist“-Agenten weitergeleitet, der die Unterscheidung intern vornimmt – indem er Fragen stellt und Vorschläge unterbreitet, bevor er mit der Generierung beginnt, wenn dies der richtige Zeitpunkt ist, oder direkt mit dem Programmieren fortfährt, wenn die Absicht bereits klar ist. Die Eingabeaufforderung ist der Startschuss; der Agent bestimmt das Tempo.

Wenn eine Sitzung etwas hervorbringt, das es wert ist, dokumentiert zu werden, verfasst der Künstler dies nicht direkt. Er übergibt die Aufgabe an den Writer-Agenten – ein strukturiertes Briefing mit fünf Feldern –, und dann übernimmt der Writer. Trennung der Aufgabenbereiche: Der „Artist“ bleibt im Code- und Parameterraum, der „Writer“ im Dokument. Die Konsistenz ergibt sich daraus, dass keiner der Agenten versucht, beide Aufgaben gleichzeitig zu erledigen.

Eine neue Skizze, Schritt für Schritt – Flechtenfeld

An dieser Stelle wird die Theorie zur Praxis. Das erste Experiment mit dem vollständig eingerichteten System: Reaktions-Diffusion mit einem „chaotischen Wachstum“. Ein Algorithmus, der noch nicht im Arbeitsbereich vorhanden ist, eine völlig leere Datei.

Ein Aspekt, der im Zusammenhang mit dem Ablauf dieser Sitzung besonders erwähnenswert ist: Ich habe alles, was geschah, parallel zu Copilot aktiv dokumentiert – jede Entscheidung, jedes Hindernis und jeder überraschende Moment wurde festgehalten. Daraus speist sich der „Writer“-Agent und letztendlich auch dieser Artikel. Der Prozess schreibt sich gewissermaßen in Echtzeit selbst, anstatt im Nachhinein rekonstruiert zu werden.

So sah das Endergebnis aus – nun ja, zumindest eine der Varianten:

Warum Reaktion-Diffusion?

Reaktions-Diffusion war in der ursprünglichen Algorithmenbibliothek nicht enthalten. Es handelt sich dabei um das System, das biologischen Mustern zugrunde liegt – Flecken auf einem Geparden, Streifen auf einem Zebrafisch, die Verzweigung einer Blattader. Zwei Chemikalien, die diffundieren und miteinander reagieren. Passen Sie die Parameter an, und Sie erhalten Flecken, Streifen, korallenartige Kolonien sowie labyrinthartige Irrgärten.

Die Herausforderung für den Plotter besteht darin, dass er ein Feld aus Gleitkommawerten erzeugt und keine Linien. Die Lösung ist das „Marching-Squares“-Verfahren: Man durchläuft das Raster Zelle für Zelle, ermittelt, an welcher Stelle das Feld einen Schwellenwert überschreitet, und zeichnet ein kurzes Liniensegment. Verbindet man genügend Segmente miteinander, erhält man den Umriss des Musters. Mehrere Schwellenwerte ergeben geschichtete, verschachtelte Konturen – Tausende kurzer Liniensegmente, die sich perfekt für den Plotter eignen.

Was die Anleitungsdatei tatsächlich bewirkte

Ausgehend von 01-new-sketch.prompt.md lautete die Vorgabe im Wesentlichen: Reaktionsdiffusion, chaotisches Wachstum, dunkler Hintergrund, akzentuierende säuregelb-grüne Farbe. Da die Anleitungsdatei bereits geladen war, funktionierten die Konvention „ CFG “, die Aufteilung in „ regenerate() “ und „draw() “ sowie das Exportformat „ LINESSVG “ – alles funktionierte auf Anhieb einwandfrei. Es war keine erneute Erläuterung der Standardvorgaben erforderlich.

Was manuell korrigiert werden musste: ein fehlender Operator „ + “ bei der Laplace-Operationsberechnung. Ein Fehler beim Kopieren und Einfügen in der Dichtearithmetik. Eine Kleinigkeit, aber eine gute Erinnerung daran, dass generierter numerischer Code stets eine Überprüfung verdient.

Iteration: Verdichtung

Das erste Ergebnis wirkte für einen Plotterausdruck zu spärlich. Es stellte sich die Frage: Welche sind die richtigen Einflussgrößen? Bei der Reaktionsdiffusion gibt es vier verschiedene Möglichkeiten, mehr Linien zu erhalten – das Gray-Scott-Regime zu wechseln, weitere Isoschwellenwerte hinzuzufügen, mehr Iterationen durchzuführen oder die Startpunkte breiter über die Leinwand zu verteilen. Aus dieser Sitzung entstand „ 06-intensify-density.prompt.md “: eine wiederverwendbare Eingabeaufforderung, die genau diese Einflussgrößen für jeden Algorithmus-Typ dokumentiert, denn was „mehr Linien hinzufügen“ bedeutet, hängt ganz davon ab, welchen Algorithmus man gerade verwendet.

Die Neugestaltung der Eingabeaufforderung

Nachdem ich die Flechten-Skizze erstellt hatte, warf ich noch einmal einen Blick auf 01-new-sketch.prompt.md und stellte fest, dass sie nicht mit dem übereinstimmte, was tatsächlich funktioniert hatte. Das Original war eine passive Vorlagenvorlage, die direkt zum Code überging. Was in der Praxis funktionierte, war ein dreistufiger Dialog: Zunächst werden Algorithmusoptionen vorgeschlagen, dann wird ein Plan in Worten dargelegt, bevor Code geschrieben wird, und schließlich erfolgt die Generierung mit expliziten Überprüfungshinweisen. Die Eingabeaufforderung wurde neu gestaltet, um der Realität zu entsprechen.

Die erste Fassung einer Aufforderung entspricht in der Regel dem, was man zu wollen glaubt. Die nützliche Fassung entsteht dadurch, dass man erkennt, was tatsächlich funktioniert hat, und dies stattdessen aufschreibt.

Wenn der Algorithmus Sie überrascht

Hier ist etwas, das sich ereignet hat und das ich festhalten möchte, da es ein wesentlicher Bestandteil des Prozesses ist.

Als ich die Taste „ R “ drückte, um bei der Flechten-Skizze durch zufällige Startwerte zu blättern, entstand dabei ein großes natürliches Vakuum – ein unregelmäßiger leerer Bereich, umgeben von eng ineinander verschlungenen Konturlinien. Das Muster hatte sich organisch um diesen Bereich herum entwickelt, wobei sich die Isokonturen krümmten und verengten, während sie den Raum umrahmten. Es sah absichtlich aus. Es wirkte wie eine kompositorische Entscheidung. Das war es jedoch nicht – es war Zufall.

Dieser Moment ist eines der Dinge, die ich an generativer Kunst am meisten schätze: Der Algorithmus erzeugt etwas, das besser ist, als man es sich gewünscht hätte. Einen leeren Bereich auf der Skizze zu schaffen, die durch komplexe Algorithmen erzeugt wurde, ist keine triviale Aufgabe – zumindest nicht für mich –, daher hat es mich sehr gefreut, dies zu sehen. Das bedeutet, dass meine Parametrisierung mir eine gewisse Unvorhersehbarkeit bei den Ergebnissen ermöglicht.

Sobald Sie die Simulation verstanden haben, ist es einfacher, bewusst einen leeren Bereich zu schaffen. Die B-Chemikalie benötigt Keime, um zu wachsen – wenn Sie nach dem Ausbringen der Keime einen kreisförmigen Bereich freiräumen, bildet sich dort keine Kolonie, und das umgebende Muster wächst um diesen Bereich herum. Die Isokonturen rahmen den leeren Raum auf natürliche Weise ein. Das Gegenteil – ein Konzentrationsakzent – packt zusätzliche Samen dicht in einen Bereich und schafft so einen Hotspot, der die komplexeste innere Struktur in der Komposition entwickelt.

Dies ist bereits das dritte Mal in diesem Projekt, dass die nützlichste Ergänzung nicht aus der Planung, sondern aus der Beobachtung des Algorithmus hervorgegangen ist.

Fähigkeiten vs. Anweisungen – eine Unterscheidung, die es wert ist, getroffen zu werden

Nach dem Aufbau der Prompt-Bibliothek stellte sich als Nächstes die Frage, ob ein Teil dieses Wissens an einer ganz anderen Stelle gespeichert werden sollte. Konkret ging es dabei um die „GitHub Copilot Agent Skills“.

Hier ist der Unterschied in einfachen Worten.

Befehle sind Handlungsaufforderungen. Sie sind pro Sitzung einmalig verwendbar, auf bestimmte Aufgaben zugeschnitten und werden aufgerufen, wenn Sie möchten, dass etwas sofort erledigt wird. „Erstellen Sie eine neue Skizze.“ „Erhöhen Sie die Dichte.“ „Erläutern Sie, wie diese Skizze funktioniert.“ Alles im Ordner „ prompts/ “ ist auf diese Weise aufgebaut.

Fähigkeiten sind Kompetenzpakete. Sie sind wissensbasiert, dauerhaft und können neben den Anweisungen auch unterstützende Ressourcen bündeln – Referenztabellen, Vorlagen, Datendateien und alles, worauf die Anweisungen möglicherweise verweisen müssen. Der entscheidende Unterschied liegt nicht im Format, sondern darin, was sie enthalten und warum Sie darauf zurückgreifen. Sie rufen eine Skill auf, um Copilot domänenspezifisches Wissen zu vermitteln; Sie geben eine Eingabeaufforderung ein, um ihn dazu zu bringen, etwas auszuführen.

Diese Unterscheidung ist von Bedeutung, da die Möglichkeiten, alles in Befehle zu packen, begrenzt sind. Ein Befehl wie „Erstelle eine neue Skizze“ kann Copilot mitteilen, wie dies zu bewerkstelligen ist. Eine Funktion für „So sieht der Kern einer Plotter-Skizze aus“ kann jedoch die eigentliche CFG-Vorlage und die SVG-Exportvorlage als Dateien bündeln – sodass das Modell diese nicht anhand der Beschreibung rekonstruieren muss, sondern die tatsächliche kanonische Version liest.

Das deutlichste Beispiel: die Referenz zum Gray-Scott-Regime. Bei der Arbeit an der Flechten-Skizze haben wir in der Praxis festgestellt, dass feed 0.037/kill 0.060 Korallen erzeugt, 0.029/0.057 dichte, labyrinthartige Kanäle erzeugt und 0.025/0.055 feine, komplexe Netzwerke erzeugt. Das ist echtes Wissen aus echten Experimenten. Eine Eingabeaufforderung kann eine strukturierte Referenztabelle nicht effektiv enthalten. Eine Fertigkeit mit einer gebündelten „ regime-reference.md “-Datei kann dies jedoch – und die nächste Sitzung, in der an einer Reaktions-Diffusions-Skizze gearbeitet wird, beginnt damit, dass all dies bereits geladen ist und nicht erst neu entdeckt werden muss.

Zwei Fähigkeiten, eine klare Regel

Es wurden zwei Fähigkeiten erstellt:

gray-scott-plotter — Der fachspezifischste und derjenige mit dem unmittelbarsten Nutzen. Das Handbuch „ SKILL.md “ behandelt den Algorithmus, die Isokontur-Strategie, die Hebel zur Dichteintensivierung sowie die Sicherheitsvorschriften für Plotter. Das im Lieferumfang enthaltene „ regime-reference.md “ ist eine vollständige Karte der Feed-/Kill-Parameter – jeder Betriebsbereich ist benannt, beschrieben und mit den Iterationsanforderungen sowie den Auswirkungen auf den Plotter verknüpft.

p5js-algorithm-library — Ein aktuelles Nachschlagewerk zu allen sechs Algorithmen, die derzeit im Arbeitsbereich verfügbar sind, mit Beschreibungen der Zeichen, Schlüsselparametern, Plottereigenschaften und Empfehlungen zur Kombination. Das im Lieferumfang enthaltene Handbuch „ algorithm-params.md “ enthält vollständige Parametertabellen mit Voreinstellungen der Typen „konservativ“, „Standard“ und „dicht“ für jeden Algorithmus – weitaus nützlicher als die kurze Tabelle unter copilot-instructions.md.

Es hat sich folgende Regel herauskristallisiert, um zu entscheiden, was wo hingehört: Die Anleitungsdatei enthält feststehende Konventionen, die Eingabeaufforderungen dienen der Ausführung bestimmter Aufgaben, und die Skills umfassen Fachwissen, das von gebündeltem Referenzmaterial profitiert. Wenn es sich bei dem Inhalt um eine Tabelle, eine Vorlage oder eine Parameterzuordnung handelt, die Sie lieber nachschlagen als neu erstellen möchten, gehört er in ein Skill-Asset – und nicht in eine Markdown-Liste innerhalb einer Anleitungsdatei.

In der Praxis bedeutet dies, dass der Arbeitsbereich nun über drei zusammenwirkende Kontextebenen verfügt. Die „ copilot-instructions.md “ bildet die Grundlage, die stets vorhanden ist. „Skills“ werden aufgerufen, wenn Sie fundiertes Fachwissen zu einem bestimmten Algorithmus oder Prozess benötigen. „Prompts“ werden aufgerufen, wenn Sie eine Aufgabe zu erledigen haben. Jede Ebene erfüllt eine bestimmte Funktion, anstatt zu versuchen, alle drei Aufgaben zu übernehmen.

Die Skills enthalten zudem gebündelte Ressourcen. „ cfg-template.js “ und „ svg-export-template.js “ befinden sich in einem separaten Ordner „ templates/ “ im Stammverzeichnis des Arbeitsbereichs – es handelt sich dabei um tatsächliche Code-Dateien, aus denen kopiert werden soll, und nicht um beschriebene Vorlagen. Das Modell liest die Datei selbst und nicht eine Beschreibung ihres Inhalts.

Der Agent – der Copilot für diese Aufgabe eine Rolle zuweist

Nachdem die Anleitungsdatei, die Eingabeaufforderungen und die Fähigkeiten erstellt worden waren, fehlte noch eine Sache. All diese Ebenen liefern zwar Kontext und Aufgabenvorlagen, legen jedoch nicht fest, wie sich Copilot in einem Gespräch verhalten soll. Soll es Fragen stellen oder direkt zum Code übergehen? Soll es ästhetische Meinungen äußern oder neutral bleiben? Soll es laut über Kompromisse nachdenken oder einfach nur ausführen?

Genau das leistet eine benutzerdefinierte Agent-Datei. GitHub Copilot unterstützt „ .agent.md “-Dateien – eine Möglichkeit, einen bestimmten Interaktionsmodus für einen Arbeitsbereich zu definieren. Betrachten Sie diese weniger als Konfigurationsdatei, sondern eher als Charakterbeschreibung. Sie beschreiben einen Mitwirkenden und legen keine Parameter fest.

Einer der für diesen Arbeitsbereich erstellten Agenten heißt „Artist“. Es gab einige Aspekte, die ich mir von ihm wünschte, die ein gewöhnlicher Assistent jedoch nicht aufweist:

Ästhetisch eigenwillig. Ein gewöhnlicher Copilot generiert alles, was Sie von ihm verlangen, und versichert Ihnen, dass es großartig aussieht. Das ist in einem kreativen Kontext nicht hilfreich. Der „Plotter Artist“-Agent ist darauf programmiert, anzusagen, wann eine Komposition unausgewogen wirkt, wann ein Ergebnis auf Papier nicht gut zur Geltung kommt und wann etwas wirklich schön ist. Er vertritt eine eigene Sichtweise.

Eine Denkweise, bei der der Plotter an erster Stelle steht. Jede Linie in jeder Skizze wird letztendlich zu einer physischen Stiftbewegung. Der Entwickler ist darauf vorbereitet, die physikalischen Konsequenzen jeder Entscheidung im Code zu durchdenken – Strichstärke im Hinblick auf das Ausbluten der Tinte, Dichte im Hinblick auf die Druckzeit, keine Füllungen, da der Plotter diese nicht darstellen kann. Dies sollte als natürlicher Bestandteil jeder Diskussion über den Code zum Tragen kommen und nicht als etwas, das man erst im Nachhinein überprüfen muss.

Ich interessiere mich für Unfälle. Die interessantesten Ereignisse in diesem Projekt ergaben sich aus etwas, das der Algorithmus unerwartet hervorbrachte – eine natürliche Lücke, eine glückliche Dichteverteilung. Der Agent ist angewiesen, zu fragen: „Können wir dies bewusst gestalten?“, wenn etwas Unerwartetes und Gutes geschieht. Das ist der kreative Kernkreislauf in der generativen Kunst: wahrnehmen, benennen, kodieren.

Im Zusammenhang mit den Skills. Der Agent weiß, dass er den entsprechenden Skill laden muss, bevor er Parameterempfehlungen ausspricht – „ gray-scott-plotter “, bevor er auf Reaktions-Diffusions-Parameter eingeht, und „ p5js-algorithm-library “, bevor er die Auswahl von Algorithmen erörtert. Die Skills sind nutzlos, wenn sie nicht aufgerufen werden.

Verantwortlich für die Dokumentation. Dem Mitarbeiter wird ausdrücklich mitgeteilt, dass bemerkenswerte Momente einer Sitzung unter documentation_draft.md festgehalten werden sollen. Das ist die Metaebene: Die Arbeit dokumentiert sich selbst, während sie stattfindet, anstatt im Nachhinein rekonstruiert zu werden. Ich habe zahlreiche Test- und Verbesserungsrunden durchlaufen und wollte interessante Momente für zukünftige Referenzzwecke sowie für diesen Artikel zusammenstellen.

Die Struktur der Agenten-Datei unterscheidet sich in einem wichtigen Punkt von den Fähigkeiten und Aufforderungen. Fähigkeiten sind Referenzmaterial – Sie rufen sie auf, um etwas nachzuschlagen. Eingabeaufforderungen sind Aufgabenvorlagen – man ruft sie auf, um etwas zu tun. Die Agenten-Datei definiert eine Verhaltensweise, die über eine gesamte Sitzung hinweg bestehen bleibt. Das ist der Unterschied zwischen einem Werkzeug und einem Kooperationspartner.

Der Künstler arbeitet jedoch nicht allein. Es gibt einen zweiten Akteur – den Schreiber –, dessen einzige Aufgabe darin besteht, die Materialien zu dokumentieren. Die beiden Akteure bilden einen geschlossenen Kreislauf: Der Künstler gestaltet und experimentiert, der Schreiber dokumentiert und reflektiert. Keiner von beiden dringt in das Gebiet des anderen vor. Diese Trennung ist es, die das Ganze als System funktionieren lässt und nicht nur als eine Ansammlung von Anweisungen.

Der Writer-Agent weiß nichts über p5.js oder Gray-Scott-Parameter. Er kennt die Dokumentation: die aktuelle Reihenfolge der Abschnitte, den Stil, in dem sie verfasst ist, wann ein neuer Abschnitt „ ## “ anstelle eines Unterabschnitts „ ### “ hinzugefügt werden muss und was als Platzhalter in den Abschnitt „What’s next“ gehört. Seine Werkzeuge beschränken sich auf read, edit und search – keine Codeausführung, keine Webabfragen. Er benötigt diese nicht.

Der Künstler schließt nun bemerkenswerte Momente mit einer Sitzungszusammenfassung ab – einem kurzen, strukturierten Dokument mit fünf Feldern: Was wurde erstellt, was war überraschend, was wurde gelernt, welche Vorgabe oder Fähigkeit kam dabei zum Einsatz und an welcher Stelle im Dokument gehört dies hin. Der Autor liest die Zusammenfassung, liest das gesamte Dokument und verfasst einen Text. Der Künstler greift nicht direkt auf „ documentation_draft.md “ zu.

Das kurze Format ist wichtig, da es vor der Weitergabe einen Moment des Nachdenkens erzwingt. Zu schreiben „Was war überraschend: nichts“ ist an sich schon eine Beobachtung. Wenn Sie die vorgeschlagene Platzierung im Text angeben, müssen Sie entscheiden, ob etwas einen neuen Abschnitt verdient oder lediglich als Absatz an einen bestehenden angehängt werden sollte. Die Weitergabe ist unkompliziert, aber nicht völlig unbedeutend – und das ist beabsichtigt.

Wenn Copilot eine Auswahl trifft

Bislang hatte jede Sitzung auf dieselbe Weise begonnen: Ich brachte eine Idee mit – einen Stimmungsbegriff, ein Bildbeispiel, den Namen eines Algorithmus. Dieses Mal brachte ich nichts mit. Die Vorgabe war völlig offen: Wählen Sie etwas aus, das Sie gerne erkunden würden; ich gebe Ihnen keine Vorgaben.

Der von ihm gewählte Algorithmus war „Differential Growth“ – dieser stand zwar auf der Kandidatenliste in der Algorithmenbibliothek, war jedoch nie implementiert worden. Es handelte sich nicht um einen zufälligen Vorschlag. Da er Zugriff auf die gesamte Bibliothek hatte, entdeckte er die Lücke und schlug vor, diese zu schließen.

Das Ergebnis war gut. Vier geschlossene Kurven, die unter konkurrierenden Feder- und Abstoßungskräften wachsen und sich falten, Wechselwirkungen zwischen den Kurven, 720 Iterationen, eine blasse, botanisch-grüne Farbpalette auf fast schwarzem Hintergrund. Die Mechanismen waren interessant – die Abstoßung zwischen den Kurven führte dazu, dass die Formen den gemeinsamen Raum ausloteten, anstatt unabhängig voneinander zu wachsen. Alle Konventionen des Arbeitsbereichs wurden korrekt befolgt.

So sah eine Kurve aus:

Mit etwas Aufwand könnte das recht ansprechend aussehen, doch das differentielle Wachstum ist nicht gerade einfach zu handhaben, daher werde ich mir das für später aufheben.

Daher war ich von dem Ergebnis nicht wirklich begeistert. Der Algorithmus ist vom Prinzip her großartig, und der Code war sauber und korrekt. Er hatte jedoch nicht dieselbe visuelle Wirkung, die ich bei den anderen Skizzen empfunden hatte. Dem Assistenten völlige kreative Freiheit zu gewähren, funktionierte zwar technisch – es entstand eine gültige, plotterfähige Skizze –, doch das ist nicht dasselbe wie etwas zu schaffen, das ich gerne ausdrucken würde. An diesem Teil der Einrichtung muss noch gearbeitet werden.

Wenn ich eine Anweisung erteile

Der Unterschied, als ich meinen eigenen Ausgangspunkt einbrachte, war sofort spürbar und offensichtlich. Derselbe Assistent, dieselben Vorgaben, dieselbe Anleitungsdatei – doch diesmal ging es von einem Gefühl oder einem Bild aus, anstatt von einer offenen Aufgabenstellung. In mehreren aufeinanderfolgenden Sitzungen gab ich eine Vorgabe, und das Ergebnis entsprach genau meinen Vorstellungen. Bilder dazu folgen jeweils im Anschluss.

Wasserwellen – Welleninterferenz

Ich beschrieb es als „bleaks“, ähnlich wie Wasserwellen – ein etwas unpassendes Wort, das jedoch etwas Reales einfing: jene hellen, unbeständigen Lichtblitze, wenn Sonnenlicht auf unruhiges Wasser trifft. Ich nannte keinen Algorithmus. Ich beschrieb, wie es sich anfühlen sollte. Der Künstler wählte die Welleninterferenz, entwarf den Plan und erstellte die Skizze. Ich bestätigte die Anzahl der Wellen und die Anzahl der Isolinien. Das war im Wesentlichen alles. Das Ergebnis des ersten Durchlaufs war, wie ich es damals selbst formulierte: genau das, was ich mir vorgestellt hatte. Ich hatte zuvor bereits mehrfach versucht, Wasserwellen zu generieren, doch das Ergebnis war nie auch nur annähernd so gut wie dieses.

Geländegitter – perspektivische Drahtgitterdarstellung

Dieses Projekt begann mit einem Referenzbild – einem leuchtend elektrisch-blauen 3D-Drahtgitter-Wellen-Gelände. Ich habe die Referenz weitergegeben, und der Künstler hat sie direkt umgesetzt: perspektivische Projektion, Verdichtung der Linien zum Horizont hin, abgestufte Strichstärke von vorne nach hinten. Eine Parameteranpassung, um die ich anschließend gebeten habe – Rauschen in einer einzigen Oktave statt in drei, um die Kammlinien klar und ununterbrochen zu halten. Alles andere gelang auf Anhieb. Auf den ersten Blick ist dieses Projekt nichts Besonderes, aber ich habe es aus Neugier ausprobiert. Ich habe bereits zuvor versucht, ein Gelände zu erstellen, doch es war viel zu zeitaufwendig, um das gewünschte Ergebnis zu erzielen. Diesmal jedoch war es mit meiner aktuellen Konfiguration im Grunde schon beim ersten Versuch fertig.

Drahtgeflecht – Laugenwasser

Ich teilte mitten in der Sitzung ein Foto eines sonnenbeschienenen Pools, und das Wort, das mir als Rückmeldung kam, war „Kaustik“ – nicht als ästhetische Beschreibung, sondern als optisches Phänomen. Der Künstler stellte einen Zusammenhang zum Algorithmus her: Wenn displaceScale deutlich größer ist als gridStep, bündeln die Wellenkämme benachbarte Reihen zu dichten Clustern und bilden so exakt nach, wie sich echte Kaustiken bilden. Breiter Frequenzbereich für chaotische, mehrskalige Interferenz, acht Wellen. Die Skizze war im Wesentlichen fertiggestellt. Ein Referenzbild veränderte nicht nur mein Ziel, sondern auch das, was der Algorithmus tat – und diese Neuausrichtung ging vom Agenten aus, nicht von mir.

Was ich tatsächlich gebaut habe und was mich überrascht hat

Die Konfiguration, bei der ich letztendlich gelandet bin, sieht wie folgt aus: eine Anleitungsdatei, sechs wiederverwendbare Aufforderungen, zwei Fähigkeiten, zwei Akteure. Auf dem Papier klingt das nach viel Unterstützung. In der Praxis fällt dies jedoch kaum auf – es ist einfach da, und die Sitzungen fühlen sich anders an.

Am stärksten verändert hat sich die Qualität der Ausgangsbasis. Bevor ich dies erstellt habe, begann jede Sitzung mit Copilot mit zehn Minuten, in denen der Kontext neu hergestellt werden musste: Welchen p5.js-Modus ich verwende, wie das SVG-Exportformat aussieht, was ein „ CFG “-Block ist. Da die Anleitungsdatei nun geladen ist, entfällt dieser Teil. Die erste Nachricht in einer Sitzung ist bereits eine Zusammenarbeit und keine Einweisung mehr.

Was mich jedoch wirklich überrascht hat, war, wie viel intelligenter die Antworten im richtigen Kontext wurden. Nicht im vagen Sinne intelligenter – sondern konkret intelligenter. Der „Artist“-Agent unterbreitet Vorschläge, bevor er etwas generiert, was bedeutet, dass er Unstimmigkeiten erkennt, bevor daraus 300 Zeilen Code werden, die rückgängig gemacht werden müssen. Er fragt, wie sich ein Algorithmus anfühlen sollte, und nicht nur, was er tun sollte. Er lädt eine Fähigkeit und orientiert sich an einer Parameter-Referenztabelle, anstatt Werte zu erraten. Das ist kein anderes Modell. Es ist dasselbe Modell, das mit der richtigen Struktur unterlegt ist.

Die Skizzen in der zweiten Hälfte dieses Artikels – die Welleninterferenz, das Geländegitter, der Kaustikdraht – erforderten jeweils nur ein oder zwei Anpassungsrunden, nicht zehn. Der Agent verstand bereits nach der ersten Nachricht, was ich beabsichtigte, da die Anweisungen und Aufforderungen ihm genügend Kontext lieferten, um eine echte Entscheidung zu treffen, anstatt auf Nummer sicher zu gehen. Diese Kluft zwischen „technisch korrekt und generisch“ und „genau das, was ich eigentlich wollte“ ist genau die Lücke, die ein guter Kontext schließt.

Generative Kunst ist bereits ein Prozess, bei dem man eine Struktur aufbaut und sich dann von ihr überraschen lässt. Dieses Projekt hat dem Ganzen eine weitere Ebene hinzugefügt: Man erstellt die richtigen Anweisungen, Eingabeaufforderungen und Agenten-Definitionen und lässt sich dann auch vom Assistenten überraschen. Die besten Sitzungen fühlten sich weniger so an, als würde man einem Werkzeug Anweisungen geben, sondern eher so, als würde man mit jemandem zusammenarbeiten, der die Ästhetik bereits verstanden hatte und dem man lediglich die Richtung aufzeigen musste.

Genau das wollte ich eigentlich erstellen. Ich glaube, es hat geklappt.