Die NCA PHP AI Coding Guidelines sind ein Regelwerk aus Rules Dateien, Spezifikationen, Tests und Quality Gates, das wir in bestehende PHP und Symfony Projekte einbauen. Es legt fest, wie ein KI Agent in eurem Code arbeiten darf und was erfüllt sein muss, bevor sein Ergebnis live geht.

Den Ablauf kennt jedes Team. Jemand öffnet Claude Code, beschreibt in zwei Sätzen, was fehlt, und bekommt eine funktionierende Klasse zurück. Sie läuft. Sie passt nur nicht zum Rest.

Beim nächsten Ticket passiert dasselbe. Nach drei Monaten gibt es vier Arten, einen Service zu registrieren, zwei Wege der Validierung und Tests, die nur den Happy Path kennen. Kein einzelner Commit war falsch. Die Summe ist es.

Das Problem ist nicht die KI. Das Problem ist, dass niemand ihr gesagt hat, wie in diesem Projekt gearbeitet wird. Ein neuer Entwickler lernt das über Reviews und Gespräche am Schreibtisch. Ein Agent liest nur, was im Repository steht.

Never Code Alone ist eine Agentur aus Duisburg mit Schwerpunkt Softwarequalität. Roland Golla ist der Gründer. Sein Thema: Die KI schreibt den Code, er sorgt für die Qualität. Automatisiertes Testen läuft hier seit 2013. PHPUnit, PHPStan und Rector PHP sind Tagesgeschäft und nicht Folienthema.

Wir pflegen eine eigene AGENTS.md aus den NCA dotfiles und arbeiten täglich mit Claude Code und OpenCode, dazu mit lokalen Modellen über Ollama. Was wir bei euch einbauen, läuft bei uns selbst in Produktion. Roland ist Cypress Ambassador und hat Tests zum TYPO3 Core beigetragen. Das Thema ist über Jahre gewachsen und nicht gerade erst entdeckt.

Die Guidelines greifen in unsere übrigen Leistungen. Den Rahmen gibt das PHP Consulting. Gewachsener Code wird über PHP Refactoring wieder beherrschbar, alte Versionen räumt das PHP Update ab. Durchgesetzt werden die Regeln in der CI CD Pipeline mit Docker und Staging. Wer den Blick über PHP hinaus braucht, findet ihn im Vibe Coding Consulting und bei den Vibe Coding CI CD Pipelines.

Die meisten Teams starten mit einer Regeldatei. Jemand schreibt eine AGENTS.md, packt zwanzig Punkte hinein und wundert sich, dass der Agent die Hälfte davon vergisst. Eine Regel, die niemand prüft, ist nur ein Wunsch.

Deshalb bauen wir vier Ebenen ein, die aufeinander aufsetzen. Die Regeln sagen dem Agenten, wie euer Projekt tickt. Die Spezifikation sagt ihm, was diesmal genau entstehen soll. Die Tests entscheiden, ob er fertig ist. Und die Pipeline lässt nichts durch, was durchfällt.

Erst dann ist der Kreis geschlossen. Jede Ebene für sich lässt sich umgehen. Zusammen bilden sie ein Netz, durch das kein unfertiger KI Commit mehr rutscht.

Eine gute Regeldatei ist keine Liste guter Vorsätze. Sie beschreibt das Projekt, das ihr wirklich habt.

Wir lesen dafür zuerst eure Codebasis. Welche Ordnerstruktur gilt, wie werden Services registriert, welches Repository Muster ist gesetzt, wo liegen die Ausnahmen, die historisch gewachsen sind. Daraus entsteht ein Regelwerk, das euer Projekt beschreibt statt allgemeiner PHP Weisheiten.

Wichtig ist der Umfang. Jede Zeile in der Regeldatei kostet Kontext, und ein volles Kontextfenster macht Agenten schlechter, nicht besser. Wir halten die Basisdatei schlank und lagern Spezialwissen in eigene Dateien aus, die nur bei passenden Aufgaben geladen werden.

