Pexon Consulting | 8 Min. Lesezeit | 16.07.2026
TL;DR
Claude Code produziert plausiblen, aber statistisch erzeugten Code, der stillschweigend erfundene API-Parameter oder inkonsistente Konventionen einbaut. Ein Linter ist die deterministische Gegenprobe: Er fängt reproduzierbar, was das Modell übersieht. Pexon (80 Mitarbeitende, Microsoft Partner) verdrahtet Linter als automatische Gates in AI-Engineering-Workflows, damit Tempo nicht auf Kosten der Qualität geht.
Das Problem: LLM-Code ist statistisch, nicht deterministisch
Claude Code ist schnell und meistens erstaunlich gut. Aber das Modell rät die nächste Zeile, es beweist sie nicht. Das ist der Kern: Egal ob claude-sonnet-5 oder ein anderes Modell dahintersteckt, die Ausgabe ist ein Wahrscheinlichkeitsprodukt. Und Wahrscheinlichkeit heißt, dass gelegentlich etwas durchrutscht, das syntaktisch sauber aussieht und semantisch falsch ist.
Die Forschung hat dafür einen Namen. Sogenannte Knowledge Conflicting Hallucinations, subtile Fehler wie ein API-Parameter, den es gar nicht gibt, tauchen regelmäßig in LLM-Code auf. Das Tückische daran: Sie sehen aus wie korrekter Code, kompilieren teilweise sogar, und fallen erst zur Laufzeit auf. Ein Mensch, der 300 Zeilen generierten Code überfliegt, sieht so etwas nicht zuverlässig. Ein Werkzeug, das jede Zeile stur gegen Regeln prüft, schon.
Das ist keine Kritik an Claude Code. Es ist eine Eigenschaft aller generativen Modelle. Und die Antwort darauf ist alt und langweilig und funktioniert: deterministische Guardrails.
Was ein Linter fängt, was das Modell nicht sieht
Statische Analyse ist genau dort am stärksten, wo LLMs schwächeln: bei deterministischen Befunden. Sicherheitslücken, Duplikate, zu hohe Komplexität, Stilverstöße, Policy-Checks. Die Ausgabe ist reproduzierbar, und genau das macht Linter zum richtigen Fundament für Qualitäts- und Compliance-Gates.
Ein konkretes Beispiel aus der Go-Welt: Der Linter unparam findet Funktionsparameter, die immer mit demselben Wert aufgerufen werden. Das ist exakt das Muster, das ein LLM erzeugt, wenn es eine unnötig generische Funktion baut, weil es den Kontext nicht kennt. Dazu gosec für Sicherheit und gocritic für Stil. In Python übernimmt das heute meist ein einziges Werkzeug.
Ruff, der in Rust geschriebene Python-Linter, zeigt, wie weit das geht: Das Release vom 9. Juli 2026 bringt über 900 eingebaute Regeln und läuft 10- bis 100-mal schneller als klassische Tools wie Flake8. Schnell genug, um bei jedem einzelnen Edit zu laufen, ohne dass du es merkst.
Linter als Claude-Code-Hook: das Gate direkt im Loop
Der eigentliche Hebel ist nicht, dass du einen Linter hast. Den hattest du vorher auch. Der Hebel ist, ihn so zu verdrahten, dass er automatisch nach jedem Schreibvorgang von Claude Code läuft, nicht erst in der CI eine Stunde später. Claude Code kann das über Hooks: Ein PostToolUse-Hook feuert, sobald das Modell eine Datei schreibt oder ändert.
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit|Write",
"hooks": [
{
"type": "command",
"command": "ruff check --fix "$CLAUDE_FILE_PATH" || exit 2"
}
]
}
]
}
}Der Trick liegt im Exit-Code. Gibt der Hook einen Fehler zurück, bekommt Claude Code die Linter-Meldung direkt zurückgespielt und korrigiert im selben Loop nach, statt dass der Fehler bis in einen Commit durchsickert. Das Modell repariert seinen eigenen Output, angeleitet von einer deterministischen Instanz.
Wir setzen genau das in unseren Projekten ein, und es funktioniert auch jenseits von reinem Code. In diesem Setup hier läuft zum Beispiel ein Hook, der deutschen Text auf falsche Umlaut-Schreibweisen prüft und den Schreibvorgang blockt, bevor er rausgeht. Dieselbe Mechanik, anderer Regelsatz. Wie du Hooks, Skills und MCP sauber zusammensteckst, haben wir in unserem Beitrag zu Claude-Code-Workflows auseinandergenommen.
Warum das 2026 dringender ist als je zuvor
Der Anteil an maschinell geschriebenem Code ist gekippt. Google berichtete im April 2026, dass 75 Prozent des neuen Codes KI-generiert und von Ingenieuren freigegeben werden. Global liegt der Anteil bei rund 41 Prozent, und in kleinen Startups sind es teils 95 Prozent. Nur: Studien verorten die nachhaltige Grenze bei 25 bis 40 Prozent, bevor die Qualität messbar leidet.
Das ist die eigentliche Rechnung. Wenn ein Mensch 20 Prozent des Codes schreibt und 80 Prozent reviewt, skaliert Handarbeit. Wenn die KI 75 Prozent schreibt, skaliert sie nicht mehr. Du kannst nicht dreimal so viel Code mit demselben Team per Auge prüfen. Meine klare Position: Ab diesem Punkt ist der Verzicht auf automatische Gates keine Stilfrage mehr, sondern fahrlässig. Die Prüfung, die nicht mehr von Hand skaliert, muss an Werkzeuge, die deterministisch skalieren.
Was Linter NICHT fangen (und warum das kein Gegenargument ist)
Damit hier kein falscher Eindruck entsteht: Ein Linter ist kein Wundermittel. Genau die semantischen Halluzinationen von oben, der erfundene API-Parameter, entgehen einem klassischen Linter oft, weil der die fremde Bibliothek nicht kennt. Dafür brauchst du Typen, Tests und moderne AST-basierte Analyse, die den Projektkontext mitliest.
Die richtige Reihenfolge ist ein Netz aus mehreren Schichten, nicht ein einzelnes Tool. Linter für Stil und offensichtliche Fehler, Typprüfer für Signaturen, Tests für Verhalten, und der Mensch für Architektur und die Frage, ob das Ding überhaupt das richtige Problem löst. Der Linter ist die billigste und schnellste Schicht, deshalb steht er ganz vorn. Er ist nicht die einzige. Wer den Linter-Score zum Selbstzweck macht und dann glaubt, fertig zu sein, hat das Prinzip missverstanden.
Ein solches mehrstufiges Qualitätsnetz gehört auf ein tragfähiges Fundament, das nicht an einzelnen Entwicklern hängt. Die Grundlagen dafür legen wir in der AI-Platform-Engineering-Praxis.
Häufig gestellte Fragen
Ersetzt ein Linter das Code-Review durch Menschen bei KI-Code?
Nein, er verlagert es. Der Linter erledigt die mechanischen Prüfungen deterministisch, der Mensch konzentriert sich auf Architektur, Sicherheitslogik und die Frage, ob die Lösung passt. Bei einem KI-Anteil von 75 Prozent ist genau diese Verlagerung der einzige Weg, wie Review überhaupt noch skaliert.
Welche Linter lohnen sich mit Claude Code konkret?
Für Python ist Ruff der Standard, ein Werkzeug ersetzt Flake8, isort und Black. Für Go die Kombination aus golangci-lint mit gosec, gocritic und unparam. Für JavaScript und TypeScript ESLint. Entscheidend ist weniger das Tool als die Verdrahtung als automatischer Hook, der bei jedem Edit läuft.
Was kostet die Einrichtung solcher Guardrails?
Der Linter selbst ist Open Source und kostenlos. Der Aufwand steckt im Regelsatz und der teamweiten Verdrahtung: von einem halben Tag für ein einzelnes Repo bis zu wenigen Wochen für einen einheitlichen Standard über eine ganze Engineering-Organisation samt CI-Gates. Der Return ist eingesparte Review-Zeit und weniger Produktionsfehler.
Kann Claude Code seine eigenen Linter-Fehler korrigieren?
Ja, und das ist der eigentliche Gewinn. Über einen PostToolUse-Hook, der bei einem Verstoß einen Fehler-Exit-Code zurückgibt, bekommt Claude Code die Meldung direkt zurück und bessert im selben Durchlauf nach. Das Modell wird von einer deterministischen Instanz angeleitet, statt frei zu raten.
Fängt ein Linter halluzinierte API-Aufrufe ab?
Nur begrenzt. Erfundene Parameter fremder Bibliotheken entgehen einem reinen Stil-Linter oft. Dafür brauchst du statische Typprüfung, Tests und AST-basierte Analyse mit Projektkontext. Der Linter ist die erste und billigste Schicht, nicht die einzige.
Nächster Schritt
Wenn dein Team gerade den KI-Anteil im Code hochfährt, ist die richtige Reihenfolge: erst die Gates, dann Gas geben. Ein Linter-Hook ist in einer Stunde eingerichtet, ein teamweiter Standard braucht ein sauberes Fundament.
Verwandte Themen
