AI & Rendering | Ziele, Revisionen, Regeln: Wie man längere Agentenarbeit organisiert

In der letzten Nacht des Projekts habe ich kurz nach Mitternacht ein Ziel gesetzt und bin schlafen gegangen. Um 02:46 Uhr waren zwei Innenansichten in voller Auflösung berechnet, um 02:52 Uhr lag der Prüfbericht dazu vor. Das Bild oben ist eine davon, genau so, wie sie in dieser Nacht entstand, ohne eine Rückmeldung von mir zu einem Zwischenstand.

Möglich macht das die Zielfunktion von Claude Code. Man setzt mit /goal eine Bedingung, und der Agent arbeitet, bis sie erfüllt ist. Bei jedem Halt löst er automatisch eine Prüfung aus, einen sogenannten Hook. Sie kontrolliert, ob die Bedingung erfüllt ist, und schickt den Agenten andernfalls zurück an die Arbeit. Für mich ist das ein Segen. Ich schlafe, und die Arbeit geht trotzdem weiter.

Bis zu meiner Abnahme waren danach noch Korrekturen nötig.

Nach Teil 1 und Teil 2 zeigt dieser dritte Teil, was vorhanden sein muss, damit ein Agent eine Nacht lang allein zu einem brauchbaren Ergebnis kommt: Dateien, Regeln und Zieldokumente.

Dieser Teil ist technischer als die beiden ersten. Wer nicht selbst mit Coding-Agenten arbeitet, kann die Auszüge aus den Dokumenten überfliegen: Die Geschichte der letzten Nacht und der Schluss sind auch ohne sie verständlich.

#Eine Szene ist ein Programm

Die wichtigste technische Entscheidung fiel am ersten Tag. Der Agent bearbeitet die Blender-Datei nie von Hand. Er schreibt ein Python-Skript, das einen bestehenden Stand lädt, eine Änderung vornimmt und das Ergebnis unter neuem Namen speichert. Jede Revision besteht damit aus vier Dingen: einem Aufbauskript, einer neuen Szenendatei, einem oder mehreren Nachweisbildern und einem Bericht.

Meine Erfahrung sagte mir, dass das die richtige Entscheidung ist. Für die Arbeit mit Agenten ist es die einzige, die zählt. Programmierschnittstellen sind das Alpha und das Omega der Arbeit mit AI, ohne sie geht nichts. Das ist der neue Maßstab für jede Art von Software, mit der wir arbeiten. So wähle ich inzwischen auch Software aus, wenn wir sie für unser Unternehmen einkaufen. Hat sie eine API, hat sie einen MCP-Server, also eine Schnittstelle eigens für Agenten, oder lässt sie sich auf andere Weise so ansprechen, dass eine AI damit arbeiten kann? Wenn nicht, ist sie in der Regel raus.

Wie jedes Softwareprojekt sammelte auch dieses technische Schulden an. Nach fünf Tagen nannte ich den Zustand einen Flickenteppich und fragte, ob wir Altlasten angespart hätten. Die Antwort war eine Liste, angefangen bei Geländeoberflächen auf drei verschiedenen Höhen übereinander. Jede einzelne Korrektur war für sich plausibel gewesen. Zusammen ergaben sie eine Szene, in der niemand mehr sagen konnte, welches Objekt einen sichtbaren Fehler erzeugt.

#Regeln, die aus Fehlern stammen

Aus dieser Bestandsaufnahme entstand eine neue AGENTS.md, die Regeldatei, die jeder Agent bei jedem Start liest. Ich hatte dem Agenten die Themen genannt: Benennung, Skriptaufbau, Speicherort, Renderregeln und den Lebenszyklus einer Iteration. Formuliert hat er sie selbst, aus den Fehlern der Tage davor.

Ein paar Beispiele, jeweils mit dem Fehler, aus dem die Regel stammt:

