Du hast ein halbes Sicherheitsnetz gebaut und es als fertig bezeichnet

Seien wir ehrlich: So sehen die meisten KI-Code-Pipelines im Moment tatsächlich aus.

Du generierst Code mit Cursor oder Claude Code. Du führst tsc --noEmit aus, weil der TypeScript-Strict-Mode Typfehler erkennt. Du führst ESLint aus, weil niemand über Semikolons in einem Pull Request streiten will. Vielleicht führst du dependency-cruiser aus, weil zirkuläre Imports peinlich sind. Deine Tests laufen durch. Du lieferst aus.

Und du denkst, das ist ein deterministischer Stack.

Ist es nicht. Es ist ein Typ-und-Style-Stack. Du hast ungültige Zustände verhindert und Import-Grenzen durchgesetzt — das ist durchaus nützlich. Aber du hast genau nichts dagegen unternommen, dass das LLM gerade eine 180-Zeilen-Funktion mit einer zyklomatischen Komplexität generiert hat, bei der selbst ein Graphentheoretiker weinen würde. Du hast nicht bemerkt, dass drei verschiedene Module dieselbe Hilfsfunktion mit leicht unterschiedlichen Variablennamen kopiert haben. Du hast nicht bemerkt, dass das Error Handling ein einziges catch (e) { console.log(e) } ist, das am Ende einer Promise Chain sitzt wie ein fauler Türsteher.

Der Code kompiliert. Die Architektur ist sauber. Der Code ist trotzdem objektiv schrecklich.

Das ist die Lücke. Und das ist wichtig, weil KI-generierter Code ein besonderes Talent dafür hat, genau diese Art von Müll zu produzieren: strukturell gültig, architektonisch konform und still von innen heraus verrottend.

Was die fehlende Schicht tatsächlich ist

Stell dir den Unterschied vor zwischen einem Gebäude, das die Prüfung eines Tragwerksplaners besteht, und einem Gebäude, in dem man gerne wohnt. Die Tragwerksprüfung prüft, ob das Gebäude einstürzt. Sie prüft nicht, ob die Dusche in die Küchenspüle abläuft. Beides ist wichtig. Es sind verschiedene Aufgaben.

Dein bestehender deterministischer Stack ist der Tragwerksplaner. Er prüft:

  • Typen: Kann dieser Wert überhaupt in dieser Form existieren?
  • Linting: Befolgt die Syntax grundlegende Hygiene?
  • Architekturregeln: Respektieren die Imports die Boundaries?
  • Tests: Läuft der Happy Path ohne Absturz durch?

Was er nicht prüft:

  • Komplexität: Hat diese Funktion so viele Verzweigungen, dass kein Mensch sie jemals korrekt durchdenken kann?
  • Duplikation: Hat das LLM dieselbe Logik an vier Stellen mit kleinen Variationen generiert?
  • Naming: Ist data ein aussagekräftiger Variablenname, oder ist es das Programmier-Äquivalent zu einem Schulterzucken?
  • Error Handling: Werden Fehler tatsächlich behandelt, oder nur abgefangen und ignoriert?
  • Struktur: Ist die Dateiorganisation sinnvoll, oder ist sie ein Sammelbecken?
  • Kommentare: Sind die kniffligen Stellen erklärt, oder braucht der nächste Entwickler eine Séance?
  • Größe: Hat diese Datei 400 Zeilen, weil sie so viele braucht, oder weil niemand dem Modell gesagt hat, dass es aufhören soll?

Das sind keine ästhetischen Vorlieben. Komplexität korreliert mit der Fehlerdichte. Duplikation garantiert, dass zukünftige Änderungen inkonsistent sein werden. Schlechtes Naming erhöht die kognitive Belastung bei jeder nachfolgenden Änderung. Schlechtes Error Handling bedeutet Produktionsausfälle ohne diagnostische Spur.

