Das Werkzeug ist nicht der Architekt

KI-Coding-Tools sind das einfachste Argument in dieser ganzen Debatte, wenn man Entwickler:innen überzeugen will. Genau deshalb muss dieser Beitrag vorsichtig sein.

Es wäre leicht zu sagen: Agenten schreiben Code schneller, Indie-Devs haben zu wenig Ressourcen, also benutzt die Tools und liefert aus. Da steckt etwas Wahres drin. Da steckt auch eine Falle drin.

Die Vorbehalte gegen KI auf Entwicklerseite sind nicht nur Nostalgie nach handgetipptem Code. Ein Teil davon ist Handwerksverteidigung. Ein Teil davon ist die Erinnerung daran, Code aufgeräumt zu haben, den niemand verstanden hat. Ein Teil davon ist die Beobachtung, wie "Vibe Coding" zur stillen Erlaubnis wird, Systeme auszuliefern, die plausibel wirken, bis ein Spieler den einen Zustand trifft, den niemand getestet hat. Ein Teil davon ist das Erleben von Pull Requests, die komplett von einem Agenten geschrieben wurden und deren Autor weder das Design noch den Tradeoff noch den Fehlermodus erklären kann.

Diese Vorbehalte haben einen Punkt.

Gute Entwickler:innen werden nicht nur dafür bezahlt, Codezeilen zu produzieren. Sie werden dafür bezahlt, Unsicherheit zu reduzieren. Sie verwandeln unklare Anforderungen in eine begrenzte Implementierung. Sie wählen die langweilige Lösung, wenn langweilig richtig ist. Sie merken, wenn ein Feature-Request eigentlich ein Designproblem ist, wenn ein Bug-Report eigentlich ein Architekturproblem ist, und wenn eine clevere Abstraktion die nächsten drei Wochen schlechter machen wird.

KI nimmt diese Arbeit nicht weg. Sie kann sie verstecken. Das ist die Gefahr. Ein großer Diff kann sich wie Fortschritt anfühlen, auch wenn die eigentlichen Entscheidungen noch offen sind. Ein funktionierender Prototyp kann sich wie ein Beweis anfühlen, auch wenn er nur den Happy Path bewiesen hat. Ein generiertes Refactoring kann sich wie Sauberkeit anfühlen, auch wenn es das lokale Wissen ausradiert hat, das das System debuggbar gemacht hat.

Code, der schnell entsteht, kann trotzdem schlechter Code sein. Code, der kompiliert, kann trotzdem die falsche Architektur sein. Code, der einen schmalen Test besteht, kann trotzdem den Build brechen, Performance verlieren, State-Bugs erzeugen oder die nächste Person dazu bringen, die Datei nicht anfassen zu wollen.

Die Antwort von Clowdr ist nicht "KI ist die Zukunft, gewöhn dich dran." Das wäre zu billig für die Arbeit. Die Antwort ist derselbe Standard, den wir für Art und Audio anwenden: Tools dürfen helfen, aber jemand verantwortet das Ergebnis.

Geschwindigkeit ohne Urteilskraft ist kein Feature.

Architektur ist immer noch deine Aufgabe

Ein Agent kann ein Feature scaffolden. Er kann einen Controller schreiben, eine Komponente skizzieren, ein Save-System entwerfen, ein Menü verkabeln, eine Engine-API erklären, einen Testfall generieren oder ein Refactoring vorschlagen.

Das ist nützlich.

Das ist keine Architektur.

Architektur ist die Entscheidung, wohin das Feature gehört, wovon es abhängen soll, was es nicht wissen soll, wie es scheitert, wie es später verändert wird und was passiert, wenn das Spiel um es herum wächst. In der Spieleentwicklung bedeutet Architektur außerdem, die Engine zu respektieren, die Asset-Pipeline, das Build-Target, das Frame-Budget, das Input-Modell, das Save-Format und die unaufgeräumte Realität, dass "es funktioniert einmal" nicht dasselbe ist wie "es gehört hierher."

Entwickler:innen behalten die Verantwortung für Architektur, Scope, Wartbarkeit und Integration.

