Der Agent liefert eine Komponente, der Bundler baut sie, der Deploy läuft durch. Auffällig wird die Sache erst, wenn im Formular ein Feld leer bleibt, für das es keine Fehlermeldung gibt. KI generierter Code fällt im Frontend nicht um, er zeigt einfach nichts an.

AI Coding Guidelines sind die Antwort darauf. Rules Dateien, Spezifikationen, Tests und Quality Gates legen in eurem bestehenden Astro, React oder Vue Projekt fest, wie ein KI Agent arbeiten darf und was erfüllt sein muss, bevor sein Ergebnis live geht. Ob ihr dabei mit Cursor, GitHub Copilot, Claude Code, Codex oder OpenCode arbeitet, spielt für die Regeln keine Rolle.

Der Preis für das Gegenteil steht in keiner Modellrechnung. Er steht in den Stunden, die später jemand mit dem Nachbauen von Zusammenhängen verbringt, und in der dritten und vierten Variante von etwas, das im Projekt längst existiert. Jede davon wird ab dann mitgepflegt.

Der Grund ist banal. Dem Agenten fehlt alles, was sich ein Mensch im Team über Reviews, Nachfragen und Gespräche nebenbei zusammensammelt. Was nicht im Repository steht, existiert für ihn nicht. Also erfindet er es, plausibel und falsch. In einem neuen Projekt fällt das kaum auf, in einer gewachsenen Codebasis sofort.

Ein KI Agent hat kein Gefühl dafür, ob etwas stimmt. Er hat ein Gefühl dafür, ob etwas plausibel aussieht. Das reicht für einen Entwurf und nicht für einen Merge.

Im Frontend gibt es genau eine Instanz, die unbestechlich antwortet und die der Agent selbst lesen kann: den TypeScript Compiler. In vielen gewachsenen Projekten ist er halb abgeschaltet. Der strict Mode steht auf false, Parameter ohne Typ gelten stillschweigend als beliebig, und an den heiklen Stellen steht ein as, das jede Prüfung wegräumt. Der Agent bekommt dann nichts zurück und produziert weiter.

Den strict Mode in einem bestehenden Projekt einzuführen ist deshalb der erste Schritt, und zwar in Stufen, damit die Zahl der Fundstellen bearbeitbar bleibt. Danach leiten wir die Regeln daraus ab. Fremde Daten kommen als unknown herein und werden geprüft, Konfigurationsobjekte hält satisfies gegen ihren Zieltyp, jeder switch über einen Union Type endet im Exhaustive Check, und ein as braucht eine Begründung im Kommentar.

Das sind vier Zeilen in der AGENTS.md. Sie sehen unspektakulär aus und nehmen einer ganzen Fehlerklasse den Boden, weil der Agent seine Annahmen offenlegen muss, statt sie wegzucasten.

Dazu kommt die Trennung von Typprüfung und Build. Bundler wie Vite entfernen Typinformationen und bauen weiter, egal wie kaputt die Typen sind. Erst als eigener Schritt wird der Type Check zum Quality Gate und macht die Pipeline rot, statt den Fehler still ins Bundle zu schieben.

Sobald mehr als eine Person mit Agenten arbeitet, wird aus der Spielerei ein Posten in der Buchhaltung. Ohne zentrale Stelle weiß niemand, welches Modell wie oft läuft und was am Monatsende zusammenkommt.

Wir stellen LiteLLM als Proxy vor die Modelle. Jeder Aufruf geht darüber, egal ob er bei einem lokalen Modell über Ollama landet oder bei einer Cloud API. Verbrauch und Kosten stehen damit pro Nutzer und pro Projekt auf einem Dashboard, statt verstreut in den Abrechnungen einzelner Anbieter.

Darauf setzen harte Budget Limits. Ist der Topf leer, leitet der Proxy nicht mehr weiter. Das ist im Moment unbequem und verhindert genau den Fall, in dem ein Agent über Nacht im Kreis läuft und die Summe erst auf der Rechnung auffällt.

Über dieselbe Stelle verteilen wir die MCP Server. Wer welchen Server erreichen darf, wird zentral vergeben statt in jeder lokalen Konfiguration einzeln gepflegt. Neue Kollegen bekommen den passenden Satz an Werkzeugen, ohne dass Zugangsdaten per Chat wandern.

Beim Datenschutz gilt bei uns eine klare Trennung: Coding aus der Cloud, Datenverarbeitung aus dem eigenen Netzwerk. Große Coding Modelle laufen über EU souveräne Anbieter, der Agent arbeitet gegen eine lokale Entwicklungsumgebung mit Testdaten und nie gegen echte Bestände. Wer ganz ohne externe Anbieter auskommen will, findet den Weg unter Self Hosted KI im Unternehmen mit Mandantentrennung und Audit Logging.

Der größte Effekt zeigt sich nicht beim Schreiben, sondern im Review. Wenn Struktur, Typen und Testpflicht vorgegeben sind, muss im Pull Request niemand mehr aushandeln, wie etwas gemacht werden soll. Diskutiert wird über das Was und nicht mehr über das Wie.

Das Code Review von KI Code ist ohnehin die Stelle, an der die meiste Zeit verbrennt. Jemand liest einen Diff, den in dieser Form niemand geschrieben hat, und sucht nach Annahmen, die nirgends stehen. Regeln und Gates nehmen einen Teil dieser Arbeit vorweg, damit im Review nur noch der Rest übrig bleibt.

