KI-Werkstatt: Mein Entwicklungs-Setup

In den letzten sieben Teilen ging es um Grundlagen: Projekt vorbereiten, Regeln schreiben, saubere Prompts, Grenzen kennen. Alles wichtig, alles richtig. Aber zwischen dem Lesen eines Tutorials und dem täglichen Arbeiten mit KI liegt ein Graben, den kein Artikel allein überbrückt. Dieser letzte Teil zeigt, was aus den Grundlagen geworden ist — ein Setup, das über Wochen gewachsen ist und mit jedem Projekt besser wird.

Von der Theorie zum System

In Teil 1 habe ich erklärt, warum eine CLAUDE.md den Unterschied macht. In Teil 2 ging es um Regeln, die verhindern, dass die KI eigene Entscheidungen trifft. Das stimmt alles noch. Aber nach 25 abgeschlossenen Aufgabenpaketen an einem Shopware-Plugin und einer Symfony-Anwendung habe ich gemerkt: Eine Projektbeschreibung und ein paar Regeln reichen nicht. Sie sind der Anfang, nicht das Ziel. Was fehlt, ist ein System, das über einzelne Sessions hinaus funktioniert — ein Gedächtnis, eine Arbeitsstruktur, eine Qualitätssicherung, die nicht von meiner Tagesform abhängt.

Das Ergebnis ist kein Framework, das ich dir verkaufen will. Es ist ein Arbeitsverzeichnis mit Textdateien, das sich über Wochen entwickelt hat. Jede Datei darin existiert, weil ohne sie etwas schiefgegangen ist.

Das BRIEF-System — Aufgaben statt Wünsche

Der größte Unterschied zwischen meinem heutigen Setup und dem, was ich in Teil 3 über Prompts geschrieben habe: Ich prompte kaum noch frei. Stattdessen arbeite ich mit BRIEFs — strukturierten Aufgabendokumenten, die beschreiben was gebaut werden soll, warum, und wann es fertig ist. Ein BRIEF hat ein Ziel, Anforderungen, Akzeptanzkriterien und eine Priorität. Er liest sich wie ein Ticket, nicht wie eine Wunschliste.

Warum der Aufwand? Weil freie Prompts bei komplexen Aufgaben versagen. Du schreibst „Bau mir einen Custom-Command für den Import“ und bekommst etwas, das technisch funktioniert, aber nicht in deine Architektur passt. Mit einem BRIEF sagst du: Hier ist der Service, hier ist das Interface, hier sind die Constraints, hier ist das Akzeptanzkriterium. Die KI implementiert, sie entscheidet nicht. Das klingt einschränkend, spart aber in der Praxis Stunden an Korrekturschleifen.

Nach 25 BRIEFs an einem einzigen Projekt kann ich sagen: Das System skaliert. BRIEF 1 hat die Grundstruktur angelegt, BRIEF 25 hat die Doctrine-Entities refactored. Jeder BRIEF baut auf dem vorherigen auf, weil die Statusdatei den aktuellen Stand festhält. Kein „Wo waren wir nochmal?“ — die Antwort steht in einer Datei.

Regeln, die gewachsen sind

In Teil 2 habe ich empfohlen, Regeln zu schreiben. Was ich damals nicht beschrieben habe: Regeln wachsen. Sie entstehen nicht am Anfang eines Projekts, sondern während der Arbeit. Jede Regel in meinem Setup existiert, weil die KI ohne sie einen Fehler gemacht hat — meistens mehr als einmal.

Mein aktuelles Setup hat zehn Regeldateien. Nicht weil ich gerne dokumentiere, sondern weil zehn Kategorien von Fehlern aufgetreten sind. Eine Datei verbietet Debug-Ausgaben im produktiven Code. Eine andere definiert, dass Warnungen behoben werden — nie unterdrückt. Eine dritte regelt, wie Code-Reviews strukturiert ablaufen: mit definierten Prüfkriterien statt nach Bauchgefühl.

.ai/rules/
├── general.md        # PHP, CSS, JS Grundregeln
├── coding.md         # Clean Code, Namenskonventionen
├── security.md       # Escaping, Validierung, keine Secrets
├── architecture.md   # Schichten, Dependency Inversion
├── design.md         # Farben, Typografie, Spacing
├── shopware.md       # Shopware-spezifische Patterns
├── testing.md        # Determinismus, Isolation
├── zero-warnings.md  # 0 Errors, keine Suppression
├── review.md         # Senior-Review-Prozess
└── readme.md         # README-Standard für alle Projekte

