SQL-Konventionen mit Claude Code ableiten — der Generate-Refine-Derive-Loop

Veröffentlicht 12.06.2026
von

Eine KI schreibt dir eine Stored Procedure in Sekunden. Sie kompiliert, sie läuft – und sie sieht aus, als hätte sie ein Fremder geschrieben. Beim nächsten Artefakt sieht sie wieder anders aus. Generierter SQL-Code ist technisch korrekt, aber stilistisch beliebig – und ohne durchgesetzte Konvention driftet eine generierte Sammlung genauso auseinander wie eine, an der fünf Entwickler von Hand schreiben. Die naheliegende Antwort – jedes Artefakt manuell nachformatieren – skaliert nicht.

Dieser Artikel zeigt den Ausweg als wiederholbaren Arbeitsablauf: den Generate→Refine→Derive-Loop. Statt die KI bei jedem Artefakt neu zu korrigieren, korrigierst du einmal von Hand, lässt Claude Code die Differenz zwischen seinem Output und deiner Handfassung analysieren und daraus eine explizite Regel ableiten. Diese Regel lebt ab dann in einer .claude/rules/-Datei und greift beim nächsten Generieren automatisch. So lassen sich SQL-Konventionen ableiten statt mühsam pro Datei durchsetzen – aus einer einmaligen Korrektur wird eine dauerhafte Konvention.

Das nimmst du mit:

  • den Loop in sechs Schritten – Generate, Refine, Derive, Codify, Enforce, Wiederholen – und wo jeweils der Mensch und wo die KI arbeitet;
  • wie du Claude Code die Differenz zwischen generiertem und handkorrigiertem Code analysieren und daraus wiederverwendbare Regeln formulieren lässt;
  • wann du der KI etwas gezielt vorgeben musst, das sie aus keinem einzelnen Diff zuverlässig erraten kann – am Beispiel der Parameter-Reihenfolge in einer Prozedur-Signatur;
  • warum der manuelle Refine-Schritt nicht nur die Regel liefert, sondern dich zu dem genauen Lesen zwingt, das fachliche Fehler aufdeckt.

Voraussetzung: Claude Code (oder ein vergleichbarer KI-Coding-Agent mit Projekt-Regeldateien), Grundkenntnisse PL/pgSQL. Den Überblick über die drei Hebel – Rules, Skills, Agenten – liefert der Hub-Artikel KI-gestützte SQL-Entwicklung mit Claude Code; dieser Beitrag vertieft den Entstehungs-Workflow hinter den Regeln.

Inhalt

Das Problem: generierter SQL-Code ohne Konvention

Ein KI-Agent erzeugt funktionierenden Code – aber nicht deinen Code. Er benennt eine Prozedur update_project, wo dein Hausstil sp_upd_project verlangt; er rückt einen JOIN anders ein als der vorige; er baut den Fehlertext direkt ins RAISE, wo deine Konvention ihn in eine Variable legt. Jedes Artefakt für sich ist lesbar – im Maßstab wird die Stil-Vielfalt zum Such- und Review-Problem: 50 generierte Prozeduren in fünf Stilen sind so schwer zu durchsuchen wie 50 handgeschriebene in fünf Stilen.

Es gibt drei mögliche Reaktionen darauf, und nur eine nimmt dir die Wiederhol-Arbeit dauerhaft ab:

  1. Hinnehmen. Der Code wird inkonsistent, Review und grep leiden. Genau das, was Konventionen verhindern sollen.
  2. Jedes Artefakt manuell nachformatieren. Funktioniert, kostet aber bei jedem Artefakt dieselbe Handarbeit. Die KI hat dir nichts abgenommen, nur die Reihenfolge verschoben.
  3. Die Konvention einmal ableiten und der KI als Regel geben. Du korrigierst ein Artefakt von Hand, leitest daraus die Regel ab und legst sie in eine .claude/rules/-Datei. Ab dann generiert der Agent konvention-konform – die Handarbeit fällt genau einmal an.