Neue Kollegen sind schneller drin, weil das, was sonst über Nachfragen und Flurgespräche weitergereicht wird, als Datei im Repository steht. Dieselbe Datei liest der Agent. Was ihr für Menschen aufschreibt, wirkt gleichzeitig als Leitplanke für die Maschine, und das ist der eigentliche Trick an der Sache.

Wir arbeiten dabei nicht neben euch, sondern mit euch. Die Guidelines ziehen wir an einem echten Ticket aus eurem Backlog durch, in Pair Programming Sessions und gemeinsamen Reviews. Bei Never Code Alone beraten Entwickler, die selbst im Code stehen. Roland Golla ist der Gründer, Cypress Ambassador und hat Tests zum TYPO3 Core beigetragen. Automatisiertes Testen läuft bei uns seit 2013.

Soll das Wissen dauerhaft im Team bleiben, passt das KI Training für Entwicklerteams. Die Methodik dahinter steht bei Exact Coding und in den Vibe Coding Best Practices, der Aufbau der Regeldateien bei Rules Dateien für KI Coding Agents.

Der Deploy ist selten das Problem. Das Problem ist der Zustand, den er verteilt. KI generierter Code fällt im Frontend nicht um, er zeigt eine leere Stelle, und die entdeckt irgendwann jemand in der Oberfläche statt vorher im Log.

Wir ziehen den Zeitpunkt, an dem ein Fehler auffällt, deshalb nach vorne. Type Check, Linter mit Type Awareness, Vitest und Cypress laufen als eigene Quality Gates in der Pipeline, egal ob ihr GitLab CI, GitHub Actions oder etwas anderes fahrt. Was dort rot wird, geht nicht in den Hauptbranch. Aus einem Rollback am Freitagabend wird damit ein roter Job am Dienstagvormittag.

Für die Shipzeit heißt das in der ersten Woche: es kostet Tempo. Danach nicht mehr. Zurück kommen kürzere Reviews, weniger Rückfragen und Pull Requests, die durchlaufen statt zweimal zurückzukommen. Bis zum ersten belastbaren Stand rechnen wir mit 15 bis 30 Tagen. Regeln stehen, die ersten Gates laufen, der Agent arbeitet im Alltag mit.

Der Nebeneffekt ist Planbarkeit. Wenn jede Änderung dieselben Stufen durchläuft, hängt ein Release nicht mehr davon ab, wer es geschrieben hat und wie viel Zeit für das Review übrig war.

Wie das in der Pipeline aussieht, steht bei den Vibe Coding CI CD Pipelines und bei AI Code in Produktion. Die Stufen im Detail beschreiben die Quality Gates für KI Code. Gewachsenen Code räumt AI Slop Refactoring auf, und wenn der Bestand vorher geprüft werden soll, helfen der Codebase Audit für KI generierten Code und der Vibe Coding Security Audit.

Am Anfang steht ein kostenloses Kennenlernen. Danach schätzen wir den Aufwand für euer Projekt ein und rechnen minutengenau ab. Pakete, Mindestlaufzeiten und Festpreise gibt es bei uns nicht, weil der Aufwand am Zustand eurer Codebasis hängt und nicht an einer Preisliste.

Nach der Einführung bleibt eine Begleitung von wenigen Tagen im Monat sinnvoll. Regeln, die nicht mit dem Projekt mitwachsen, werden nach ein paar Monaten ignoriert. Das ist kein Werkzeugproblem, sondern der übliche Verfall von Dokumentation, den man von Anfang an einplanen sollte.

Die zweite Kostenseite sind die Modelle selbst. Über den Proxy stehen Verbrauch und Kosten pro Nutzer und pro Projekt auf einem Dashboard, harte Budget Limits stoppen die Weiterleitung, wenn der Topf leer ist. Ein Agent, der über Nacht im Kreis läuft, fällt damit sofort auf und nicht erst auf der Monatsrechnung.

Was ihr behaltet, gehört euch. Jede Regel liegt als offene Datei in eurem Repository, die Werkzeuge dahinter sind Open Source, und ihr macht ohne uns weiter. Was wir bei euch einbauen, betreiben wir selbst, von der eigenen Website bis zur Open Source Arbeit. Fällt beim Aufsetzen etwas Grundsätzliches auf, sagen wir es auch dann, wenn es gerade nicht passt.

Den Rahmen setzt das Frontend Development, den Einstieg über das Frontend hinaus das Vibe Coding Consulting. Das PHP Gegenstück zu dieser Seite sind die NCA PHP AI Coding Guidelines. Die einzelnen Bausteine der Regeln stehen im NCA TypeScript Glossar: unknown statt any, satisfies und der never Type. Für die Systemgrenze kommt Zod dazu, für Unit Tests Vitest, toten Code räumen Knip und Fallow weg. Die Grundlagen zur Sprache stehen im TypeScript Glossareintrag, den Weg in den strict Mode mit Astro und das Aufräumen überladener Oberflächen mit JavaScript ablösen haben wir separat beschrieben.

Was in Erstgesprächen und beim Aufsetzen immer wieder auf den Tisch kommt.

Die konkreten Fragen zu Konfiguration, Pipeline und dem Umgang mit euren Daten.