Vom Coding-Assistenten zum Sparringspartner: Die nächste Evolutionsstufe von „AI-Assisted“ in Datenprojekten

AI-Assisted Coding in Datenprojekten

Wer über AI-Assisted Coding spricht, spricht im Kontext von Datenprojekten fast immer über den falschen Teil des Problems.
 Die Debatte kreist um Prompt-to-Code, um Produktivitätsgewinne beim Schreiben von SQL- oder Python-Skripten, um Benchmarks und darum, welches LLM den besseren Boilerplate-Code erzeugt.

Das Narrativ ist einfach, eingängig und letztlich irreführend: KI macht Entwickler schneller, weil KI Code schreibt. Diese Erzählung ignoriert, woran anspruchsvolle Datenprojekte tatsächlich scheitern: Insbesondere in Datenprojekten ist Implementierung nur selten der Engpass. Kaum ein Data-Team kämpft heute primär damit, dass niemand in der Lage wäre, einen dbt-Model-Layer, eine SQL-Transformation oder eine ETL-Pipeline zu bauen. Datenprojekte sind daher auf hoher, technischer Ebene häufig vergleichsweise banal: Tabellen werden transformiert, Kennzahlen aggregiert, Dimensionen modelliert, Business Rules in SQL gegossen.

Das Handwerk selbst ist etabliert. Die verwendeten Technologien sind ausgereift. Die Patterns sind bekannt. Was Projekte verzögert, verteuert und sogar scheitern lässt, ist nicht die Umsetzung. Es ist die Unschärfe dessen, was umgesetzt werden soll.

Das Dilemma

Der kritische Rohstoff moderner Datenprojekte ist daher nicht Code. Es ist fachliche Klarheit und Konsistenz über Abteilungs-, System- und Unternehmensgrenzen hinweg. Und genau deshalb liegt der eigentliche Nutzen von KI nicht in der Beschleunigung der Implementierung, sondern in der strukturierten Erzeugung der benötigten, fachlichen Klarheit. Der Grund ist einfach: Datenprojekte kodifizieren Geschäftslogik.

Sie sind keine rein technischen Systeme, sondern formalisiertes Organisationsverständnis. Jede Kennzahl, jede Aggregation, jede Dimension ist eine explizite Modellierung dessen, wie ein Unternehmen seine Realität interpretiert. Der klassische Verlauf ist bekannt: Ein Fachbereich fordert „einen Sales Data Mart“. Im Kick-off scheint Einigkeit zu herrschen. Wochen später stellt sich heraus, dass unterschiedliche Stakeholder unter „Revenue“ unterschiedliche Dinge verstehen. Technisch ist daran nichts komplex. Die Komplexität liegt in der Semantik.

AI-Assisted Bug

Vor diesem Hintergrund geht die gegenwärtige Fokussierung auf KI als Coding-Assistent am Kern der Sache vorbei. Denn selbst wenn ein Modell perfekte SQL-Statements erzeugt, bleibt die zentrale Frage unberührt: Ist das implementierte Modell fachlich überhaupt sinnvoll? Ein fehlerfrei generiertes Datenmodell auf Basis unpräziser Anforderungen ist kein Erfolg, sondern ein hoch effizient produzierter Fehler.

Die entscheidende Leistung in analytischen Datenprojekten liegt daher in der vorgelagerten Transformation unscharfer, oft widersprüchlicher Business-Anforderungen in belastbare Spezifikationen. Genau diese Übersetzungsarbeit ist traditionell teuer, zeitintensiv und stark von individuellen Experten abhängig. Sie ist in vielen Organisationen der eigentliche Engpass. Und genau dieses Bottleneck beginnt KI nun zu adressieren.

AI-Assisted Specification

Was sich aktuell abzeichnet, ist im Kern die Renaissance eines Entwicklungsparadigmas: Specification-Driven Development[1]. Der Kern dieses Ansatzes ist simpel. Implementierung ist nicht der Ausgangspunkt einer Entwicklung, sondern ihr Endpunkt. Das primäre Artefakt eines Projekts ist nicht Code, sondern Spezifikationen. Wenn ein System ausreichend präzise beschrieben ist, wird die Implementierung zur nahezu mechanischen Ableitung.

Historisch scheiterte dieser Ansatz selten an mangelnder Überzeugung, sondern an Kosten und Disziplin. Hochwertige Spezifikation ist aufwendig. Sie erfordert Erfahrung, Iteration und strukturierte Auseinandersetzung mit Widersprüchen.

KI verändert nun diese Ökonomie. Erstmals stehen „AI-Assisted“ Ansätze zur Verfügung, die Spezifikationsarbeit aktiv begleiten können und damit leichter und attraktiver machen als zuvor.

AI als Gegenüber

Der vielleicht wichtigste Perspektivwechsel lautet daher:
 Die relevanteste Rolle von KI im Projekt ist nicht die eines Coding-Assistenten, sondern die eines „Gegenübers”.

Ein gutes KI-gestütztes System akzeptiert Anforderungen nicht kommentarlos, es widerspricht und hinterfragt, verlangt Präzisierung und identifiziert Lücken. Wenn ein Stakeholder formuliert, „Wir brauchen Churn Reporting“, dann sollte ein solches System zunächst das eigentliche Problem greifbar machen:

• Was genau bedeutet Churn in diesem Unternehmen?
• Welche Kundenkohorten sind betroffen?
• Wie wird Reaktivierung behandelt?
• Gilt Vertragskündigung oder Inaktivität als Churn?
• …

