NCA Social Media
Aktualisiert:
Autor:
Roland Golla

Was unkontrollierter KI Code wirklich kostet

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.

Der Ablauf ohne Regeln 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.

Bezahlt wird das an anderer Stelle. Reviews dauern länger, weil niemand weiß, welches Muster diesmal gilt. Neue Leute brauchen Wochen statt Tage. Und irgendwann traut sich keiner mehr an den Bereich, in dem die KI am fleißigsten war.

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.

Inhalt

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

Erreichen Sie unsere PHP Consultant Spezialisten

Wir sind Experten für PHP und helfen Ihnen, Ihre digitalen Herausforderungen zu meistern. Unser erfahrenes Team unterstützt Sie bei PHP Updates, PHP Refactoring und berät Sie remote zu allen Fragen rund um PHP. Mit unseren vollautomatischen CI/CD Deployments und einer robusten Docker-Infrastruktur bringen wir Ihre PHP-Projekte auf das nächste Level. Vertrauen Sie auf unsere Expertise für zuverlässige und skalierbare PHP-Lösungen.

Demo Team Workshop Anrufen

Warum NCA und was das für euch bedeutet

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.

Häufige Fragen zu den NCA PHP AI Coding Guidelines

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.

Was sind AI Coding Guidelines 2026?

AI Coding Guidelines sind verbindliche Regeln für die Zusammenarbeit mit KI Coding Agents im eigenen Projekt. Sie bestehen aus Rules Dateien wie AGENTS.md, aus Spezifikationen pro Änderung, aus Tests als Abnahmekriterium und aus Quality Gates in der Pipeline. Ziel ist Code, der zum Projekt passt, reviewt ist und wartbar bleibt, statt zufällig funktionierender Einzellösungen.

Lohnen sich AI Coding Guidelines 2026 auch für Legacy PHP Projekte?

Gerade dort. In gewachsenen Codebasen fehlt dem Agenten jeder Anhaltspunkt, welches der vielen vorhandenen Muster das gewollte ist. Ohne Regeln kopiert er den ältesten Code, den er findet. Mit klaren Vorgaben und einer Testbasis an den kritischen Stellen wird Legacy Code zum ersten Mal seit Jahren wieder planbar veränderbar.

Welche Werkzeuge braucht ein PHP Team 2026 dafür?

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

Wie lange dauert die Einführung 2026?

Das hängt an Größe und Zustand der Codebasis. Die erste Fassung der Regeln und eine durchgezogene Beispielaufgabe stehen meist innerhalb weniger Tage. Fehlt die Testbasis oder die Pipeline komplett, wird daraus ein längeres Vorhaben. Wir schätzen den Aufwand nach dem ersten Blick in euer Projekt ehrlich ein, bevor irgendetwas beginnt.

Funktionieren die Guidelines 2026 mit jedem KI Coding Agent?

Ja. Die Artefakte sind offene Formate im Repository. AGENTS.md wird inzwischen von den meisten Agents gelesen, Claude Code nutzt zusätzlich CLAUDE.md. Spezifikationen, Tests und Pipeline sind ohnehin werkzeugunabhängig. Wechselt ihr den Agenten oder das Modell, bleiben die Guidelines bestehen. Genau das ist der Sinn der Sache.

Was gehört in eine AGENTS.md für ein Symfony Projekt?

Ordnerstruktur und Namenskonventionen, das gewählte Muster für Services und Repositories, die Regeln für Doctrine Entities und Migrationen, der Umgang mit Konfiguration und Secrets sowie die Testpflichten. Mindestens genauso wichtig sind die Verbote: welche Bibliotheken nicht mehr genutzt werden und welche Bereiche der Agent gar nicht anfassen darf.

Wir haben fast keine Tests. Geht das trotzdem?

Ja, und ihr seid damit nicht allein. Viele Teams kommen genau deshalb zu uns. Wir bauen die Testbasis nicht flächendeckend auf, sondern gezielt dort, wo künftig KI Code entstehen soll. Diese Tests zahlen doppelt ein, weil sie auch Refactorings und Versionsupdates absichern.

Wie verhindert ihr, dass der Agent die Regeln ignoriert?

Gar nicht auf der Ebene des guten Willens. Ein Agent hält Regeln mal ein und mal nicht, das ist normal. Deshalb steht hinter jeder wichtigen Regel eine automatische Prüfung. PHPStan, Coding Standard, Tests und Rector laufen in der Pipeline. Was durchfällt, wird nicht gemergt, egal wer oder was es geschrieben hat.

Was ist der Unterschied zwischen Prompt und Spezifikation?

