Ein Regelwerk für die Zusammenarbeit mit KI Coding Agents im eigenen Projekt. Dazu gehören Rules Dateien wie AGENTS.md, eine Spezifikation je Änderung, Tests als Abnahmekriterium und automatische Prüfungen in der Pipeline. Ziel ist Code, der zum bestehenden Projekt passt und sich genauso reviewen und warten lässt wie handgeschriebener.

Dort besonders. In gewachsenen Codebasen liegen meist mehrere Muster nebeneinander, und ohne Vorgabe greift ein Agent gern das erstbeste auf, das er findet, auch wenn es zehn Jahre alt ist. Mit klaren Regeln und einer Testbasis an den kritischen Stellen wird die Arbeit an solchen Projekten wieder planbar.

Im PHP Umfeld arbeiten wir mit PHPStan, Rector PHP, PHPUnit, einem Coding Standard und Cypress für die Oberfläche. Alles Open Source und alles im Repository. Dazu kommt ein Agent eurer Wahl, meist Claude Code oder OpenCode, bei Bedarf mit lokalen Modellen über Ollama.

15 bis 30 Tage bis zum ersten belastbaren Stand: Regeln stehen, die ersten Gates laufen, der Agent arbeitet im Alltag mit. Am unteren Ende liegen Projekte mit vorhandener Versionskontrolle, Tests und laufender Pipeline. Fehlen Tests und CI komplett, wird daraus ein längeres Vorhaben. Danach folgen ein paar Tage pro Monat für die Pflege.

Ja. Alle Artefakte sind offene Dateien im Repository. AGENTS.md wird von den meisten Agents gelesen, Claude Code nutzt zusätzlich CLAUDE.md. Spezifikationen, Tests und Pipeline arbeiten ohnehin unabhängig vom Werkzeug. Ein Wechsel des Agenten oder des Modells lässt die Guidelines unberührt.

Ordnerstruktur und Namenskonventionen, das gewählte Muster für Services und Repositories, der Umgang mit Doctrine Entities und Migrationen, Konfiguration und Secrets sowie die Testpflichten. Dazu die Verbote: welche Bibliotheken nicht mehr verwendet werden und welche Bereiche der Agent gar nicht anfassen soll.

Ja, und das ist ein häufiger Ausgangspunkt. Wir bauen die Testbasis nicht flächendeckend auf, sondern zuerst dort, wo künftig KI Code entstehen soll. Diese Tests helfen später auch bei Refactorings und Versionsupdates, der Aufwand zahlt also mehrfach ein.

Auf Ebene des guten Willens gar nicht, denn ein Agent hält Regeln mal ein und mal nicht. Deshalb steht hinter jeder wichtigen Regel eine automatische Prüfung. PHPStan, Coding Standard, Tests und Rector laufen in der Pipeline, und was dort durchfällt, wird nicht gemergt.

Nein, sie verkürzen es. Formatierung, Typfehler und Standardverstöße fängt die Pipeline ab, bevor jemand hinschaut. Im Review bleibt die fachliche Frage, ob die Lösung richtig ist und die Architekturentscheidung zum Projekt passt. Dafür ist dann mehr Zeit da.

Die bleiben bestehen. Wir erfinden keine neuen Konventionen, sondern schreiben eure vorhandenen so auf, dass ein Agent sie versteht, und hängen eine automatische Prüfung dahinter. Fallen dabei Widersprüche auf, etwa zwei konkurrierende Muster im selben Projekt, sprechen wir das an und ihr entscheidet.

Wir arbeiten ohne Festpreise und ohne Pakete. Am Anfang steht ein kostenloses Kennenlernen, in dem wir euer Projekt und euer Ziel verstehen. Danach schätzen wir den Aufwand ein und rechnen minutengenau ab, sodass jederzeit nachvollziehbar bleibt, wofür ihr zahlt.

Beides. Der größte Teil läuft remote über Pair Programming Sessions und gemeinsame Reviews, was für die meisten Teams am besten funktioniert. Für Workshops und intensive Startphasen kommen wir auch vor Ort, von Duisburg aus in den gesamten DACH Raum.

Ja. Der Aufbau ist sprachunabhängig, es wechseln nur die Werkzeuge. Für Astro, React und Vue gibt es die AI Coding Guidelines für TypeScript Projekte, dort übernehmen der Compiler, ESLint und Vitest die Rolle von PHPStan und PHPUnit. Das sprachneutrale System hinter beiden sind die NCA Agentic AI Coding Guardrails.

Nein, nicht als zwei gepflegte Regelwerke. Die AGENTS.md hält alle Projektregeln, die CLAUDE.md verweist mit einer Importzeile darauf und enthält nur noch das, was wirklich Claude Code betrifft. So lesen Codex, Copilot und Cursor dieselbe Basis, und es gibt genau eine Stelle, an der Regeln gepflegt werden.

Regeln sind Text für das Modell und damit eine Bitte. Hooks sind Shell Befehle, die unabhängig vom Modell laufen und einen Vorgang abbrechen können. Für Arbeitsabläufe nehmen wir Regeln, für harte Grenzen Hooks. Beides zusammen ergibt erst eine Leitplanke, an der ein Agent nicht vorbeikommt.