Genauso wichtig sind die Verbote. Was der Agent nicht anfassen darf, welche Bibliothek nicht mehr genutzt wird, welche Migration nur von Hand läuft. Ein klares Nein spart mehr Reviewzeit als zehn wohlwollende Empfehlungen. Wie sich solche Dateien sinnvoll aufteilen lassen, zeigen wir im Detail bei den Rules Dateien für KI Coding Agents.

Ein Prompt im Chat ist flüchtig. Er steht in einem Fenster, das morgen geschlossen ist, und niemand kann später nachlesen, was eigentlich bestellt war.

Eine Spezifikation liegt im Repository. Sie beschreibt in wenigen Absätzen, was gebaut werden soll, welche Fälle abgedeckt sein müssen und woran man erkennt, dass es fertig ist. Der Agent arbeitet gegen dieses Dokument, nicht gegen eine Erinnerung.

Der Effekt zeigt sich beim Review. Statt Zeile für Zeile zu raten, was gemeint war, vergleicht ihr Ergebnis und Spezifikation. Abweichungen fallen sofort auf. Und wenn ein halbes Jahr später jemand fragt, warum das so gelöst ist, steht die Antwort im Git Verlauf.

Wir setzen das mit den Werkzeugen auf, die zu eurem Team passen. Für strukturierte Vorgehen gibt es fertige Ansätze wie OpenSpec, für kleinere Projekte reicht oft ein schlankes eigenes Format. Den methodischen Hintergrund dazu haben wir unter Exact Coding zusammengefasst.

Ein Agent hört auf, wenn er sich für fertig hält. Das ist der Kern des Problems. Er hat kein Gefühl dafür, ob eine Lösung trägt, er hat nur ein Abbruchkriterium.

Tests liefern genau dieses Kriterium in messbarer Form. Wenn ein PHPUnit Test den Fall beschreibt, bevor der Code entsteht, arbeitet der Agent auf ein Ziel hin, das nicht verhandelbar ist. Grün oder nicht grün. Keine Selbsteinschätzung.

Viele Teams kommen genau hier ins Stocken, weil kaum Tests existieren. Das ist kein Ausschlusskriterium, sondern der erste Auftrag. Wir bauen die Testbasis dort auf, wo sie am meisten trägt: an den Stellen, an denen KI Code künftig entstehen soll. Für die Oberfläche kommt Cypress dazu, für kritische Pfade Mutation Testing mit Infection, damit ihr wisst, ob eure Tests überhaupt etwas prüfen.

Ein angenehmer Nebeneffekt: Dieselben Tests machen auch das PHP Refactoring und jedes künftige PHP Update deutlich ruhiger.

Solange eine Regel nur in einer Markdown Datei steht, hängt sie am guten Willen. Am Freitagnachmittag verliert der gute Wille.

Deshalb wandern die wichtigsten Regeln in die Pipeline. PHPStan prüft Typen und tote Pfade, Rector PHP hält den Code auf der Zielversion, ein Coding Standard erzwingt die Formatierung, PHPUnit und Cypress prüfen das Verhalten. Was durchfällt, wird nicht gemergt. Auch dann nicht, wenn eine KI es geschrieben hat.

Der Level ist dabei kein Dogma. Wir starten auf dem Level, das eure Codebasis heute schafft, und ziehen ihn schrittweise nach. Ein Gate, das dauerhaft rot ist, wird ignoriert und schadet mehr, als es nützt.

Läuft bei euch noch keine Pipeline, ist das der passende Einstieg über die CI CD Pipeline mit Docker, Staging und Preview URLs. Wer zusätzlich automatisierte Reviews möchte, findet den Ansatz beim automatisierten KI Code Review.

Wir fangen nicht mit einem Konzept an, sondern mit eurem Code. In den ersten Tagen arbeiten wir im Hintergrund: Codebasis lesen, Muster erkennen, Testlage prüfen, Pipeline anschauen. Danach wissen wir, wo die Guidelines ansetzen müssen.