Revisionen heißen R<Nummer> <Kurzer Zweck>, und Modell, Skripte, Bilder und Berichte tragen dieselbe Kennung. Vorher hießen Dateien „Dämmerungsbalance 16“ oder „Finalsatz82“, und ein Bild ließ sich keinem Modellstand mehr zuordnen.
Dateien heißen nur dann „Final“, wenn die Abnahme abgeschlossen ist. „Finalsatz82“ war nie abgenommen worden. Berater, die ihren Foliensatz gerade zum dritten Mal „final“ nennen, dürfen hier schmunzeln. Es gibt tatsächlich Systeme, die sich an diese Regel halten.
Ein Skript überschreibt seine Quelle nie. Das Ziel muss neu sein, sonst bricht der Aufbau ab.
Objekte werden nach expliziter Rolle ausgewählt, nie nach Namensteilen. Eine Namenssuche nach Bodenbelägen hatte Fensterbänke, Türen und Möbel miterfasst.
Pro Komponente gibt es genau eine aktive Fassung. Keine anwachsende Folge ausgeblendeter Korrekturebenen.
Eine automatische Codeprüfung kontrolliert jedes Skript vor dem Aufbau der Szene. Ich hatte gefragt, ob es dafür etwas Fertiges gibt, bevor wir es selbst schreiben. Gab es.

Dazu kommt ein fester Ablauf je Iteration. Zwei Sätze daraus: Vermutung und Beweis werden getrennt protokolliert, und ein bestandener Untertest gilt ausdrücklich nicht als gelöstes Problem.

Am ersten Tag hätte ich keine dieser Regeln schreiben können. Sinnvoll war, sie in dem Moment festzuhalten, in dem der Fehler noch frisch war, und zwar in einer Datei, die jeder Agent bei jedem Start liest.

#Eine einzige Aufgabenliste

Nach einigen Tagen gab es einen Arbeitsplan, einen datierten Aufgabenplan, ein Fortschrittsprotokoll und offene Punkte, die nur im Gesprächsverlauf standen. Ich habe das auf eine Datei reduziert: TODO.md in der Arbeitswurzel, mit festem Aufbau. Programmierer kennen so eine Datei als ihre Roadmap.

Aktueller Stand: Eingangsmodell, aktive Revision, zuletzt bestandene Prüfung, nächster konkreter Schritt.
Aufgaben mit stabiler Kennung, Status, Erfolgskriterium und Verweis auf den Nachweis. Drei Zustände: offen, in Arbeit, erledigt.
Ein knappes Iterationsprotokoll: Hypothese, Änderung, geprüftes Bild, Ergebnis, Entscheidung.
Offene Annahmen und Entscheidungen, die ich treffen muss.
Die nächsten ein bis drei Schritte.

Zwei Sätze aus der Vorgabe haben sich besonders bewährt. Der erste: „Ein gestarteter Render ist nicht erledigt.“ Der zweite betrifft das Protokoll: „Auch gescheiterte und verworfene Ansätze festhalten, damit sie nicht erneut blind ausprobiert werden.“ Nach einer Kontextverdichtung kennt der Agent seine eigenen Fehlversuche sonst nicht mehr und probiert dieselbe Sackgasse noch einmal.

Die Liste hat noch einen zweiten Zweck. Wenn ich morgens wissen wollte, wo wir stehen, habe ich diese Datei gelesen und keinen Chatverlauf.

#Der Wechsel von Codex zu Claude

Mit den visuellen Ergebnissen von GPT-Astra war ich nicht zufrieden. Ich habe auf arena.ai nachgesehen, welche Modelle bei visuellen Aufgaben gut bewertet werden, und mich für Claude Opus entschieden. Die Protokolle zeigen daneben zwei sachliche Gründe: vier gescheiterte Versuche am selben Fehler und die angesparten Altlasten.

Der Wechsel machte außerdem ein Dokumentationsproblem sichtbar. In meiner Bestandsaufnahme vom selben Abend stand ein Abschnitt mit der Überschrift: „Steht nur in unserem Kontext, nicht in einem Dokument.“ Wesentliches Wissen über das Projekt lebte nur noch im Gesprächsverlauf einer einzigen Sitzung. Ein Wechsel des Agenten zwingt dazu, dieses Wissen aufzuschreiben. Das hätte ich auch ohne Wechsel tun sollen.