Das sieht nach viel aus. Ist es auch. Aber jede einzelne Datei hat ihren Grund. Die zero-warnings.md zum Beispiel existiert, weil die KI bei einem Symfony-Deprecation-Warning vorgeschlagen hat, ihn mit @ zu unterdrücken — statt auf die aktuelle API zu migrieren. Einmal passiert, Regel geschrieben, nie wieder passiert. Regeln sind das Immunsystem deines Projekts. Sie kosten Zeit beim Schreiben, sparen sie beim Arbeiten.

Gedächtnis über Sessions hinweg

Das größte Problem bei KI-gestützter Entwicklung ist nicht die Qualität einzelner Antworten — es ist der Kontextverlust zwischen Sessions. Du arbeitest drei Stunden an einem Feature, schließt das Terminal, öffnest es am nächsten Tag, und die KI hat alles vergessen. Sie kennt dein Projekt nicht mehr, sie weiß nicht was gestern passiert ist, und sie macht die gleichen Fehler wie beim ersten Mal.

Mein Setup löst das auf zwei Ebenen. Erstens: Eine Statusdatei, die den aktuellen Projektstand festhält. Welche BRIEFs sind abgeschlossen, welcher ist aktiv, welche technischen Details gelten. Die KI liest diese Datei am Anfang jeder Session und weiß sofort, wo sie steht. Zweitens: Ein Feedback-Gedächtnis, das Korrekturen und bestätigte Vorgehensweisen speichert. Wenn ich sage „Push sofort nach dem Commit, nicht erst fragen“ — dann merkt sich das System diese Präferenz und wendet sie in der nächsten Session an.

Das klingt trivial, verändert aber die Arbeitsqualität fundamental. Ohne Gedächtnis ist jede Session ein Onboarding. Mit Gedächtnis ist jede Session eine Fortsetzung. Der Unterschied ist wie zwischen einem Freelancer, der jede Woche neu eingearbeitet werden muss, und einem Teamkollegen, der seit Monaten mitarbeitet.

Wissen als Code

Ein Detail, das in keinem KI-Tutorial vorkommt, aber meinen Workflow massiv verändert hat: Konfiguration und Architektur-Entscheidungen liegen als Textdateien in Git — nicht in einem Wiki oder Confluence. Jede Entscheidung ist eine Datei im .ai/-Verzeichnis, versioniert wie Code.

Warum? Weil ich so über alle Projekte gleichzeitig arbeiten kann. Wenn ich ein Pattern etabliere — etwa wie Shopware-Services registriert werden oder wie Symfony-Commands strukturiert sein sollen — kann ich die Regel in allen Projekten per Script ergänzen. Ein Wiki ist dafür nicht gebaut. Git schon.

Der zweite Vorteil: Nachvollziehbarkeit. Jede Änderung an einer Architektur-Entscheidung ist ein Commit mit einer Nachricht. „Shopware-Plugin: Service-Registration auf Autowiring umgestellt“ — das ist keine vage Erinnerung, das ist ein dokumentierter Stand, zu dem ich jederzeit zurückkehren kann.

Qualität ist kein Bonus

In Teil 6 habe ich über Reviews geschrieben. Was ich damals als Empfehlung formuliert habe, ist heute eine Pflicht in meinem Setup. Vor jedem Release wird ein Senior-Developer-Review durchgeführt — ein strukturierter Durchgang durch den gesamten Code mit definierten Prüfkriterien: Wartbarkeit, Sicherheit, Architektur, Lesbarkeit, Fehlerresistenz, Performance, Testabdeckung.

Das klingt aufwendig, ist es auch. Aber die Alternative ist schlimmer: Code, der „irgendwie funktioniert“ und in sechs Monaten zum Problem wird. KI-generierter Code sieht auf den ersten Blick immer gut aus — saubere Syntax, konsistente Formatierung, keine offensichtlichen Fehler. Genau das macht ihn gefährlich. Die echten Probleme stecken nicht in der Syntax, sondern in der Architektur. Ein Review findet sie, bevor sie in Produktion gehen.

Dazu kommt die Zero-Warnings-Regel: Null PHP-Errors, null PHPStan-Findings, null ESLint-Errors. Nicht „so wenig wie möglich“ — null. Keine Unterdrückung, keine Ausnahmen. Wenn ein Warning auftaucht, wird die Ursache behoben. Diese Regel allein hat die Codequalität meiner Projekte stärker verbessert als jede andere Maßnahme.