Die Forschung ist hier eindeutig. Unsere eigene Analyse über mehrere Dimensionen hinweg hat ergeben, dass geschichtete Zuverlässigkeitsarchitekturen nur dann funktionieren, wenn jede Schicht Fehler erkennt, die die vorherigen Schichten übersehen haben. Wenn dein Layer 1 Type Checking ist und dein Layer 2 Tests, aber niemand prüft, ob der Code eine Wartungskatastrophe ist, hast du ein Loch in deinem Stack. Und KI-generierter Code liebt es, durch dieses Loch zu fallen, weil Modelle sehr gut darin sind, plausibel aussehende Implementierungen zu generieren, die sich zufällig als Albträume erweisen, mit denen man leben muss.

Das Tool mit dem unanständigen Namen

Es gibt ein Tool namens fuck-u-code — ja, wirklich, das ist der Befehl — und es macht genau eine Sache, die nichts anderes in deiner Pipeline tut. Es führt eine deterministische, AST-basierte Code-Quality-Analyse über vierzehn Sprachen hinweg durch und sagt dir genau, wie schlecht dein Code ist — mit Metriken, die tatsächlich mit echten Problemen korrelieren.

Das prüft es:

  • Komplexität: Zyklomatische und kognitive Komplexitätswerte. Wenn eine Funktion siebzehn Verzweigungen hat, markiert es sie.
  • Größe: Zeilenanzahl von Dateien und Funktionen. Das LLM, das eine 250-Zeilen-Funktion generiert hat, bekommt keinen Freifahrtschein, nur weil die Typen stimmen.
  • Kommentare: Kommentardichte und -qualität. Nicht weil Kommentare tugendhaft wären, sondern weil komplexe Logik ohne Erklärung eine Wartungsfalle ist.
  • Error Handling: Ob Fehler abgefangen, weiter geworfen, geloggt oder still verschluckt werden.
  • Naming: Qualität von Variablen- und Funktionsnamen. data, temp, handler und process bestehen nicht.
  • Duplikation: Wiederholte Code-Blöcke über Dateien hinweg. Der Lieblingstrick des LLMs: Copy-Paste mit Find-and-Replace.
  • Struktur: Dateiorganisation und Modulkohäsion.

Es gibt einen Gesamtwert von 0 bis 100 aus. Höher ist besser. Es gibt auch einen pro-Datei-„Shit-Gas-Index“ aus — höher ist schlechter — sodass du genau weißt, welche Dateien zuerst Aufmerksamkeit brauchen. Die Analyse läuft vollständig offline über tree-sitter AST Parsing. Dein Code verlässt niemals deine Maschine. Bei den meisten Projekten dauert sie weniger als eine Sekunde.

Und hier ist der Teil, der dich wütend machen sollte, dass du es nicht schon längst benutzt: Es kostet null Dollar.

Das Tool verkörpert die Philosophie

Was fuck-u-code interessant macht, ist nicht nur, was es prüft. Es ist, wie es intern architektonisch aufgebaut ist, denn das Tool selbst ist ein perfekter Mikrokosmos der Pipeline, zu der es gehört.

Das Tool hat zwei Befehle:

fuck-u-code analyze .          # Deterministic AST analysis. Offline. Fast. Free.
fuck-u-code ai-review . -m gpt-4o   # AI review of the worst-scoring files. API call. Costs tokens.

Beachte die Reihenfolge. Beachte den Standard. Die deterministische Analyse läuft immer zuerst, weil sie keinen API Key erfordert, kein Geld kostet und nicht zwischen verschiedenen Durchläufen variiert. Die AI Review ist ein optionaler zweiter Schritt, der nur die Top-N schlechtesten Dateien betrachtet.

Das ist genau die Architektur, die deine Pipeline haben sollte.

Du schickst nicht jeden Pull Request zu Greptile oder Claude Code für ein vollständiges semantisches Review. Das kostet Geld, dauert lange und — wie wir in vorherigen Posts festgestellt haben — produziert es probabilistischen Output, der bei aufeinanderfolgenden Durchläufen dieselben Probleme vielleicht erkennt und vielleicht auch nicht. Du lässt zuerst das deterministische Gate laufen. Du filterst die strukturellen Desaster kostenlos heraus, in Millisekunden, mit perfekter Reproduzierbarkeit. Dann, und nur dann, schickst du die Überlebenden zu einem teuren AI Review für die semantische, architektonische und verhaltensbezogene Analyse, die deterministische Tools nicht leisten können.