Den Übergabe-Prompt und alle weiteren /goal-Prompts hat Codex geschrieben, denn Codex hatte den gesamten Kontext des Projekts. Es braucht also eine strukturierte Übergabe, wie bei einem Mitarbeiter. Auch einen guten Azubi würden Sie nicht ohne Übergabe an Ihre nächste große Aufgabe setzen. Meine Vorgabe dafür war kurz:

Generell musst du annehmen, dass der Agent bei 0 anfängt und noch nicht in diesem Projekt gearbeitet hat und dementsprechend keinen Kontext hat.

Zwei Subagenten prüften den Entwurf. Einer fand fünf Fallen, die in keinem Chat erwähnt worden waren, darunter ein Aufbauskript, das eine längst gelöschte Datei voraussetzte.

#Das Zieldokument: Guardrails für den Agenten

Im Kern definiert das Ergebnis Guardrails, und Guardrails sind der wesentliche Teil agentischer Arbeit. Bei Code sind sie vertraut. Hier lässt sich sehen, wie man sie für eine visuelle Aufgabe formuliert. Die Teile, die am meisten bewirkt haben:

Der Einstieg sagt, was der Agent nicht tun soll.

Du übernimmst eine bestehende Architekturvisualisierung für Oliver Borchers. Du arbeitest an der Fertigstellung, nicht an einem neuen Projekt und nicht an einer erneuten allgemeinen Planungsrunde. Du hast keinen Chatkontext. Dieses Briefing und die angegebenen lokalen Unterlagen sind dein Einstieg.

Wer ein fremdes Projekt übernimmt, beginnt gern mit einer Analyse und einem neuen Plan. Beides hatten wir schon.

Freiheiten und Grenzen stehen nebeneinander. Das Dokument gibt Materialien, Licht, Himmel, Kamera und Ausstattung frei und benennt im selben Absatz die Grenze: Kubatur, Dachform, Öffnungen, Maßstab und Lage des Hauses bleiben, Bäume stehen ungefähr dort, wo sie real stehen. Ohne diese Grenze ließe der Auftrag „mach es schöner“ offen, ob auch das Haus selbst umgebaut werden darf.

Bekannte Fallen werden benannt. Ein Skript hieß dem Namen nach wie eine harmlose Prüfung, startete in Wahrheit aber Renderläufe und veränderte dabei Licht und Kameras. Das weiß nur, wer dabei war. Ein neuer Agent hätte es arglos gestartet.

Für jedes Arbeitspaket müssen mehrere Abnahmekriterien zugleich erfüllt sein. Die Rasenkante aus Teil 2 war viermal gescheitert. Für dieses Paket gelten deshalb unter anderem folgende Bedingungen:

Kein Gras über oder auf befestigten Flächen.

Geometrie von Haus und geschützten Belagsflächen unverändert […].

Darunter steht: „Keine bloße Punktzahl anstelle des Nachweises.“ Jede Zeile dieser Liste ist ein Fehler, den wir vorher tatsächlich gesehen hatten.

Eine Regel gegen das Weiterflicken.

Spätestens nach zwei erfolglosen, auf denselben Fehler zielenden Versuchen die Patchfolge unterbrechen, Hypothese und Messung überprüfen und einen besser begründeten Ansatz wählen. Nicht nach zwei Versuchen den Auftrag aufgeben, sondern die Methode ändern.

Claude hat diese Regel in der ersten Nacht dreimal angewandt. Beim ersten Mal wechselte der Agent nach zwei erfolglosen Korrekturen vom Probieren zum Messen und fand den Fehler im eigenen Skript.

„Fertig“ ist definiert, und Selbstbewertung zählt nicht als Abnahme.

Nicht jedes Bild auf 85 aufrunden. Technisch geprüft, tatsächlich visuell geprüft und von Oliver akzeptiert sind drei getrennte Zustände. Selbstbewertung ist keine externe Auszeichnung.

#Nach der ersten Nacht mit Claude

