Du arbeitest an einer Data Pipeline. Nach einem nächtlichen Lauf stellen die Zahlen, aber nur auf den ersten Blick. Irgendwo hat sich ein Fehler eingeschlichen: eine doppelte Zeile, ein falscher Join, der nicht auffällt, weil das Ergebnis nicht abstürzt. Ein Fehler, der nicht bricht, sondern leise falsche Werte liefert, kann in Berichten und Entscheidungen unbemerkt verheerend wirken. In der Datentechnik geht es nicht nur darum, Code zu produzieren, sondern Code, dem wir vertrauen können.
KI-Agenten sollen dabei helfen. Aber wie viel Vertrauen darf man ihnen schenken? Ein aktueller Artikel beschäftigt sich mit dieser Frage und stellt die Korrektheitsschicht vor – ein Sicherheitsnetz, das die Zuverlässigkeit von KI-generierten Datenpipelines erhöht. Der Artikel untersucht drei Ebenen von KI-Agenten in der Datentechnik, die Rolle deterministischer Validierung und wie sich Token-Kosten kontrollieren lassen. Fazit: Die Struktur eines Projekts und die richtigen Werkzeuge sind wichtiger als das neueste Sprachmodell.
Die drei Ebenen der KI-Agenten in der Datentechnik
Warum Agenten für die Datentechnik einsetzen? Und auf welchen Ebenen können sie produktiv helfen? Sprachmodelle haben, wie Menschen, eine gewisse Fehlertoleranz. Wir brauchen eine Möglichkeit, sicherer zu sein, dass der produzierte Code korrekt ist. Der Artikel unterscheidet drei Stufen.
Erste Ebene: die reine Chat-Phase. Hier prompten wir Claude oder ChatGPT. Das Modell versucht, den Kontext zu verstehen, basierend auf dem, worauf es Zugriff hat. Das verbraucht viele Tokens, weil es alles von Grund auf scannen muss. Das Ergebnis ist brauchbar, aber selten produktionsreif.
Zweite Ebene: der autonome Ansatz. Hier haben Agenten wie Claude Code oder Codex Zugriff auf dieselben Werkzeuge wie ein Mensch – die Kommandozeile. Sie können Postgres mit psql abfragen, mit DuckDB aus S3 oder Parquet lesen und so Daten und Queries direkt verifizieren. Die Qualität der Ergebnisse ist höher, weil der Agent nicht nur rät, sondern überprüft.
Dritte Ebene: dedizierte Agenten für die spezifische Aufgabe. Für die Datentechnik kennen diese Agenten dbt oder können SQL-Code deterministisch transpilieren – nicht aus Trainingsdaten, sondern mit einem Werkzeug, das schneller und zuverlässiger arbeitet. Sie haben eingebaute Prüfungen und Funktionen, die ein allgemeiner Agent nicht bietet. Ideal sind immer dedizierte Werkzeuge – aber es gibt nicht für jede Aufgabe ein solches.
Wo im Datenlebenszyklus jede Ebene wirklich hilft
Die Frage ist nicht nur, ob es dedizierte Agenten gibt, sondern in welchem Teil des Datenlebenszyklus sie den größten Nutzen bringen. Geht es um BI-Dashboards, Datenleitungen, Quell-Ingestionen oder Wartung? Der Lebenszyklus umfasst Extraktion, Transformation und Laden, das Verständnis der Geschäftslogik, die Visualisierung der Ergebnisse und die Fehlerbehebung bei nächtlichen Läufen. Grundsätzlich können Agenten im gesamten Zyklus helfen, aber die Antwort hängt stark von der Rolle und Erfahrung des Anwenders ab. Ohne Vorwissen oder Seniorität ist es gefährlich, von Grund auf etwas zu bauen. Man kann nicht überprüfen, ob der Code korrekt ist. Für Nebenprojekte oder Proof-of-Concepts ist das okay, aber nicht für die Produktion.
Die Ingenieursdisziplin im Umgang mit KI
Es gibt auch einen weniger technischen Teil: die Agenten in die richtige Richtung lenken. Wenn wir KI sicher in großen Projekten oder Organisationen einsetzen wollen, können wir sie nicht ohne Führung laufen lassen. Vier Punkte helfen dabei.
Erstens: eine klare Projektstruktur, in der die Agenten sich entfalten können. Je mehr vorgegeben ist, desto weniger Tokens werden verbraucht, desto einheitlicher wird das Projekt. Ein deterministischer Workflow wie uv init ist optimal, weil er immer gleich abläuft.
Zweitens: baue mit klaren Anweisungen – Agenten-Fähigkeiten oder Superkräfte – wie die Werkzeuge verwendet werden. Das bedeutet, dem Agenten CLI- und API-Dokumentationen bereitzustellen. Das ist der Hauptteil der Arbeit. Es geht um die Datenarchitektur, das Brainstorming mit Kollegen, bevor man etwas baut, damit man keine entscheidende Einsicht verpasst und den Agenten in die falsche Richtung laufen lässt. Ein Prompt wie „sei korrekt“ oder „verwende den neuesten Stand der Technik“ macht den Code nicht korrekter oder moderner, als das Modell trainiert wurde. Bei relativ neuen Architekturen muss man dem Agenten die entsprechenden Links und Hinweise geben.
Drittens: gestalte das Projekt modular, sodass die Agenten nicht das gesamte Projekt zerstören können, wenn sie eine kleine Änderung vornehmen. Kein Abhängigkeits-Chaos, bei dem alles von allem abhängt.
Viertens: verwende einen deklarativen Ansatz mit beschreibender Konfiguration, der das „Was“ und nicht das „Wie“ festlegt. So kannst du mit den Agenten an diesen Konfigurationen zusammenarbeiten, sie versionieren, leicht zurücksetzen oder ändern und die Implementierungslogik von der Geschäftslogik entkoppeln. Das Modell spielt eine geringere Rolle. Struktur und Workflow sind entscheidend. Plane ausgiebig, bevor du eine einzige Zeile schreibst, und korrigiere das Modell, bevor es in die falsche Richtung läuft. Ziel ist Nutzen aus der KI, nicht mehr Arbeit. Früher dachten die meisten Entwickler über das Problem nach. Heute ertrinken viele in Pull-Requests. Bessere KI-Werkzeuge können qualitativ hochwertigeren Code liefern, der weniger Überprüfung und weniger Iterationen erfordert – also weniger PRs und weniger Arbeit.
Die Korrektheitsschicht für Dateningenieure
KI-Agenten sollten den Menschen für Korrektheit unterstützen – oder eine Korrektheitsschicht. Statt mehr Arbeit zu verursachen, um mehr Code zu verifizieren, sollten wir Vertrauen in den Prozess haben und wissen, dass der produzierte Code verifiziert und korrekt ist. Eine deterministische Validierungsarchitektur ist dafür zentral. Der Artikel führt Altimate Code als Beispiel an. Dieses Tool teilt den Agenten in eine probabilistische Schicht oben und eine deterministische Rust/TS-Schicht unten auf, die die eigentlichen SQL-Operationen wie Parsen, Validieren und Äquivalenzprüfungen übernimmt. Der Agent selbst muss bei diesen Fragen nie vertraut werden.
Konkret: Der probabilistische Agent mit dem LLM übernimmt die kreative Arbeit – Intention lesen, Strategie wählen, SQL entwerfen, Ergebnisse zusammenfassen, sich von Fehlern erholen. Unter dieser Grenze liegt das deterministische Geschirr (deterministic harness), eine TypeScript-Schicht, die jeden Werkzeugaufruf abfängt. Ein Dispatcher prüft, ob ein nativer Handler existiert, und leitet den Aufruf entweder an einen nativen, deterministischen Handler oder zurück an das Modell. Diese Handler rufen die Logik nicht selbst auf, sondern ein deterministisches Core-Modul in Rust (altimate-core), das SQL-Operationen als reine Funktionen über ASTs und Schemata bereitstellt. Parsen, Validieren, Transpilieren, Query-Äquivalenz prüfen, Schema-Diffs, Column-Lineage extrahieren, Zeilen-Diffs über Data Warehouses hinweg – all das läuft sub-Millisekunde und liefert bei gleichem Input immer die gleiche Antwort. Wie ein Compiler: Der Agent entscheidet nie, ob zwei Queries äquivalent sind oder eine Spalte upstream existiert. Stattdessen ruft er eine Funktion auf, die es am geparsten AST und Schema beweist – so wie ein Type-Checker beweist, dass ein Programm kompiliert, anstatt zu raten.
Das macht die Ausgabe leichter überprüfbar: Faktische Prüfungen wurden ausgeführt, und die Ausgabe ist entweder korrekt, oder es gibt einen Bug, den der Agent direkt beheben kann. Den Rest kann ein Mensch verifizieren. Das Dilemma: Code wird schneller genehmigt, als geprüft werden kann. Dazu gibt es einen separaten Beitrag. Ein weiterer Faktor: Reiner Agenteneinsatz mag günstig erscheinen – aber nur, bis er falsch liegt. Dann sind die Kosten unbegrenzt.
Verbesserungen für eine bessere Token-Nutzung
Altimate Code oder ähnliche Agenten mit deterministischen Funktionen helfen, Tokens zu sparen und token-effizient zu arbeiten – das Gegenteil von Tokenmaxxing, einem Trend auf Social Media, bei dem möglichst viele Tokens verbraucht werden und Agenten rund um die Uhr laufen. In großen Unternehmen sind Token-Kosten ein echtes Budget-Thema. Ein einfacher Trick: Weist das Modell an, selbst weniger Tokens und Wörter zu verwenden – „Höhlenmensch-Stil“ ist ein Beispiel. Du kannst auch einen einzelnen Prompt in deine CLAUDE.md oder in Codex einfügen, in Kombination mit Altimate Code.
Es gibt einen zweiten, weniger offensichtlichen Kostenpunkt: Der Token selbst ist keine stabile Einheit. Als Anthropic Opus 4.7 auslieferte, kostete derselbe Prompt, der auf 4.6 X Tokens verbrauchte, auf 4.7 plötzlich etwa 1,4X – gleicher Input, gleiche Antwort, mehr Tokens, gleicher Preis pro Token. Der Artikel verweist auf einen Beitrag, der argumentiert, dass „Kosten pro Token“ die falsche Kennzahl sei, denn der Zähler selbst kann sich mit dem nächsten Modell-Update des Anbieters verschieben. Was wir stattdessen verfolgen sollten, sind Kosten pro Aufgabe. Deterministische Funktionsaufrufe umgehen diese Volatilität, indem sie für viele Aufgaben gar kein Modell und keine Tokens benötigen – das macht die Sache günstiger.
Typische Anwendungsfälle
Welche konkreten Einsatzmöglichkeiten gibt es für KI-Agenten in der Datentechnik? Die Liste ist lang. Du kannst sie nutzen, um dich oder dein Team weiterzubilden, produktive Datenpipelines zu bauen, Daten-Apps zu entwickeln und Daten auf innovative Weise zu visualisieren – meistens als HTML-Seiten mit React und anderen JavaScript-Frameworks. Die Anwendungsfälle lassen sich in verschiedene Ansätze gliedern: von der Unterstützung bei der Codeerstellung über die Automatisierung von Tests bis hin zur Generierung von Dokumentation. Der entscheidende Punkt bleibt: Ohne eine Korrektheitsschicht und eine durchdachte Projektstruktur wirst du auf Dauer keine verlässlichen Ergebnisse erzielen. Die Werkzeuge sind da, aber du musst wissen, wie du sie einsetzt.
Was bedeutet das für den Dateningenieuralltag? Vertraue nicht blind, sondern baue eine deterministische Validierung ein. So werden KI-Agenten von einer Blackbox zu einem verlässlichen Partner. Je besser die Werkzeuge, desto unabhängiger wirst du von jedem einzelnen Modell. Der deterministische Rahmen – die Korrektheitsschicht – ermöglicht es, Ergebnisse zu reproduzieren und ihre Herkunft nachzuverfolgen, unabhängig vom Modell. Das gilt besonders bei Wartungsarbeiten oder Erweiterungen, bei denen die Überprüfung die eigentliche Arbeit ist. Die Gefahr liegt nicht im Absturz, sondern in einer falschen Zahl, die nicht auffällt. Es mag eine saubere Query sein, aber sie führt zu doppelten Zeilen. Mit der richtigen Architektur kannst du solche stillen Fehler eliminieren. Hier liegt der Schwerpunkt: menschliche Expertise, Projektstruktur und Korrektheitsschicht machen den Unterschied.
Quelle: ssp.sh
