Agentic Coding im DWH – Hype oder echter Hebel?
Und was klassische BI-Architekturen davon wirklich haben
Die meisten Datenteams liefern weniger, als sie könnten — nicht, weil Kompetenz fehlt, sondern weil 40–60 % der Engineering-Kapazität in repetitiver Arbeit gebunden ist. Neue Dimensionen modellieren, Pipelines für weitere Quellen aufsetzen, Code-Reviews für Standardänderungen — alles nötig, aber kein Differenzierungsmerkmal. Das Ergebnis: Feature-Backlogs, die über Quartale wachsen, und Time-to-Value für neue Datenanforderungen von Wochen statt Tagen.
Klassisches DWH: Standards als Stärke
Der einfachste Einstieg ist das klassische Data Warehouse. Star Schema, zentrale ETL-Steuerung, klare Namenskonventionen — hier sind Agenten sofort produktiv, weil die Regeln bereits existieren.
Ein konkretes Beispiel: Der bevorzugte Interaktionskanal eines Kunden — Filiale, App, Chatbot oder WhatsApp — soll als neue Dimension ins Modell aufgenommen werden. Ein Agent generiert daraus Staging, SCD2-Dimension, dbt-Modelle, Tests, Dokumentation und den passenden Pull Request.
In einem Versicherungsprojekt mit über 300 dbt-Modellen sank der Boilerplate-Anteil bei bestimmten Änderungstypen um rund 70 %. Gleichzeitig ging die Zahl der im Code-Review gefundenen Konventionsverstöße deutlich zurück.
Data Lake und Lakehouse: Mehr Dynamik, mehr Autonomie
Im Data Lake und Lakehouse geht der Agent einen Schritt weiter: Er reagiert auf Strukturen, die sich erst zur Laufzeit zeigen. Ein typisches Szenario: Eine neue JSON-Quelle wird angebunden. Der Agent:
erkennt den Schema-Drift
passt Bronze/Silver/Gold-Layer an
aktualisiert die Data Contracts
generiert den passenden Spark- oder Python-Code
schreibt Terraform für Cloudinfrastrukturprovisionierung.
Das Onboarding einer neuen Datenquelle — von Schema-Erkennung bis produktionsreife Pipeline — verkürzt sich von 1–2 Wochen auf 1–2 Tage. Bei Unternehmen, die quartalsweise 5–10 neue Quellen anbinden, bedeutet das den Unterschied zwischen einem Datenteam, das hinterherläuft, und einem, das vorausplant.
Data Mesh: Agent als Koordinationsschicht
Wo mehrere Domains ihre Datenprodukte eigenverantwortlich liefern, wird der Agent zur Koordinationsschicht. Ein Beispiel aus der Versicherungswelt: Das Domain-Team „Schadenregulierung" ändert sein Datenprodukt — etwa durch eine neue Schadenart. Der Agent:
prüft den Data Contract,
erkennt den Breaking Change,
erstellt einen Impact-Report für abhängige Consumer-Domains für die abhängigen Domains „Aktuariat" und „Berichtswesen"
benachrichtigt die betroffenen Teams.
Ein ungeplanter Breaking Change im Nachtlauf bindet über mehrere Teams hinweg schnell 4–8 Stunden. Der Agent erkennt das Problem vor dem Deployment und reduziert die Inzidenten um 90 %.
Data Mesh: Agent als Koordinationsschicht
Über alle Architekturmuster hinweg verschiebt sich der Zeitaufwand messbar:
Leistungsvergleich im Data-Engineering
Diese Werte stammen aus einem DWH-Projekt mit über 300 dbt-Modellen — dem gleichen Versicherer, der auch den 70-%-Effekt beim Boilerplate bestätigt. -> Stories, die seit Monaten im Backlog liegen, werden umsetzbar — weil die Kapazität plötzlich da ist.
Sicherheit: Warum Agenten die Compliance verbessern
Ein Agent arbeitet ausschließlich über Pull Requests, in isolierten Umgebungen und mit exakt den Berechtigungen, die sein Aufgabenprofil erfordert — das macht ihn zum aktiven Governance-Instrument:
Keine Secrets in Repositories — der Agent prüft bei jedem Commit automatisch, ob Zugangsdaten, Tokens oder personenbezogene Daten enthalten sind. Diese Prüfung greift unabhängig davon, ob der Code von einem Menschen oder einem anderen Agenten stammt.
Vollständiger Audit Trail — jede Agent-Aktion wird geloggt: welche Dateien geändert, welche Tests ausgeführt, welche Abhängigkeiten aktualisiert wurden.
Kontinuierliches Scanning — Schwachstellen, veraltete Abhängigkeiten und DSGVO-relevante Daten werden automatisiert erkannt, nicht erst beim nächsten manuellen Audit. Grundprinzip bei dem Agentic Coding ist das Least-Privilege-Modell: Jeder Agent erhält nur die Berechtigungen, die er tatsächlich benötigt. Zugriff auf das Code-Repository, aber nicht auf Produktionsdaten. Code-Änderungen ausschließlich über Pull Requests, nie direkt auf den Main-Branch. Darüber hinaus empfiehlt es sich, Agenten explizit in isolierten Umgebungen laufen zu lassen, etwa in Docker-Containern, die den Blast Radius im Fehlerfall begrenzen.
Fazit: Ist Ihre Datenarchitektur bereit?
Agentic Coding ist architekturagnostisch, aber architektursensitiv — es funktioniert überall, entfaltet den größten Hebel aber dort, wo Strukturen bereits stehen. Drei Faktoren entscheiden, wie schnell Sie profitieren:
Konventionen sind dokumentiert — Namenskonventionen, Modellierungsrichtlinien und Code-Standards liegen als versionierte Artefakte im Repository, nicht nur im Kopf einzelner Entwickler.
Pipelines laufen CI/CD-gestützt — Pull Requests, automatisierte Tests, definierte Deployment-Stufen. Der Agent arbeitet im selben Prozess wie das Team.
Mehr als 30 % der Entwicklungszeit fließt in Boilerplate. Je höher dieser Anteil, desto schneller der ROI.
Zwei von drei Punkten treffen zu? Dann lohnt sich ein genauerer Blick.
Sie möchten wissen, wo Agentic Coding in Ihrer Datenarchitektur den größten Hebel hat? In einem kostenlosen 60-Minuten-Assessment analysieren wir Ihre bestehende Umgebung — vom Reifegrad der Dokumentation bis zur Automatisierbarkeit Ihrer Pipelines — und zeigen konkrete Einstiegspunkte auf.
Über den Author: Dmitry Zamyatin
Dmitry Zamyatin arbeitet als Senior Consultant mit Berufserfahrung bei weltweit führenden Versicherungs- und Bankunternehmen im Bereich Data Engineering und DataOps.
Er ist Big Data-Experte mit mehr als 10 Jahren Projekterfahrung in DWH- und Cloud-Migrationen und verfügt über fundierte Kenntnisse in Cloud-Themen wie Datenintegrationen, Lakehäuser, Infrastructure as Code und Jobsteuerung
Bei diesem Blog handelt es sich um Teil 2 unserer Agentic Coding Reihe.
Melden Sie sich jetzt an oder vereinbaren Sie einen Termin, wenn Sie die Fortsetzung nicht verpassen möchten.