fuck-u-code implementiert das buchstäblich intern. Der analyze-Befehl ist dein Layer-1-Quality-Filter. Der ai-review-Befehl ist dein Layer-2-Semantic-Deep-Dive. Das Tool ist eine Demonstration des Prinzips, das es ermöglicht.

Das wirtschaftliche Argument ist fast beleidigend

Lass uns kurz über Geld reden, denn hier wird der aktuelle Zustand der Branche wirklich ärgerlich.

KI-Code-Review-Plattformen berechnen Gebühren pro Pull Request oder pro überprüfter Codezeile. Die Kosten sind nicht riesig — vielleicht ein oder zwei Dollar pro PR — aber sie sind nicht null, und sie skalieren mit der Velocity deines Teams. Wenn du Code mit KI generierst, ist deine Velocity höher als früher, was bedeutet, dass deine Review-Kosten auch höher sind als früher.

In der Zwischenzeit analysiert fuck-u-code deinen gesamten Codebase über vierzehn Sprachen hinweg in weniger als einer Sekunde und berechnet dir genau nichts. Es markiert die 20 % der Dateien, die wirklich problematisch sind. Es erzeugt einen JSON- oder Markdown-Report, den dein CI verarbeiten kann. Es lässt den Build fehlschlagen, wenn der Durchschnittswert unter einen von dir konfigurierten Schwellenwert fällt.

Wenn du bei jedem PR ein AI Review laufen lässt, ohne vorher ein deterministisches Quality Gate, bezahlst du API-Tokens, um herauszufinden, dass eine Funktion zu komplex ist. Das ist so, als würdest du einen Tragwerksplaner engagieren, um dir zu sagen, dass dein Haus schmutzig ist. Der Ingenieur ist für den Job qualifiziert, aber du verschwendest seine Zeit und dein Geld.

Die ökonomisch rationale Pipeline ist:

  1. KI generiert Code
  2. Type Checking, Linting und Architekturregeln (dein bestehender Stack)
  3. fuck-u-code analyze (das fehlende Quality Gate — 0 $, <1 s)
  4. AI Review (Greptile etc. — aber nur bei Dateien, die Schritt 3 überlebt haben, oder nur wenn Schritt 3 interessante Patterns markiert)

Das ist keine Theorie. Das ist Arithmetik. Das deterministische Gate erkennt die Klasse von Problemen, für die deterministische Tools konzipiert sind. Das AI Review erkennt die Klasse von Problemen, die semantisches Verständnis erfordern. Jedes Tool macht das, worin es gut ist. Niemand verschwendet Tokens für strukturelle Hygiene.

MCP-Integration: Für den Workflow gebaut, nicht nachträglich angepasst

Es gibt noch ein Detail, das wichtig ist, wenn du es mit KI-gestützter Entwicklung ernst meinst.

fuck-u-code liefert einen MCP Server. Wenn du Claude Code, Cursor oder ein anderes MCP-fähiges Tool benutzt, kannst du fuck-u-code analyze direkt von deinem Agent aus aufrufen. Der Agent muss nichts über AST Parsing oder zyklomatische Komplexität wissen. Er ruft ein Tool auf. Das Tool gibt einen strukturierten Report zurück. Der Agent handelt danach.

Das ist wichtig, weil es den Kreis schließt. Dieselbe KI, die den Code generiert hat, kann jetzt deterministisches Feedback über die Qualität dieses Codes erhalten — in einem Format, das sie verstehen und danach handeln kann. Der Agent kann sehen, dass der Shit-Gas-Index für src/auth/login.ts 87 von 100 ist und sich entscheiden zu refactoren, bevor ein Mensch den PR je zu Gesicht bekommt.