Ja, das ist der Kern des Aufbaus. Der Hook am Ende des Agentenlaufs, der git Hook vor dem Commit und der Job in der Pipeline rufen dasselbe Skript auf. Dadurch verschwinden Überraschungen beim Merge, und niemand diskutiert mehr, warum etwas lokal grün war.

Wir arbeiten mit PHP 8.5, PHPStan 2, Rector 2 und aktuellem PHPUnit. Ältere Projekte holen wir nicht in einem Schritt dorthin. Wir setzen eine Baseline, ziehen den Level schrittweise nach und lassen Rector die mechanische Arbeit machen, damit das Team sich auf die fachlichen Stellen konzentriert.

Ja. Wir arbeiten selbst täglich mit Ollama und Modellen wie Qwen3 Coder auf eigener Hardware. Die Guidelines sind reine Dateien im Repository, denen es gleichgültig ist, welches Modell sie liest. Für Teams mit strengen Vorgaben ist das der Weg, bei dem kein Quellcode das eigene Netz verlässt.

Nein. Es gibt drei Wege: lokale Modelle über Ollama, gehostete Inferenz bei einem europäischen Anbieter oder eine Cloud eurer Wahl. Bei hohen Anforderungen arbeiten wir mit unserem Duisburger Netzwerkpartner Conversis zusammen, der gehostete Inferenz nach DSGVO Vorgaben anbietet.

Über LiteLLM als Proxy vor den Modellen. Jeder Aufruf läuft darüber, lokal wie in der Cloud, und landet mit Verbrauch und Kosten auf einem Dashboard. Darauf setzen Budgets je Nutzer, Team oder Projekt: Ist der Topf leer, leitet der Proxy nicht mehr weiter. Damit fällt ein durchlaufender Agent Loop sofort auf statt erst auf der Monatsrechnung.

Zentral über dieselbe Stelle. Wer welchen MCP Server erreichen darf, wird einmal vergeben statt in jeder lokalen Konfiguration einzeln gepflegt. Neue Kollegen bekommen den passenden Satz an Werkzeugen freigeschaltet, ohne dass Zugangsdaten per Chat weitergereicht werden.

Wir starten auf dem Level, den eure Codebasis heute erreicht, und ziehen ihn schrittweise nach. Ein Projekt direkt auf Level 8 zu zwingen erzeugt eine Fehlerliste, die niemand abarbeitet, und ein Gate, das dauerhaft rot steht. Solche Gates werden erfahrungsgemäß ignoriert.

Rector PHP führt Codeänderungen nach Regeln automatisch aus. Im Zusammenspiel mit KI Code hilft das zweifach: Veraltete Muster verschwinden ohne Handarbeit, und der Agent bekommt eine einheitlichere Codebasis vorgesetzt. Je gleichförmiger der Bestand, desto eher trifft er beim nächsten Mal den passenden Stil.

PHPUnit prüft die Logik, Cypress prüft, ob die Anwendung im Browser noch tut, was sie soll. Bei KI Code lohnt sich das, weil Agenten oft auch Templates und Formulare anfassen. Roland Golla ist Cypress Ambassador, das Werkzeug ist bei uns in jedem Projekt im Einsatz.

Ja. Eine schlanke Basisdatei liegt auf Wurzelebene, je Anwendung kommen eigene Regeldateien dazu. Der Agent lädt dann nur, was zum aktuellen Verzeichnis passt. Genauso wichtig: PHPStan und die Testsuite laufen je Anwendung, damit ein Fehler zeigt, wo er entstanden ist, statt eine Sammelmeldung über das ganze Repository zu erzeugen.

An Zahlen, die ohnehin vorliegen. Wie viele Kommentare hängen an einem Merge Request, wie lange bleibt er offen, wie oft geht ein Feature zurück in die Entwicklung, wie entwickelt sich die Testabdeckung. Wir sehen uns diese Werte vorher an, damit der spätere Vergleich etwas aussagt.

Euch. Alle Artefakte liegen als offene Dateien in eurem Repository, die Werkzeuge dahinter sind Open Source. Es gibt keine Plattform und keinen Zugang, der ablaufen kann. Ihr könnt das Ergebnis jederzeit ohne uns weiterentwickeln.

Immer dann, wenn sich eine Architekturentscheidung ändert oder ein neues Muster Einzug hält. In der Praxis sind das ein paar Zeilen pro Quartal. Wichtig ist, dass die Pflege im Team verankert ist, deshalb zeigen wir in den Sessions, wie eine Regel entsteht und wie sie wieder verschwindet.

Der Agent schreibt Migrationen, führt sie aber nicht gegen echte Bestände aus. Gearbeitet wird gegen eine lokale Entwicklungsumgebung mit Testdaten. Wo ein Agent an ein echtes System muss, läuft der Zugriff über definierte Werkzeuge statt über freien Datenbankzugang.

Die Regeln und Gates gelten für alle gleich, weil sie im Repository liegen und in der Pipeline laufen. Beim Agenten selbst hat jeder die freie Wahl. Wichtig ist nur, dass lokal dieselben Prüfungen laufen wie in der CI, sonst verschiebt sich die Fehlersuche in den Merge Request.