Scope ist wichtig, weil Agenten gut darin sind, Oberfläche hinzuzufügen. Frag nach einem kleinen Inventarsystem und du bekommst vielleicht Kategorien, Seltenheitsfarben, Drag-and-Drop, Sortierung, Tooltips, Persistierung, Analytics-Hooks und drei Abstraktionen, die du nie gebraucht hast. Das sieht nach Fortschritt aus, bis das Feature das Projekt verdoppelt hat.

Disziplinierte Entwickler:innen kürzen den Prompt, bevor der Agent Code schreibt. Sie entscheiden, was das Feature tun muss, was es nicht tun darf, welche bestehenden Systeme es wiederverwenden soll und was zu viel wäre. Sie lehnen nützlich aussehende Ergänzungen ab, wenn diese die Wartungslast vergrößern, ohne das Spiel zu verbessern.

Wartbarkeit ist wichtig, weil irgendjemand diesen Code in sechs Wochen debuggen muss. Wenn die einzige "Person", die die Implementierung verstanden hat, das Modell war, das sie erzeugt hat, verantwortet niemand den Code.

Wartbarkeit ist kein Vibe. Sie ist die Frage, ob ein:e andere:r Mitwirkende:r dem Kontrollfluss folgen kann, ob ein:e Designer:in die Zahlen ohne Quellcodeänderung justieren kann, ob eine QA-Notiz auf eine Stelle zeigt, die Entwickler:innen tatsächlich inspizieren können, und ob das nächste Feature hinzugefügt werden kann, ohne das erste umzuschreiben. KI kann beim Erzeugen sauberen Codes helfen, aber sie kann nicht entscheiden, was Klarheit in deinem Projekt bedeutet.

Integration ist wichtig, weil Game-Code fast nie allein lebt. Er berührt Scenes, Prefabs, Animationszustände, UI, Physik, Content-Daten, Audio-Trigger, Savefiles, Lokalisierung, Plattform-Eigenheiten und Spielerverhalten. Ein generiertes Feature, das diese Kanten ignoriert, ist nicht fertig. Es ist ein Entwurf mit Selbstvertrauen.

Verifikation sind nicht nur Unit-Tests

Der Clowdr-Standard ist derselbe wie in How We Ship:

Kein generiertes Ergebnis wird ausgeliefert, ohne dass ein Mensch die Verantwortung übernimmt und einen angemessenen Verifikationsdurchgang macht.

Für Code bedeutet menschliche Verantwortung, dass eine Entwickler:in erklären kann, was sich geändert hat, warum es dort hingehört, welche Annahmen es macht und wie es verifiziert wurde.

Ein angemessener Verifikationsdurchgang hängt von der Änderung ab.

Manchmal ist das ein Unit-Test. Manchmal ein Smoke-Test. Manchmal ein sauberer Build auf der Zielplattform. Manchmal ein Profiler-Lauf, weil der generierte Pfad in jedem Frame alloziert. Manchmal ein Playtest, weil der Bug nicht "die Funktion gibt false zurück" lautet, sondern "die Spielerin kann das Level soft-locken, indem sie während eines Übergangs das Menü öffnet." Manchmal ist es das alles zusammen.

Spiele sind keine SaaS-Dashboards. Verifikation lässt sich nicht auf "der Test ist grün" reduzieren. Ein Test beweist ein Verhalten. Ein Build beweist, dass das Projekt noch kompiliert. Ein Profiler beweist, dass die Abkürzung das Frame-Budget nicht verbrannt hat. Ein Playtest beweist, dass die State Machine echte Menschen überlebt.

Verifikation heißt auch, die langweiligen Ränder zu prüfen. Lädt der Save-Stand noch, nachdem die Datenstruktur sich geändert hat? Funktioniert das Feature nach einem Scene-Reload? Verhält es sich bei Pause, Tod, Neustart, Verbindungsabbruch, Rebinding, Lokalisierung, niedriger Framerate und Controller-Input richtig? Macht der Editor-Workflow noch Sinn für die Person, die den Content platzieren muss? Hat der generierte Code eine versteckte Abhängigkeit von Dateireihenfolge, Objektnamen, Update-Timing oder einer bestimmten Auflösung eingeschleppt?

Diese Prüfungen sind keine Bürokratie. Sie sind der Unterschied zwischen einer Demo und einem Produkt.