Der typische Arbeitstag

Wie sieht das konkret aus? Morgens öffne ich das Terminal, starte Claude Code und die KI liest automatisch die Projektbeschreibung, die Statusdatei und die gespeicherten Präferenzen. Innerhalb von Sekunden weiß sie: Shopware 6, PHP 8.3, Symfony 7, 25 BRIEFs abgeschlossen, BRIEF 26 steht an. Ich muss nichts erklären, nichts wiederholen.

Dann nehme ich mir den aktuellen BRIEF vor. Die Anforderungen stehen drin, die Akzeptanzkriterien auch. Ich gebe der KI die Aufgabe, sie implementiert, ich reviewe. Was nicht passt, wird korrigiert — und die Korrektur wandert ins Feedback-Gedächtnis, damit sie beim nächsten Mal nicht wieder passiert. Am Ende wird committed, gepusht, die Statusdatei aktualisiert. Kein Schritt ist optional.

Der entscheidende Punkt: Ich schreibe weniger Code als früher, aber ich treffe mehr Entscheidungen. Welche Architektur, welche Patterns, welche Grenzen. Die KI ist schneller beim Tippen, aber ich bestimme die Richtung. Das Verhältnis hat sich verschoben: weniger Handwerk, mehr Führung. Und das Setup sorgt dafür, dass die Führung nicht in einer Session verloren geht.

Was sich gegenüber den Grundlagen verändert hat

Wenn ich mein heutiges Setup mit dem vergleiche, was in Teil 1 dieser Serie stand, sehe ich drei große Erweiterungen. Erstens: Struktur statt Dokument. Statt einer einzelnen CLAUDE.md gibt es ein ganzes Verzeichnis mit spezialisierten Regeln, Statusdateien und Aufgabendokumenten. Die CLAUDE.md ist immer noch der Einstiegspunkt, aber das echte Wissen steckt tiefer. Zweitens: Gedächtnis statt Kontext. Statt bei jeder Session den gleichen Kontext neu aufzubauen, speichert das System Feedback und Präferenzen persistent. Die KI lernt aus Korrekturen — nicht im Modell, aber im Dateisystem. Drittens: Prozess statt Prompt. Statt einzelner Prompts gibt es einen definierten Workflow: BRIEF lesen, implementieren, testen, reviewen, committen, Status aktualisieren.

Keine dieser Erweiterungen war von Anfang an geplant. Jede ist aus einem konkreten Problem entstanden. Das BRIEF-System, weil freie Prompts bei komplexen Features zu unvorhersehbaren Ergebnissen führten. Das Feedback-Gedächtnis, weil ich die gleiche Korrektur dreimal in verschiedenen Sessions geben musste. Die Zero-Warnings-Regel, weil die KI Warnings lieber unterdrückt als behebt. Gute Setups entstehen nicht am Reißbrett, sondern aus Fehlern.

Die ehrliche Bilanz

Ist das Setup perfekt? Nein. Es gibt Tage, an denen die KI trotz aller Regeln Unsinn generiert. Tage, an denen ein BRIEF zu vage formuliert ist und das Ergebnis an der Realität vorbeigeht. Tage, an denen ich mehr Zeit mit dem Review verbringe als die KI mit dem Schreiben. Das gehört dazu.

Was ich aber sagen kann: Die Fehler wiederholen sich nicht. Jeder Fehler wird zu einer Regel, jede Korrektur zu einem Gedächtniseintrag, jede schlechte Erfahrung zu einem besseren BRIEF. Das System wird mit jedem Projekt besser — nicht weil die KI schlauer wird, sondern weil die Leitplanken enger werden. Und enge Leitplanken sind kein Nachteil. Sie sind der Grund, warum ein Shopware-Plugin nach 25 BRIEFs produktionsreif ist und nicht wie ein Prototyp aussieht.

Die wichtigste Erkenntnis aus acht Monaten KI-gestützter Entwicklung: Das Tool ist nur so gut wie das System, in dem es arbeitet. Ein gutes Modell mit schlechtem Setup produziert mittelmäßigen Code. Ein mittelmäßiges Modell mit gutem Setup produziert soliden Code. Das Setup ist der Multiplikator — nicht das Modell.