Der dritte Weg ist der Generate→Refine→Derive-Loop. Er verlagert die Konvention von „menschlicher Disziplin bei jedem Artefakt“ zu „Default beim Generieren“ – und am Entstehungs-Punkt des Codes ist sie am billigsten durchzusetzen. Dabei ist der Loop nicht die einzige Quelle von Konventionen: Coding-Standards, Architektur-Vorgaben und Review-Kommentare sind weitere. Er deckt speziell die impliziten Regeln ab, die erst sichtbar werden, wenn du ein generiertes Artefakt von Hand in Form bringst.

Der Loop in sechs Schritten

Der Ablauf ist immer derselbe, egal ob es um eine Tabelle, eine Funktion oder eine Prozedur geht:

  1. Generate – die KI erzeugt das SQL-Artefakt aus deiner Anforderung.
  2. Refine – du korrigierst es von Hand in den Zustand, den du eigentlich willst (Naming, Alignment, Reihenfolge, Fehler-Handling).
  3. Derive – du lässt Claude Code seinen ursprünglichen Output mit deiner Handfassung vergleichen und daraus die Regel(n) ableiten – je Regel mit einer Begründung.
  4. Codify – die abgeleitete Regel wandert in die passende .claude/rules/<typ>.md-Datei (z. B. procedures.md für Prozeduren).
  5. Enforce – beim nächsten Artefakt lädt der Agent die Regel automatisch als Projekt-Instruktion und generiert regelkonform.
  6. Wiederholen – jeder neue Sonderfall, den du von Hand korrigierst, schärft das Regelwerk um eine weitere Regel.

Der entscheidende Schritt ist Derive: Statt die Regel selbst zu formulieren, lässt du sie die KI aus deinem eigenen Edit extrahieren. Das ist schneller, und es zwingt zu Präzision – eine Regel, die sich aus einem konkreten Vorher/Nachher ableiten lässt, ist automatisch mit einem Beispiel belegt.

Der Loop an einem Beispiel

Nimm eine simple Prozedur: Sie soll den Namen eines Projekts aktualisieren. Die Anforderung an die KI lautet schlicht „schreib mir eine Prozedur, die den Projektnamen ändert“.

1. Generate — der KI-Output

  1: create or replace procedure update_project(p_name varchar, p_id bigint)
  2: language plpgsql as $$
  3: begin
  4:   update project set name = p_name, modified_on = now() where id = p_id;
  5: end; $$;

Das läuft. Aber es ist nicht dein Stil: Kleinschreibung, kein Typ-Präfix im Namen, kein Alignment, die Parameter in der Reihenfolge „erst das Attribut, dann der Identifier“, alles in einer Zeile.

2. Refine — deine Handfassung

Du korrigierst es so, wie du es haben willst:

  1: CREATE OR REPLACE PROCEDURE app.sp_upd_project
  2: (
  3:     IN p_id     bigint
  4:    ,IN p_name   varchar
  5: )
  6: LANGUAGE plpgsql
  7: AS $procedure$
  8: BEGIN
  9:    UPDATE app.project T01
 10:    SET
 11:        name        = p_name
 12:       ,modified_on = now()
 13:    WHERE
 14:       T01.id = p_id;
 15: END;
 16: $procedure$;

Sechs Dinge haben sich geändert: Großschreibung der Schlüsselwörter, Präfix + Verb-Code im Namen (sp_upd_), schema-qualifizierter Name, tabellarisch ausgerichtete Signatur mit Leading-Komma, ein positioneller Alias T01 – und die Parameter-Reihenfolge ist umgedreht: der Identifier p_id steht jetzt vorn.

3. Derive — Claude leitet die Regeln ab

Statt diese sechs Punkte selbst als Regeln auszuformulieren, gibst du Claude Code den Auftrag:

„Vergleiche die Prozedur, die du erzeugt hast, mit meiner überarbeiteten Fassung. Liste die Unterschiede auf und formuliere daraus wiederverwendbare Regeln für künftige Prozeduren – je Regel mit einer kurzen Begründung.“