Eine eher unbequeme KI, die möglichst viele gute Fragen stellt, ist in diesem Kontext die produktivere Variante der Zusammenarbeit zwischen Mensch und KI. Denn gute Spezifikation entsteht häufig erst durch konfrontative Präzisierung im Dialog. Allerdings sind heutige KI-Systeme mit LLMs im Hintergrund nicht immer gut darin unbequem zu sein. Sie tendieren zu einer Art opportunistischen Zustimmung (Sycophancy[2]) und es bedarf einiger Kniffe sie davon abzubringen.

Strukturierte Präzisierung mit kreativen Ansätzen

Ein Beispiel für diese Art „Gegenüber”, welches eine Diskussion und Konfrontation unterstützen kann, ist die Creative Intelligence Suite (CIS)[3] im BMad Eco-System[4].

BMad ist ein KI-gestützter Entwicklungsansatz, der strukturierte Workflows, Rollen und Spezifikationsartefakte kombiniert, um Softwareprojekte systematischer „AI-Assisted” umzusetzen. BMad verfolgt die Idee, dass der Kontext für Anfragen an LLMs nicht implizit in einzelnen Prompts verloren geht, sondern systematisch aufgebaut, strukturiert dokumentiert und entlang des Entwicklungsprozesses weitergegeben werden kann.

Die Creative Intelligence Suite:

A collection of agents and workflows for innovation, brainstorming, design thinking, and creative problem-solving.[5]

stellt dabei verschiedene strukturierte Kreativitäts- und Explorationsmethoden zur Verfügung, um beispielsweise implizites Wissen, versteckte Annahmen oder alternative Interpretationen frühzeitig sichtbar zu machen, bevor diese in Spezifikationen oder Implementierungen verfestigt werden.

Creative intelligence is the ability to generate novel, valuable ideas and solutions using structured approaches rather than random inspiration. Unlike “creativity” as an innate trait, creative intelligence is a learnable skill set combining:

• Divergent thinking: Generating many options before evaluating
• Pattern recognition: Seeing connections others miss
• Reframing: Looking at problems from new angles
• Synthesis: Combining disparate elements into something new
• Iterative development: Building ideas through cycles of improvement[5]

Damit lassen sich auch in Datenprojekten kreative Exploration mit strukturiertem Vorgehen kombinieren und beispielsweise in einer „AI assisted” Brainstorming-Session neue Ideen und insbesondere weitere Einsichten als Vorbereitung zur Spezifikation herausarbeiten. Zu obigem Beispiel lassen sich vielleicht schon:

• bewusst mehrere konkurrierende Interpretationen eines Begriffs wie „Churn“, oder „Revenue“ darstellen,
• Implizite Annahmen sichtbar machen,
• Widersprüche zwischen Stakeholdern identifizieren,
• Entscheidungen zwischen alternativen Definitionen herbeiführen

Spezifikation zwischen Datenrealität und Kreativität

Insbesondere der „verteilte” und „heterogene” Charakter von Datenprojekten über Abteilungs-, System- und Organisationsgrenzen hinweg bringt besondere Herausforderungen, viel Komplexität und auch einige Fallstricke mit sich. Zudem sind in der Regel eine Vielzahl verschiedener Quellen und Informationen zu berücksichtigen.

Ein Data-Team, das nicht über Abteilungsgrenzen hinweg aufgestellt ist und über die jeweilige fachliche Expertise verfügt wird dies in der Realität allerdings kaum leisten können. Um das Team dahingehend zu unterstützen kann der Kontext, auf den die KI zugreifen kann, um weiteres Wissen, wie beispielsweise exemplarische, ggf. anonymisierte, Datensätze und Strukturen, Metadaten, falls vorhanden Video-Transkriptionen von Meetings oder sonstige Dokumentation angereichert werden. Im kreativen Teil des Vorhabens lässt sich dieses Wissen dann schon verwenden.

Ob dieser Ansatz, in ein Projekt zu starten, infrage kommt hängt natürlich vom Projekt selbst und den jeweiligen Gegebenheiten ab. Aber es eröffnet die Möglichkeit strukturiert in die Diskussion zu kommen und das mit einer Prise Kreativität. Letztendlich ist der entscheidende Punkt dabei nicht das Tool selbst, sondern dass Spezifikation durch KI zu einem expliziten, geführten Prozess werden kann und nicht nur zu einem Nebenprodukt von Meetings.

Fazit: Die Zukunft gehört Systemen, die Klarheit schaffen

Die populäre Vorstellung, AI-Assisted Coding werde primär deshalb transformativ sein, weil Maschinen künftig Code schreiben, greift zu kurz. Code ist nie der entscheidende Produktionsfaktor anspruchsvoller Datenprojekte. Das ist und bleibt die Fähigkeit, fachliche Realität präzise genug zu modellieren.

Genau dort kann KI weiteres Potenzial entfalten. Wenn sie nicht als schnellerer Entwickler, besseres Autocomplete oder gar als Boilerplate-Machine agiert, sondern als strukturiertes Gegenüber im Denkprozess.

Referenzen

[1] Specification-Driven Development

[2] Towards Understanding Sycophancy in Language Models

[3] CIS, Creative Intelligence Suite

[4] BMad, Build More Architect Dreams

[5] CIS Brainstorming Techniques

[Titel-Bild] "Al-Assisted Coding in Datenprojekten – Klarheit vor Code." ist KI generiert