Wir haben schon früher darüber geschrieben, dass CI die Enforcement Layer ist, die specification-driven development real macht. Die MCP-Integration bedeutet, dass fuck-u-code nicht nur ein CI-Gate ist. Es ist ein agent-zugängliches Quality Oracle, das die Generation Pipeline in Echtzeit konsultieren kann.

Wie die Integration tatsächlich aussieht

Du brauchst keinen Migrationsplan. Du brauchst fünf Minuten.

npm install -g eff-u-code
fuck-u-code analyze .              # See your current scores
fuck-u-code config init            # Generate .fuckucoderc.json

Konfiguriere deine Schwellenwerte. Wähle einen minimalen Gesamtwert. Wähle einen maximalen Shit-Gas-Index für jede einzelne Datei. Füge es zu deinen Pre-Commit-Hooks hinzu:

# .husky/pre-commit
fuck-u-code analyze . --format json --output quality-report.json

Oder füge es zu deinem CI hinzu:

# .github/workflows/quality.yml
- name: Code Quality Gate
  run: |
    npm install -g eff-u-code
    fuck-u-code analyze . --format markdown -o quality.md
    # Parse the JSON and fail if overall score < threshold

Die Gewichtungen sind konfigurierbar. Wenn dein Team mehr über Komplexität als über Kommentare besorgt ist, passe die Metrik-Gewichtungen in .fuckucoderc.json an. Wenn du Testdateien ausschließen willst, benutze --exclude. Wenn du die Top 20 schlechtesten Dateien statt der Standard-10 sehen willst, benutze -t 20.

Dann, wenn du die strukturellen Desaster herausgefiltert hast, schicke die interessanten Dateien zum AI Review:

fuck-u-code ai-review . -m gpt-4o -t 5   # Review only the 5 worst files

Das ist die Pipeline. Generieren. Type Check. Quality Gate. AI Review der Überlebenden. Ausliefern.

Das ehrliche Fazit

Ich werde nicht so tun, als ob fuck-u-code jedes Problem in deinem Codebase lösen würde. Es wird keinen Race Condition erkennen. Es wird dir nicht sagen, dass deine Authentifizierungslogik einen subtilen Timing-Angriff hat. Es wird property-based testing, mutation testing oder formale Verifikation oder eine der anderen Schichten, über die wir in vorherigen Posts gesprochen haben, nicht ersetzen.

Was es tun wird, ist die langweiligen, vorhersehbaren, teuren Probleme zu erkennen, die momentan niemand erkennt. Es wird dir sagen, dass dein KI-generierter API-Handler 300 Zeilen lang ist und kein Error Handling hat. Es wird dir sagen, dass drei verschiedene Services dieselbe Validierungslogik kopiert haben. Es wird dir sagen, dass die Hälfte deiner Variablen data oder result heißt und du dich deswegen schlecht fühlen solltest.

Das sind keine Edge Cases. Das sind die Standard-Outputs einer schnellen Code-Generation-Pipeline ohne Quality-Feedback-Loop. Das LLM wird nicht müde, aber es wird auch nicht verlegen. Es wird schlechten Code mit derselben Zuversicht generieren wie guten Code, und dein aktueller deterministischer Stack wird ihn durchlassen, weil dein Stack nicht dafür konzipiert wurde, Qualität zu prüfen. Er war dafür konzipiert, Gültigkeit zu prüfen.

Gültigkeit und Qualität sind verschiedene Dinge. Du brauchst beides.

fuck-u-code ist nicht die ganze Antwort. Es ist die Antwort auf die spezifische Frage: „Was ist der billigste, schnellste, deterministischste Weg, KI-generierten strukturellen Müll davon abzuhalten, das Code Review zu erreichen?“

Die Antwort lautet: Parse den AST, bewerte die Metriken, lass den Build fehlschlagen und bring das Modell dazu, es noch einmal zu versuchen.

Es kostet nichts. Es dauert weniger als eine Sekunde. Und es schließt ein Loch in deinem Sicherheitsstack, von dem du wahrscheinlich nicht wusstest, dass du es hattest.