Dann schreiben wir die erste Fassung der Regeln und Spezifikationen und ziehen sie an einer echten Aufgabe durch. Kein Beispielprojekt, sondern ein Ticket aus eurem Backlog. Ihr seht am selben Tag, was sich am Ergebnis ändert.

Der dritte Schritt ist das Team. Wir arbeiten in Pair Programming Sessions, gehen Reviews gemeinsam durch und zeigen, wie eine Aufgabe an den Agenten übergeben wird, damit sie beim ersten Versuch sitzt. Wissen, das nur bei uns bleibt, hilft euch nach dem Projekt nicht weiter.

Am Ende gehören die Guidelines euch. Sie liegen in eurem Repository, nutzen offene Werkzeuge und funktionieren mit jedem Agenten, den ihr morgen einsetzen wollt. Keine Plattform, aus der ihr später schwer wieder herauskommt. Wir arbeiten remote oder vor Ort in Duisburg und im gesamten DACH Raum.

Der Einstieg ist ein kostenloses Kennenlernen. Danach schätzen wir den Aufwand ehrlich ein und rechnen minutengenau ab. Ihr zahlt für Arbeit an eurem Code, nicht für ein Paket.

Die vier Ebenen sind bewusst unabhängig von der Sprache gedacht. Regeln, Spezifikation, Tests, Quality Gates. Was sich ändert, sind die Werkzeuge dahinter.

In PHP und Symfony sind das PHPStan, Rector PHP, PHPUnit und ein Coding Standard. In Astro und TypeScript Projekten übernehmen ESLint, TypeScript im strikten Modus und Vitest dieselbe Rolle. In Python arbeiten wir mit Ruff, mypy und pytest. Über allem steht Cypress für die Oberfläche.

Deshalb geben wir dem Produkt einen Stack im Namen. Die NCA PHP AI Coding Guidelines sind die erste Ausbaustufe, weitere Stacks folgen nach demselben Muster. Teams mit gemischten Repositories bekommen so ein Vorgehen, das überall gleich funktioniert, ohne dass jede Sprache ihr eigenes Regelwerk erfindet.

Bei Never Code Alone sitzen keine Berater mit Foliensätzen. Unsere Consultants sind aktive Entwickler, die täglich mit PHPStan, Rector PHP und PHPUnit arbeiten und genauso täglich mit Claude Code und OpenCode. Beide Welten in einer Hand, das ist der Unterschied.

Wir verkaufen kein Konzept, sondern etwas, das bei uns selbst läuft. Unsere eigene Website und unsere Open Source Arbeit laufen durch dieselben Gates, die wir bei euch einbauen. Wenn beim Aufsetzen Grundsätzliches auffällt, sagen wir es deutlich, auch wenn es den Auftrag verlängert.

Rund um die Guidelines greifen weitere Leistungen. Den Rahmen setzt das PHP Consulting, gewachsenen Code räumt PHP Refactoring auf, alte Versionen hebt das PHP Update. Für Deployments sorgt die CI CD Pipeline mit Docker, für aufgeräumte Oberflächen das Symfony Frontend Refactoring. Formulare direkt ins Team Chat bringt der Telegram Bot für PHP Formulare.

Soll das Wissen dauerhaft im Team bleiben, passen der Cypress Workshop, das PHP Training mit PHPStan, die Sulu CMS Schulung für Symfony und das NCA RuhrRefactoring Consulting.

Wer KI Code über PHP hinaus absichern will, findet den Einstieg im Vibe Coding Consulting, beim Codebase Audit für KI generierten Code, beim Vibe Coding Security Audit, bei den Vibe Coding CI CD Pipelines und bei AI Code in Produktion. Die Methodik dahinter steht bei Exact Coding und in den Vibe Coding Best Practices.

Die Fragen, die in fast jedem Erstgespräch kommen, kurz beantwortet. Von der Testlage über die Werkzeugwahl bis zur Frage, wie lange die Einführung dauert.