Meine erste Bildkritik an Claude kam nach gut neun Stunden autonomer Arbeit. Mir fiel auf, dass die Straßenlaterne im Nachtbild keinen Lichtkegel auf den Boden warf. Die Ursache: ein falsch gedrehter Strahler, der nach oben leuchtete.

Die Laterne hatte buchstäblich eine tolle Ausstrahlung, nur eben nach oben. So etwas bemerkt eine AI schlicht nicht.

Das eigentliche Problem dieser Phase war das Tempo. Fünf bis zehn Minuten Wartezeit je Zwischenbild machen jede Bildkritik zäh. Es ist wie überall in der Arbeit mit Agenten: Man braucht schnelles, wiederholbares Feedback, sonst wird jede Rückkopplung zum Flaschenhals. Ich habe deshalb einen Exkurs eingelegt und die gesamte Arbeitspipeline überarbeiten lassen, mit einem einzigen Ziel: kleine Bilder und schnelle Antworten.

Der Agent schrieb einen Vorschaudienst, der das Modell einmal lädt und nur den Bildausschnitt rendert, um den es geht. Aus 110 Sekunden für ein volles Prüfbild wurden knapp 8 Sekunden für einen Ausschnitt. In die AGENTS.md kam die Regel erst, nachdem der Gewinn gemessen war.

#Das Innenraum-Ziel: über Nacht zu zwei Bildern

Dieser Teil ist eigentlich kompletter Quatsch. Gebraucht hätte ihn niemand, und für meine Ausgangsfrage ist er völlig überflüssig. Ich habe es trotzdem gemacht, weil ich es ziemlich cool fand, es einmal auszuprobieren. Und an diesem zweiten Zieldokument lässt sich am deutlichsten zeigen, wie direkt der Weg von einem Ziel zu einem Ergebnis sein kann.

Ich wollte zum Abschluss ein bis zwei Innenansichten eines Wohnraums. Meine Vorgabe an Codex war vage: hochwertig, modern, vielleicht in einem charmanten Beige, keine beliebigen Stock-Assets, und bitte erst recherchieren. Auf ein komplett beiges Millennial-Zimmer hatte ich allerdings keine Lust. Davon gibt es weiß Gott genug. Der Raum brauchte also ein paar farbliche Akzente.

Auch hier schrieb Codex den Prompt für Claude und machte aus meinen Vorgaben ein Dokument mit zehn Abschnitten. Drei Eigenschaften davon beschreibe ich hier.

Es trennt Verbindliches von Vorschlägen. Aus meiner Abneigung gegen Beige wurde ein Abnahmekriterium, aus der Farbidee des Agenten eine Empfehlung. Im Dokument steht: „Ein weiterhin monotoner beiger Raum besteht die gestalterische Abnahme auch dann nicht, wenn alle Materialien technisch korrekt sind.“

Referenzen haben einen begrenzten Zweck. Zu jedem der drei recherchierten Architekturprojekte steht im Dokument, was übernommen wird (das Zusammenspiel der Materialien) und was nicht (Raumaufteilung und Details, die nicht zu unserem Grundriss passen).

Es legt die Reihenfolge fest: erst Maße, Platzhalter und Kamera, dann Materialien und Licht. Styling erst, wenn die Architektur funktioniert.

Das lange Dokument blieb als Datei liegen. In das Eingabefeld von /goal kam nur eine Kurzfassung, die auf die Datei verweist. Der Abschnitt zur Gestaltung lautet dort:

Ein moderner, hochwertiger, wohnlicher Raum mit Persönlichkeit. Warme Eiche, Sand und Creme bilden die Basis. Verbindlich sind gezielte Farb-, Form- und Materialakzente: kein gleichförmiger oder verwaschener beiger Raum. Als Richtung sind Petrol/Rauchblau, dunkleres Holz, eine charaktervolle Leuchte und ein kleiner Rost-/Weinrotakzent vorgeschlagen. […] Wenige ausgezeichnete Möbel auswählen, passend zum kleinen Grundriss. […] Keine beliebigen Komplettsets.

Legen Sie diesen Absatz neben das Bild vom Nachtstand. Eichenboden und sandfarbenes Sofa folgen der vorgegebenen Basis. Das Kissen in Rost und der Druck in Petrol sind die verlangten Farbakzente, und die Stehleuchte ist die Leuchte mit Charakter.