Den Großteil liest der Agent zuverlässig aus dem Diff: Schlüsselwörter groß, sp_<verb>_<entity> als Name, Schema qualifizieren, Signatur tabellarisch mit Leading-Komma, positionelle Aliase. Das sind mechanische, im Vorher/Nachher sichtbare Muster.

4. Codify — die Regel wird Teil des Regelwerks

Die abgeleiteten Regeln wandern in .claude/rules/procedures.md. So sieht der Eintrag zur Parameter-Reihenfolge dort als echte Datei aus:

## Parameter-Reihenfolge (Identifier zuerst)

**Regel:** Der Identifier-Parameter (p_id) steht immer an erster Stelle
der Signatur - vor den Attribut-Parametern.

**Begründung:** WHERE id = p_id identifiziert die Zeile zuerst, danach
werden ihre Attribute gelesen oder gesetzt. Gilt auch für INSERT, wo id
als INOUT zurückgegeben wird - "Identifier zuerst" hat Vorrang vor
"Eingaben vor Ausgaben".

**Do:**    sp_upd_project(IN p_id bigint, IN p_name varchar)
**Don't:** update_project(p_name, p_id)

Das Tripel Regel → Begründung → Do/Don’t ist kein Zufall: Die Begründungs-Zeile sagt dem Agenten das Warum, sodass er die Regel auch auf Fälle überträgt, die das Beispiel nicht wörtlich zeigt. Und die Begründung trägt hier schon den Sonderfall (INSERT mit INOUT) in sich – genau den Teil, den der Agent gleich brauchen wird.

5. Enforce — der nächste Wurf sitzt

Bittest du den Agenten in der nächsten Session um eine Insert-Prozedur fürs selbe Projekt, kommt der Identifier von allein nach vorn – obwohl er hier als INOUT zurückgegeben wird:

  1: CREATE OR REPLACE PROCEDURE app.sp_ins_project
  2: (
  3:     INOUT p_id     bigint
  4:    ,IN    p_name   varchar
  5: )

Hier allerdings reicht der Diff allein nicht mehr.

Wann du der KI etwas vorgeben musst

Im Refine-Schritt oben hat der Agent „Identifier zuerst“ aus einem Beispiel abgeleitet. Aber aus einem einzigen Vorher/Nachher ist nicht erkennbar, warum der Identifier vorn steht – es könnte Zufall sein, alphabetische Sortierung, oder eine Eigenheit genau dieses Update-Falls. Der INSERT-Fall macht das greifbar: Dort ist p_id ein Ausgabe-Parameter (INOUT, der neu vergebene Schlüssel wird zurückgegeben). Die übliche Faustregel „Eingaben vor Ausgaben“ würde ihn ans Ende stellen. Die Hausregel sagt das Gegenteil: „Identifier zuerst“ hat Vorrang vor „Eingaben vor Ausgaben“.

Diese Entscheidung kann die KI aus dem einen Update-Diff nicht zuverlässig ableiten – im Artefakt ist sie schlicht nicht sichtbar. Ein Modell kann durchaus eine Hypothese bilden („vielleicht Identifier zuerst?“), aber eine geratene Hypothese ist keine verlässliche Regel. Hier brauchst du gezielten manuellen Input: Du gibst dem Agenten die Regel samt Begründung und Sonderfall explizit vor, statt zu hoffen, dass er sie errät.

Das ist der allgemeine Punkt hinter dem konkreten Beispiel: Manche Konventionen sind Design-Entscheidungen, deren Begründung nicht im Code steht. Ein Diff zeigt das Was, aber nicht immer das Warum – und ohne das Warum kann der Agent nicht generalisieren. Typische Kandidaten für solchen gezielten Input:

  • Reihenfolgen, die einer Logik folgen (Identifier vor Attributen, Prüfungen vor Mutationen) – die Logik muss benannt werden, sonst wirkt die Reihenfolge beliebig.
  • Bewusste Abweichungen von einer gängigen Faustregel (hier: „Identifier zuerst“ schlägt „Eingaben vor Ausgaben“) – der Agent kennt die gängige Regel und würde sie sonst anwenden.
  • Namensgebung mit fachlichem Hintergrund (eine Tabelle heißt account statt user, weil USER ein reserviertes Keyword ist) – das ist aus dem Namen allein nicht herzuleiten.