Entwickler:innen wählen den Verifikationsdurchgang. Dann verantworten Entwickler:innen das Ergebnis.

Was diesen Standard nicht erfüllt

Ein vom Agenten generiertes Feature, das gemerged wird, weil es "richtig aussah," erfüllt ihn nicht.

Ein Pull Request, dessen Autor:in die Architektur nicht erklären kann, erfüllt ihn nicht.

Ein Refactoring, das Duplikation entfernt, aber Editor-Workflows, Asset-Referenzen oder Debugging-Klarheit kaputt macht, erfüllt ihn nicht.

Ein Save-System, das aus einem Prompt generiert wurde und keinen Migrationsplan hat, erfüllt ihn nicht.

Eine UI-Implementierung, die in einer Auflösung funktioniert und auf dem Steam Deck zusammenbricht, erfüllt ihn nicht.

Ein KI-geschriebenes Gameplay-System, das nie einen Playtest-Build berührt, erfüllt ihn nicht.

Eine performance-kritische Schleife, die ohne Profiling akzeptiert wird, erfüllt ihn nicht.

Scope Creep, versteckt unter "das schafft der Agent schon," erfüllt ihn nicht.

Das ist die Dev-Variante von Slop: plausibler Output ohne Verantwortliche. Der Code mag syntaktisch in Ordnung sein. Der Schaden steckt in den ungeprüften Entscheidungen, ungetesteten Zuständen, versteckten Kopplungen und in der zukünftigen Wartung, für die niemand Budget hat.

Dieselbe Regel gilt für handgeschriebenen Code. Ein handgemachtes System, das niemand warten kann, erfüllt den Standard auch nicht. Handwerk zählt. Produktdenken auch.

Derselbe Standard gilt rollenübergreifend

Der Dev-Beitrag bekommt kein eigenes moralisches Universum.

Der Künstler-Standard in Geschmack ist immer noch der Job sagt, dass generierte Bilder Entwürfe sind, bis ein:e Künstler:in Kohärenz, Politur, Rechte und finale Richtung verantwortet. Der Komponisten-Standard in Sound ist mehr als Generierung sagt, dass generiertes Audio Entwurfsmaterial ist, bis ein:e Komponist:in emotionale Absicht, Timing, Mix, Implementierung und Rechte verantwortet.

Code ist nicht anders.

Generierter Code ist Entwurfsmaterial, bis ein:e Entwickler:in Architektur, Scope, Wartbarkeit, Integration und Verifikation verantwortet.

Dieser rollenübergreifende Standard ist wichtig, weil Spiele an den Nahtstellen scheitern. Eine Code-Abkürzung kann Art-Schulden erzeugen. Eine schlechte Asset-Pipeline kann Engineering-Schulden erzeugen. Eine Musikcue, die sich nicht implementieren lässt, kann Design-Schulden erzeugen. Niemand darf Output über die Mauer werfen und das "fertig" nennen.

Clowdr ist für Mitwirkende gebaut, die wollen, dass die Arbeit den Kontakt mit dem Produkt überlebt.

Welche Entwickler:innen hier hingehören

Clowdr ist für Entwickler:innen, die Spiele mit anderen Mitwirkenden ausliefern wollen, die ebenfalls ihre Arbeit verantworten.

Nicht für Leute, die wollen, dass Agenten ihr Urteil ersetzen. Nicht für Leute, die ungeprüften Code in ein gemeinsames Projekt kippen und die nächste Person das aufräumen lassen wollen. Nicht für Leute, die handgeschriebenen Code automatisch für hochwertiger halten.

Wenn du KI nutzt, um schneller zu sein, und trotzdem Verantwortung für Architektur, Scope, Wartbarkeit, Integration und Verifikation übernimmst, passt du in den Standard.

Wenn du keine KI nutzt und denselben Anspruch erfüllst, passt du auch.

Das Werkzeug ist nicht der Architekt. Die Entwickler:in ist es.

Dieser Standard verantwortet sich vor How We Ship. Die operative Version ist Der Clowdr KI-Standard, der die domänenspezifischen Prüfungen genauer definiert.

Wenn das nach dem Standard klingt, unter dem du arbeiten möchtest, melde dich an.