Ein Prompt lebt im Chatfenster und ist nach der Sitzung verschwunden. Eine Spezifikation liegt im Repository, ist versioniert und für alle lesbar. Sie beschreibt das gewünschte Ergebnis und die Akzeptanzkriterien. Beim Review vergleicht ihr Code und Spezifikation statt zu raten, was gemeint war.

Ersetzen die Guidelines das Code Review?

Nein, sie machen es kürzer und schärfer. Formatierung, Typfehler und Standardverstöße fängt die Pipeline ab. Im Review bleibt die Frage, die nur Menschen beantworten können: Ist das fachlich richtig und ist die Architekturentscheidung für dieses Projekt sinnvoll. Genau dafür gewinnt ihr Zeit zurück.

Was kostet die Einführung?

Wir arbeiten ohne Festpreise und ohne Pakete. Der Einstieg ist ein kostenloses Kennenlernen, in dem wir euer Projekt und euer Ziel verstehen. Danach schätzen wir den Aufwand ein und rechnen minutengenau ab. Ihr zahlt für Arbeit an eurem Code und seht jederzeit, wofür.

Arbeitet ihr remote oder vor Ort?

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

Gilt das nur für PHP?

Die vier Ebenen sind sprachunabhängig, nur die Werkzeuge wechseln. In Astro und TypeScript Projekten übernehmen ESLint, strikte Typen und Vitest die Rolle von PHPStan und PHPUnit, in Python sind es Ruff, mypy und pytest. Die PHP Ausbaustufe ist die erste, weitere Stacks folgen nach demselben Muster.

Technik, Werkzeuge und Datenschutz

Die zweite Runde geht in die Details. Welche Werkzeuge greifen wo, was passiert mit euren Daten und wie merkt ihr überhaupt, ob die Guidelines etwas bringen.

Läuft das auch mit lokalen Modellen über Ollama?

Ja. Wir arbeiten selbst täglich mit Ollama und Modellen wie Qwen3 Coder lokal. Die Guidelines sind reine Dateien im Repository und interessieren sich nicht dafür, welches Modell sie liest. Für Teams mit strengen Vorgaben ist das der Weg, bei dem kein Quellcode das eigene Netz verlässt.

Müssen unsere Daten dafür in eine US Cloud?

Nein. Es gibt drei Wege: lokale Modelle über Ollama, gehostete Inferenz bei einem europäischen Anbieter oder eine Cloud eurer Wahl. Für Projekte mit hohen Anforderungen arbeiten wir mit unserem Duisburger Netzwerkpartner <a href="https://www.conversis.de/" target="_blank" rel="noopener">Conversis</a> zusammen, der gehostete Inferenz nach DSGVO Vorgaben anbietet.

Welchen PHPStan Level setzt ihr an?

Den, den eure Codebasis heute schafft, und von dort aus schrittweise nach oben. Ein Projekt direkt auf Level 8 zu zwingen erzeugt tausende Fehler und ein Gate, das dauerhaft rot ist. Ein rotes Gate wird ignoriert. Wir sichern erst den Bestand ab und ziehen den Level dann Modul für Modul nach.

Was macht Rector PHP in dem Aufbau?

Rector PHP automatisiert Codeänderungen nach Regeln. Im Zusammenspiel mit KI Code ist das doppelt nützlich: Veraltete Muster werden automatisch modernisiert, und der Agent bekommt eine Codebasis vorgesetzt, die einheitlich aussieht. Je gleichförmiger der Bestand, desto besser trifft die KI beim nächsten Mal den richtigen Stil.

Wie passt Cypress dazu?

PHPUnit prüft die Logik, Cypress prüft, ob die Anwendung im Browser noch das tut, was sie soll. Gerade bei KI Code lohnt sich das, weil Agenten gern Templates und Formulare mit anfassen. Roland Golla ist Cypress Ambassador, das Werkzeug läuft bei uns in jedem Projekt.

Funktioniert das in einem Monorepo mit mehreren Anwendungen?

Ja, und dort zahlt es sich besonders aus. Wir legen eine schlanke Basisdatei auf Wurzelebene an und ergänzen pro Anwendung eigene Regeldateien. Der Agent lädt nur, was zum aktuellen Verzeichnis passt. So bleibt das Kontextfenster frei für die eigentliche Aufgabe.

Was passiert mit unseren bestehenden Coding Standards?

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

Wie messen wir, ob die Guidelines wirken?

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

Wem gehören die Guidelines am Ende?

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

Wie oft müssen die Guidelines aktualisiert werden?

Immer dann, wenn sich eine Architekturentscheidung ändert oder ein neues Muster im Projekt 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 wieder verschwindet.