Die Parameter-Reihenfolge ist dabei bewusst ein kleines Beispiel – gerade weil sich „das Warum steht nicht im Diff“ an einem simplen Fall am klarsten zeigt. Bei gewichtigeren Konventionen – Fehlerbehandlung, Mandantenfilter, Audit-Spalten, Transaktionsgrenzen – greift dasselbe Muster, nur mit höherem Einsatz.

Und damit zur Grenze des Verfahrens: Der Diff-Loop ist nicht die Quelle aller Regeln. Architektur-Entscheidungen, Security- und Performance-Anforderungen oder fachliche Geschäftsregeln entstehen aus Anforderungen, Architektur und Review – nicht aus einem Format-Diff. Der Loop deckt die impliziten Stil- und Struktur-Konventionen ab, die beim Hand-Korrigieren auftauchen. Und nicht jede Korrektur verdient eine Regel: Wer jeden Einzelfall codifiziert, erzeugt Regelwildwuchs und Widersprüche – codifiziere nur, was wiederkehrt.

Warum der manuelle Schritt sich lohnt

Man könnte einwenden: Wenn am Ende ohnehin eine Regeldatei den Stil erzwingt – warum dann noch von Hand korrigieren, statt der KI gleich alle Regeln vorzusetzen und den Refine-Schritt zu überspringen?

Weil der manuelle Refine-Schritt eine Gelegenheit schafft: das Artefakt wirklich zu lesen. Wohlgemerkt nicht das Umformatieren selbst – UPDATE project zu UPDATE app.project T01 zu machen, lehrt dich nichts über die Fachlichkeit. Es ist das genaue Lesen, zu dem der Refine-Schritt zwingt, bei dem dir auffällt, dass die Permission-Prüfung hinter der Mutation steht, dass ein JOIN zu viele Zeilen liefert, dass ein Parameter fehlt. Ein Agent, dem du blind ein fertiges Regelwerk vorsetzt, generiert hübschen Code – aber dieses prüfende Lesen hast du dann übersprungen. Generierter Code ohne Verständnis ist das eigentliche Risiko: technisch korrektes SQL, das die fachliche Frage trotzdem nicht beantwortet.

Das ist dieselbe Einsicht wie beim manuellen Formatieren von SQL – Formatieren ist Verstehen. Der Loop macht sie nur produktiv: Das genaue Lesen passiert beim Refine, und das Nebenprodukt – die abgeleitete Regel – sorgt dafür, dass du dieselbe Korrektur nicht ein zweites Mal von Hand machen musst. Du liest einmal genau hin, der Agent wiederholt das Ergebnis sehr zuverlässig – solange die Regel in seinem Kontext liegt und nicht mit einer anderen kollidiert.

Zum Mitnehmen: Den Generate→Refine→Derive-Loop gibt es als kompakte Checkliste zum Download – inklusive eines generalisierten Starter-Auszugs für deine erste .claude/rules/-Datei. Leg sie in dein Repo, und der nächste generierte SQL-Code entsteht schon im Hausstil.

Zusammenfassung

KI-Agenten erzeugen funktionierenden, aber stilistisch beliebigen SQL-Code. Ihn bei jedem Artefakt manuell nachzuformatieren skaliert nicht; die Konvention einmal abzuleiten und der KI als Regel zu geben schon. Genau das leistet der Generate→Refine→Derive-Loop für die impliziten Konventionen, die beim Hand-Korrigieren auftauchen.

