KI-gestützte SQL-Entwicklung mit Claude Code — Rules, Skills und Agenten, die Konventionen durchsetzen

Eine Stored Procedure, ein Migrations-Skript, eine komplexe Auswertung – Claude Code schreibt sie in Sekunden. Das ist der einfache Teil. Der schwere Teil beginnt danach: Generierter SQL-Code, der niemandem gehört, driftet genauso auseinander wie handgeschriebener – nur schneller, weil die KI auf Zuruf Hunderte Zeilen produziert. KI-gestützte SQL-Entwicklung ist erst dann ein Gewinn, wenn der generierte Code denselben Konventionen folgt wie der von Hand geschriebene – und wenn ein Mensch noch versteht, was da entstanden ist.

Dieser Artikel ist der Einstieg in eine Reihe darüber, wie KI-gestützte SQL-Entwicklung mit Claude Code in der Praxis funktioniert – nicht als Autovervollständigung, sondern als drei konkrete Hebel: Rules-Dateien, die Konventionen erzwingen, Skills für wiederkehrende Aufgaben und Agenten für mehrstufige Daten-Workflows. Der rote Faden bleibt dabei die Daten-Arbeit: SQL Server, Postgres, ETL – nicht KI um ihrer selbst willen.

Das nimmst du mit:

warum gerade SQL- und ETL-Arbeit von maschinell durchgesetzten Konventionen profitiert;
die drei Hebel von Claude Code – Rules, Skills, Agenten – und wofür jeder taugt;
wie eine .claude/rules/-Datei aus einem Style-Guide eine Default-Einstellung beim Generieren macht;
warum generierter Code Konventionen und menschliches Verständnis braucht – und nicht das eine ohne das andere.

Voraussetzung: Grundverständnis von SQL/ETL. Claude Code (der KI-Coding-Agent von Anthropic) wird hier eingeführt, nicht vorausgesetzt.

Inhalt

Warum KI-Coding gerade bei SQL-Arbeit?
Die drei Hebel: Rules, Skills, Agenten
Rules-Dateien: Konventionen, die der Agent durchsetzt
Skills und Slash-Commands: wiederkehrende SQL-Aufgaben
Agenten: mehrstufige Daten-Workflows
Der rote Faden: generierter Code braucht Verstehen
FAQ
Verwandte Artikel

Warum KI-Coding gerade bei SQL-Arbeit?

SQL- und ETL-Arbeit ist voller wiederkehrender Muster: dieselbe Namenskonvention über Hunderte Objekte, derselbe Prozeduren-Aufbau, dieselben Protokoll-Inserts in jedem Lade-Schritt, dieselbe Formatierung über jedes Statement. Genau solche Muster sind das ideale Terrain für maschinelle Durchsetzung – sie sind regelhaft genug, dass eine KI sie zuverlässig reproduzieren kann, und zahlreich genug, dass menschliche Disziplin allein irgendwann ermüdet.

Gleichzeitig lässt SQL fehlendes Verständnis stillschweigend durch: Ein Statement kann syntaktisch korrekt sein, performant laufen und trotzdem die falsche Frage beantworten. Eine KI, die SQL generiert, verschärft beide Seiten – sie produziert Muster schneller, aber sie produziert auch falsche Antworten schneller. KI-gestützte SQL-Entwicklung lohnt sich deshalb nur mit zwei Leitplanken: durchgesetzte Konventionen, damit der generierte Code lesbar und prüfbar bleibt, und ein Mensch, der die fachliche Frage versteht.

Die drei Hebel: Rules, Skills, Agenten

Claude Code bietet drei Mechanismen, die über reine Autovervollständigung hinausgehen – jeder löst ein anderes Problem:

Rules-Dateien (.claude/rules/) – Konventionen durchsetzen. Projekt-Instruktionen, die der Agent bei jeder Anfrage automatisch mitbekommt. Sie beantworten die Frage: „Wie soll generierter Code aussehen?“
Skills / Slash-Commands – wiederkehrende Aufgaben kapseln. Benannte, parametrisierbare Abläufe für Dinge, die man immer wieder gleich macht. Sie beantworten: „Wie stoße ich eine bekannte Aufgabe reproduzierbar an?“
Agenten – mehrstufige Workflows orchestrieren. Abläufe, die über einen einzelnen Prompt hinausgehen – mehrere Schritte, Werkzeuge, Prüfungen. Sie beantworten: „Wie lasse ich eine ganze Kette von Schritten zuverlässig laufen?“

Die folgenden Abschnitte nehmen sich jeden Hebel einzeln vor – jeweils durch die SQL-Brille.

Rules-Dateien: Konventionen, die der Agent durchsetzt

Der direkteste Hebel. Eine .claude/rules/-Datei liegt im Repository und wird von Claude Code bei jeder Anfrage als Projekt-Instruktion mitgegeben. Was darin steht, wird zum Default beim Generieren: Schreibt die Regel sp_<verb>_<entity> vor, entsteht sp_upd_project statt update_project – ohne dass jemand im Review daran erinnern muss.

Der Unterschied zum klassischen Style-Guide ist fundamental. Ein Style-Guide im Wiki ist auf menschliche Disziplin angewiesen und wird vergessen; eine Rules-Datei bekommt der Agent bei jeder Generierung vorgesetzt. Aus „bitte halte dich daran“ wird „so wird generiert“. Damit das trägt, muss die Regeldatei für einen Agenten anders gebaut sein als für einen Menschen: explizite Code-Beispiele statt Prosa, ausdrückliche Anti-Patterns (Don'ts) und – am wichtigsten – eine Begründung pro Regel, damit der Agent sie auf neue Fälle übertragen kann.

Wie das im Detail aussieht – vom Namens-Präfix über die zusammenklappbare Block-Struktur bis zum tabellarischen Alignment – zeigt der Schwester-Artikel zu PL/pgSQL-Konventionen an einer kompletten, erprobten sql.md. Er ist die Fallstudie zu diesem Abschnitt.

Das „Was“ hinter den Rules-Dateien – die konkreten Konventionen für Formatierung und Struktur – ist auf diesem Blog ohnehin ausführlich beschrieben: in den Artikeln zur Formatierung von SQL Statements (Teil 1) und Teil 2 sowie zur Strukturierung von SQL Statements. Eine Rules-Datei macht aus diesem Wissen eine maschinell durchgesetzte Regel.

Skills und Slash-Commands: wiederkehrende SQL-Aufgaben

Manche Aufgaben macht man immer wieder gleich: eine neue Tabelle samt Standard-Prozeduren anlegen, ein Protokollierungs-Muster in einen ETL-Schritt einsetzen, ein Statement nach Hausregeln formatieren, einen Datenqualitäts-Check generieren. Ein Skill (in Claude Code als Slash-Command aufrufbar) kapselt so einen Ablauf unter einem Namen – inklusive der nötigen Schritte und Konventionen.

Der Gewinn ist Reproduzierbarkeit: Statt jeden Prompt neu zu formulieren (und dabei mal dies, mal jenes zu vergessen), ruft man den immer gleichen, geprüften Ablauf auf. Für SQL-Arbeit heißt das etwa: ein Skill, der eine Tabelle nach der Surrogate-PK-Regel anlegt und gleich die sp_ins_/sp_upd_-Prozeduren im Hausstil mitgeneriert – jedes Mal identisch strukturiert.

Agenten: mehrstufige Daten-Workflows

Der größte Hebel – und der, der am meisten Sorgfalt verlangt. Ein Agent führt einen Ablauf aus, der über einen einzelnen Prompt hinausgeht: mehrere Schritte, Zwischenergebnisse, Werkzeug-Aufrufe, Prüfungen. Im ETL-Kontext liegt das nahe, weil ETL selbst mehrstufig ist – extrahieren, prüfen, transformieren, laden, protokollieren.

Ein Agent könnte etwa eine Quelltabelle analysieren, einen passenden Datenqualitäts-Check vorschlagen, das Lade-Skript generieren und die Protokollierung einbauen – alles in den Konventionen, die die Rules-Datei vorgibt. Der entscheidende Punkt: Je mehr Schritte ein Agent selbstständig macht, desto wichtiger werden die beiden Leitplanken vom Anfang. Durchgesetzte Konventionen halten den generierten Code prüfbar; ein Mensch, der die fachliche Frage versteht, fängt die plausibel-aber-falschen Ergebnisse ab, die ein Agent genauso flüssig produziert wie die richtigen.

Der rote Faden: generierter Code braucht Verstehen

Durch alle drei Hebel zieht sich dieselbe These: Das Werkzeug nimmt einem das Tippen ab, nicht das Verstehen. Formatieren und Strukturieren von SQL war noch nie nur Kosmetik – es ist der Akt, bei dem man das Statement vollständig liest und die Beziehungen zwischen den Tabellen mental aufbaut. Wenn die KI diesen Akt übernimmt, entsteht eine Lücke: technisch korrektes SQL, das die fachliche Frage trotzdem nicht beantwortet.

Konventionen schließen diese Lücke nicht von selbst – aber sie machen sie sichtbar. Generierter Code, der Hausregeln folgt, ist lesbar genug, dass ein Mensch ihn in Sekunden überprüfen kann, statt ihn erst entziffern zu müssen. Genau deshalb sind Rules, Skills und Agenten kein Ersatz für Fachwissen, sondern ein Verstärker: Sie erledigen das Reproduzierbare zuverlässig und geben dem Menschen den Kopf frei für das, was kein Modell sicher kann – die richtige Frage stellen.

FAQ

Brauche ich Claude Code, oder geht das mit jedem KI-Tool?

Die drei Hebel – durchgesetzte Konventionen, gekapselte Aufgaben, mehrstufige Abläufe – sind als Konzept werkzeug-unabhängig. Die konkrete Umsetzung unterscheidet sich: Claude Code lädt .claude/rules/-Dateien automatisch als Projekt-Instruktion, andere Tools haben eigene Mechanismen (Projekt-Settings, System-Prompts, Custom Instructions). Das Prinzip „Konventionen als maschinell geladene Regel“ überträgt sich, die Datei-Pfade nicht 1:1.

Ist generierter SQL-Code sicher genug für die Produktion?

Nur mit Review. Eine KI produziert plausiblen Code – auch dort, wo er falsch ist. Durchgesetzte Konventionen senken das Risiko, weil generierter Code lesbar und damit prüfbar bleibt; sie ersetzen die Prüfung aber nicht. Sicherheitsrelevante Logik (Permission-Checks, Mutationen) gehört besonders gründlich gegengelesen.

Wie verhindere ich, dass die KI meine Konventionen ignoriert?

Indem die Konventionen als Rules-Datei im Repo liegen statt im Kopf. Drei Dinge helfen: explizite Code-Beispiele statt Prosa-Beschreibungen, ausdrückliche Don'ts (Anti-Patterns) und eine Begründung pro Regel, damit der Agent sie auf nicht beschriebene Fälle überträgt.

Lohnt sich das für Solo-Entwickler oder nur im Team?

Beides – aus unterschiedlichen Gründen. Im Team verhindern Konventionen das Auseinanderdriften über mehrere Hände. Solo ist der Gewinn der „zweite Entwickler“, der die Regeln nie vergisst: Auch wer allein arbeitet, profitiert davon, dass generierter Code konsistent bleibt und in 18 Monaten noch lesbar ist.