Knapp drei Stunden nach dem Start lagen beide Bilder samt Prüfbericht und eigener Kritik des Agenten vor.

Ein eigenes Prüfskript des Agenten fand in dieser Nacht Fehler, die ich auf den Bildern nie gesehen hätte, weil sie vor dem Rendern behoben wurden. Die Türen eines Sideboards lagen durch einen Importfehler mehrere Meter entfernt im Garten.

Als ich aufwachte, war die Arbeit im Wesentlichen erledigt. Meine Rückmeldung am Morgen betraf Details: ein Deckenbalken, den es in der realen Architektur nicht gibt, Kissen, die ineinander steckten, dazu Wünsche wie eine kleine Kaffeebar und eine gefaltete Decke auf dem Sofa. Die erste Decke, die der Agent dafür herunterlud, hieß Alpaka-Decke und entpuppte sich als Spielfigur.

Bis zur Abnahme brauchte es danach noch vier weitere Durchläufe des Endrenders. Den ersten habe ich selbst gestoppt, weil mir ein schwarzer Fenstersturz auffiel, den ich vorher übersehen hatte.

#Die Zielbedingung, die ich falsch formuliert hatte

In beiden Zielen sollten technische Fertigstellung und meine Zustimmung getrennt ausgewiesen werden. Die Abschlussbedingung verlangte meine Freigabe aber weiterhin.

Beim Außensatz legte Claude sechs Vorschauen vor und verlangte meine Sichtfreigabe vor dem teuren Endrender. Genau so hatte ich es bestellt. Der Hook sah nur, dass noch keine Endbilder existierten, und wies den Agenten siebenmal zurück an die Arbeit. Er weigerte sich siebenmal, mit der Begründung, meine Anweisung gehe dem automatischen Weiterlaufen vor.

In der Nacht des Innenraums wiederholte sich das elfmal. Die Bilder lagen um 02:52 Uhr zur Prüfung vor, die Bedingung verlangte meine Zustimmung, und ich schlief. Der Agent wies beim ersten Mal darauf hin, dass er sich diese Zustimmung nicht selbst geben kann. Er schickte eine einzige Benachrichtigung, änderte danach nichts mehr am Modell und wartete. Er war dabei geduldiger, als ich es gewesen wäre.

Ich halte das für das richtige Verhalten und für meinen Fehler. Eine Zielbedingung sollte nur enthalten, was der Agent selbst herstellen und eine Maschine prüfen kann. Die Zustimmung eines Menschen gehört in den Ablauf danach.

#Die Zahlen

Alle Angaben stammen aus den Sitzungsprotokollen und den Projektdateien.

Kennzahl	Wert
Aktive Agentenzeit Codex	rund 30 Stunden, davon rund 19 nach der Recherche
Aktive Agentenzeit Claude	rund 21 Stunden
Meine Nachrichten	mehr als 300
Letzte Revisionsnummer	R166
Endbilder	7 außen, 2 innen
Gekaufte Assets	keine

Alle Assets waren kostenlos. Ein Teil davon darf in Renderings gezeigt, aber nicht weitergegeben werden, deshalb kann ich die bearbeitbare Szene nicht veröffentlichen.

Beide Agenten liefen über meine bestehenden Abonnements. Für das Projekt selbst fielen keine weiteren Kosten an. Meine eigene Zeit habe ich nicht gemessen. Für die Überarbeitung nach der Kritik schätze ich sie auf drei bis vier Stunden, verteilt auf viele kurze Rückmeldungen.

#Was das zeigt und was nicht

Die Bilder sind gut geworden. Mit der Arbeit eines spezialisierten Studios habe ich sie nicht verglichen. Ein 3D-Artist mit 17 Jahren Erfahrung schrieb unter meinen zweiten Beitrag, jede Werkzeuggeneration sei von der vorherigen verspottet worden, und er habe sich längst einen eigenen Agenten für genau diese Arbeit eingerichtet. Bei ihm und bei allen anderen, die positiv und konstruktiv kommentiert haben, bedanke ich mich. Genau so muss das gehen.

Für mich zählt, dass diese Visualisierung ohne Agenten nie entstanden wäre. Es gab ein privates Vorhaben, bei dem sich eine Beauftragung nicht gerechnet hätte, und jetzt gibt es Bilder. Genau darum geht es bei AI.

Der zweite Recherchebericht enthält gegen Ende einen Satz, der meine Rolle in diesem Projekt gut beschreibt:

Der Engpass ist damit zunehmend nicht mehr der Zugang zur Technik, sondern Geschmack, Selektion, Beobachtung und Art Direction.

Ich habe in dieser Woche Bilder angesehen, Fehler benannt, Maßstäbe besorgt, Arbeit angehalten, Ziele aufschreiben lassen und Regeln festgehalten. Die Verantwortung für das Ergebnis lag die ganze Zeit bei mir. Die ersten umgedrehten Terrassenstühle, die Laterne ohne Lichtkegel und das Knie in der Tischstrebe sind mir beim Ansehen der Bilder aufgefallen, bevor es eine Prüfung dafür gab.

Im Kern ist dieses Projekt eine Studie darüber, wie man seine Arbeit mit AI strukturiert. Es ist immer ein iterativer Prozess: Hypothese, Test, nächster Schritt, Rückkopplung.

Wenn Sie längere Arbeit an einen Agenten übergeben, würde ich mit diesen Dingen beginnen:

Recherchieren Sie zuerst, vor allem wenn Sie mit AI etwas Neues ausprobieren. Sehr wahrscheinlich hat in diesem Bereich schon jemand etwas gemacht.
Wählen Sie Ihre Technik so, dass sie es dem Agenten leicht macht, sei es durch die Software selbst oder durch ihre Schnittstellen.
Etablieren Sie klare, konkrete Arbeitsabläufe: eine Regeldatei, eine Aufgabenliste, nachvollziehbare Revisionen.
Lassen Sie das Zieldokument von dem Agenten schreiben, der den Kontext hat, und schreiben Sie es für einen Leser ohne Vorgeschichte. Alles, was nur im Chat steht, geht beim Wechsel verloren.
Trennen Sie Verbindliches von Vorschlägen, und nennen Sie Freiheiten und Grenzen im selben Absatz.
Benennen Sie bekannte Fallen, vor allem Werkzeuge, die anders arbeiten, als ihr Name verspricht.
Formulieren Sie neben Abnahmekriterien auch Qualitätskriterien, wie Sie es in der Softwareentwicklung tun würden, jedes aus einem Fehler, den Sie schon gesehen haben.
Was sich durch statische Analyse begrenzen lässt, begrenzen Sie so. Ein Beispiel ist der Schwarzanteil eines Bildes, der einen Schwellenwert nicht übersteigen darf.
Verwenden Sie für Reviews immer einen anderen Agenten als den, der die Arbeit gemacht hat.
Geben Sie eine Regel gegen das Weiterflicken mit. Zwei erfolglose Versuche, dann Methode wechseln.
Schreiben Sie in die Zielbedingung nur, was der Agent selbst herstellen kann. Ihre Zustimmung gehört nicht dazu.

#Werkzeuge und Quellen

Software: Blender 5.2.1 LTS mit dem Renderer Cycles; Blender MCP; Ruff als Linter für die Szenenskripte. Gerechnet wurde auf einem MacBook Pro M1 Pro mit 16 GB.

Agenten: Codex mit GPT-Astra für Aufbau und erste Überarbeitung, Claude Code mit Claude Opus für den Feinschliff und den Innenraum.

Geodaten: OpenGeodata.NRW mit Flurstücksgeometrie, digitalen Orthophotos und LoD2-Gebäudemodellen.

Assets: Poly Haven und ambientCG für HDRIs und Materialien, BlenderKit für Einzelmodelle.

Recherche: Zwei Deep-Research-Berichte zu Architekturvisualisierung in Blender (Claude und ChatGPT), dazu kürzere Berichte zu Einzelfragen.