Take-Away:

  • Der Loop: Generate (KI) → Refine (Mensch korrigiert) → Derive (KI leitet die Regel aus dem Diff ab) → Codify (Regel in .claude/rules/) → Enforce (Agent generiert regelkonform) → Wiederholen.
  • Derive statt selbst formulieren: Lass Claude Code die Differenz zwischen seinem Output und deiner Handfassung analysieren – die abgeleitete Regel ist automatisch mit einem Beispiel belegt.
  • Das Tripel Regel → Begründung → Do/Don’t macht eine Regel für einen Agenten brauchbar; die Begründungs-Zeile ist die Brücke, über die er auf neue Fälle generalisiert.
  • Gezielter manueller Input ist dort nötig, wo eine Regel ein Warum hat, das nicht im Artefakt sichtbar ist – etwa die Parameter-Reihenfolge „Identifier zuerst“, die selbst beim INSERT mit INOUT-Rückgabe Vorrang vor „Eingaben vor Ausgaben“ hat.
  • Der Refine-Schritt erzwingt genaues Lesen, nicht nur Layout – genau die Prüfung, die generierter Code sonst überspringt.
  • Grenze: Nicht alles kommt aus Diffs (Architektur, Security, Fachregeln), und nicht jede Korrektur verdient eine Regel – sonst Regelwildwuchs.

FAQ

Brauche ich Claude Code, oder geht der Loop mit jedem LLM?

Das Prinzip – generieren, von Hand korrigieren, die Differenz in eine Regel überführen – funktioniert mit jedem fähigen Coding-Assistenten. Den vollen Nutzen bringt der Loop aber erst mit einem Agenten, der projektweite Regeldateien automatisch lädt (bei Claude Code die .claude/rules/-Dateien als Projekt-Instruktion). Ohne diesen Mechanismus müsstest du die abgeleiteten Regeln bei jedem Prompt erneut mitgeben – der „Enforce“-Schritt fiele weg.

Wie verhindere ich, dass die KI die Regel beim nächsten Mal trotzdem ignoriert?

Drei Stellschrauben. Erstens ein Do/Don’t-Beispiel statt reiner Prosa – der Agent imitiert sichtbaren Code zuverlässiger als eine abstrakte Anweisung. Zweitens die Begründungs-Zeile, damit er die Regel auch auf nicht wörtlich beschriebene Fälle überträgt. Drittens: Weicht ein Artefakt trotzdem ab, ist genau das der nächste Loop-Durchlauf – korrigieren, Differenz ableiten, Regel schärfen. Eine Regel, die mehrfach gerissen wird, ist meist zu unspezifisch formuliert. (LLMs verlieren Regeln nicht selten unter Kontextdruck oder bei Konflikten – der Loop ist deshalb ein laufender Prozess, kein einmaliges Setup.)

Was, wenn zwei Regeln sich widersprechen?

Dann braucht das Regelwerk eine Vorrang-Aussage – genau wie im Parameter-Beispiel: „Identifier zuerst“ schlägt „Eingaben vor Ausgaben“. Solche Konflikte sind kein Defekt, sondern ein Signal, dass eine Design-Entscheidung explizit gemacht werden muss. Schreib die Priorität in die Regeldatei, statt dich auf die Reihenfolge der Regeln zu verlassen.

Lohnt sich der Loop für Solo-Entwickler, oder nur im Team?

Gerade solo. Der „andere Entwickler“, dessen Stil von deinem abweicht, ist beim KI-Coding der Agent selbst. Eine abgeleitete Regeldatei macht aus diesem unzuverlässigen Mit-Autor einen, der deinen Stil meist trifft. Im Team kommt eine Frage dazu: welche Korrektur zur offiziellen Regel wird, ist dann eine Team-Entscheidung (Review, Konvention) – der Mechanismus bleibt derselbe.

Ist das nicht nur Formatierung – warum so viel Aufwand für Stil?

Der Loop adressiert Stil und Verständnis. Der Stil-Teil macht generierten Code überhaupt erst review-fähig. Das Verständnis entsteht aber nicht durch das Umformatieren selbst, sondern durch das genaue Lesen, zu dem der Refine-Schritt zwingt – dabei fällt auf, wenn die Logik nicht stimmt, nicht nur das Layout. Ein Auto-Formatter würde den Stil erzeugen, aber den fachlichen Fehler mit-formatieren.

Verwandte Artikel

KI-gestützte Entwicklung:

Konventions-Spokes:

SQL-Struktur & Formatierung: