Vibe Coding hat die Finanzabteilung erreicht. Es braucht eine abgestimmte Datenbasis.

Finanzteams lassen sich Tabellen, Dashboards und interne Tools inzwischen an einem Nachmittag von einem LLM bauen. Der Code ist meist in Ordnung. Die Zahlen darunter prüft kaum jemand.

Jemand aus dem FP&A-Team hat ein LLM gebeten, ein Churn-Dashboard zu bauen. Zwanzig Minuten später stand es: eine funktionierende Web-App, Charts, Filter, sauberes Layout, auf einer internen URL live. Niemand hat ein Lastenheft geschrieben. Niemand hat ein Ticket bei der Entwicklung aufgemacht. Das Tool existiert einfach, und bis Freitag nutzen drei Leute es, um zu entscheiden, welche Accounts einen Anruf zur Vertragsverlängerung bekommen.

Das ist Vibe Coding, und es ist in Finanzfunktionen still und leise zur Normalität geworden. Ein Analyst beschreibt in normalem Deutsch (oder Englisch), was er will, das Modell schreibt die App, und der Analyst verfeinert sie, indem er beschreibt, was noch nicht passt, bis es passt. Für einen einmaligen Chart oder eine schnelle Rechnung ist das ein echter Produktivitätsgewinn: schneller als ein Ticket aufzumachen, schneller als eine Pivot-Tabelle von Hand zu bauen. Das Problem zeigt sich erst später, wenn aus derselben Wegwerf-Gewohnheit ein Tool wird, dem andere Leute zu vertrauen beginnen.

Die Logik wird geprüft. Die Zahlen nie

Hier der genaue Mechanismus, und es lohnt sich, ihn präzise zu benennen, denn “KI-Tools können sich irren” ist zu vage, um daraus etwas abzuleiten. Ein vibe-gecodetes Finanztool hat zwei Schichten: die Logik, die das LLM schreibt (die Churn-Formel, die Aggregation, den Chart), und die Zahlen, mit denen diese Logik arbeitet (Kundendaten, Umsatzzahlen, was auch immer eingefügt oder per API eingespeist wird). Bei der ersten Schicht ist Vibe Coding tatsächlich gut: Code, der läuft, rendert und ungefähr das tut, was verlangt wurde, lässt sich leicht mit dem Auge prüfen, weil man sieht, wie der Chart sich aktualisiert und plausibel aussieht.

Die zweite Schicht bekommt keine dieser Prüfungen. Das LLM kontrolliert nicht, woher die Eingabezahlen stammen; es vertraut dem, was in der CSV-Datei, der eingefügten Tabelle oder der API-Antwort steht, genau wie es dem vertraut, was in einer Excel-Zelle steht, die es lesen soll. Sind die Ausgangszahlen veraltet, nur halb abgestimmt oder auf subtile Weise falsch, stellt die App darauf die falsche Zahl trotzdem wunderschön dar. Ein sauberer Chart ist kein Beweis für eine korrekte Zahl, sondern nur dafür, dass der Code kompiliert. Niemand prüft die Daten so, wie man die Funktion prüfen würde, denn die Daten sind kein Code: sie sind nur eine Eingabe, die das Tool auf Treu und Glauben übernimmt.

Genau an dieser Nahtstelle gelangen halluzinierte oder verfälschte Zahlen in den Produktivbetrieb: nicht weil die KI sich eine Zahl aus dem Nichts ausgedacht hätte, sondern weil an keiner Stelle der Kette jemand geprüft hat, ob die übergebene Zahl stimmt. Das Tool wirkt seriös. Die Zahl darunter wurde nie mit einer Quelle abgeglichen.

Eine Reifegrad-Linie, und wo Zuverlässigkeit keine Option mehr ist

Nicht jedes vibe-gecodete Tool braucht denselben Maßstab. Das Risiko hängt davon ab, wie weit sich das Ergebnis von der Person entfernt, die es gebaut hat.

Stufe	Wie sieht das aus	Wer trägt das Risiko bei einer falschen Zahl	Zuverlässigkeitsanspruch
Rückseite eines Bierdeckels	Eine Person, eine Frage, danach weggeworfen	Nur der Autor, der den Kontext kennt	Niedrig, es geht ums Ausprobieren
Wiederverwendetes internes Tool	Geteilter Link, ein Team schaut wöchentlich rein	Ein Team, das es nicht gebaut hat und die Annahmen nicht sieht	Mittel, irgendwann handelt jemand nach einer Zahl, die er nicht selbst erzeugt hat
Produktiver Workflow	Speist einen Report, eine Prognose, eine Entscheidung mit Geldbezug	Wer downstream unterschreibt, im Zweifel Vorstand oder Wirtschaftsprüfer	Hoch, die Zahl braucht eine nachvollziehbare Quelle, kein Bauchgefühl

Die meisten vibe-gecodeten Tools entstehen auf Stufe eins, und niemand bemerkt den Übergang zu Stufe zwei. Es gibt kein Freigabe-Gate für “jetzt schauen drei Leute jeden Montag rein”. Es passiert einfach, meist weil das Tool wirklich nützlich war und sich herumgesprochen hat. Wenn es auf Stufe drei angekommen ist und einen Abweichungsbericht speist, läuft es immer noch mit denselben ungeprüften Eingaben wie am ersten Tag: der Code wurde immer schicker, die Daten darunter hat nie jemand geprüft.

Der Fehler liegt darin, das als Problem der Bauqualität zu behandeln. Das ist es nicht. Ein hervorragend gebautes Dashboard über einem nicht abgestimmten CSV-Export bleibt eine hervorragend gebaute Vermutung.

Warum “dann eben sauber neu bauen” der falsche Reflex ist

Der naheliegende Reflex, sobald jemand merkt, dass ein vibe-gecodetes Tool tragend geworden ist, lautet: an die Entwicklung übergeben und neu bauen lassen. Das ist meist überzogen und killt genau das, was das Tool wertvoll gemacht hat: dass ein Analyst eine Änderung in einem Satz beschreiben und Minuten später live sehen kann. Zwängt man das in einen Sprint-Zyklus, hört das Tool auf, gepflegt zu werden, was ein eigenes Risiko ist: Jetzt gibt es ein veraltetes, ungepflegtes Tool, dem aus Gewohnheit weiter vertraut wird.

Die Logik des Tools war nie wirklich das Problem. Sie ist gut lesbar, schnell zu ändern, und genau für dieses Grundgerüst ist das LLM gut geeignet. Was fehlt, liegt darunter: etwas, das garantiert, dass die Zahlen, mit denen das Tool gefüttert wird, tatsächlich auf die Buchhaltung, das CRM oder das Data Warehouse zurückzuführen sind (wo auch immer die echte Zahl herkommt), statt auf einen Snapshot, den jemand vor drei Wochen exportiert und dann vergessen hat. Die Datenquelle austauschen, nicht das Tool. Die vibe-gecodete App behält ihre Fünf-Minuten-Iterationsschleife; die Zahl, die sie darstellt, hört auf, geraten zu sein.

Das ist ein enger gefasster Anspruch als “baut euren Datenstack neu”, und es ist wichtig, dass er eng bleibt. Das meiste, was diese Tools berechnen (eine Churn-Rate, eine Marge, ein Kohorten-Split) ist eine simple Aggregation, sobald die Eingaben verlässlich sind. Die Arithmetik war nie das Schwierige. Schwierig ist zu wissen, dass die Eingabezahl die echte ist und keine veraltete Kopie: genau das Thema, das ausführlicher behandelt wird unter warum eine Tabellenkalkulation das falsche Fundament für KI in der Finanzabteilung ist, derselbe stille Fehlermechanismus, nur mit einer Tabellenkalkulation statt einer vibe-gecodeten App als vertrauter Eingabe.

Wie “darunter, nicht stattdessen” in der Praxis aussieht

Konkret braucht ein vibe-gecodetes Tool eine Ergänzung, keinen Ersatz: eine Abfrage, die es zur Build-Zeit oder zur Laufzeit stellen kann und die eine Zahl mit Quellenbezug liefert, statt was auch immer gerade in einer lokalen Datei liegt. Das ist die Form der Lösung: keine neue Oberfläche, keine Migration, eine Verbindung.

Genau hier hat Rexfin seinen Platz im Stack. Rexfin gleicht Buchhaltungs-, Bank- und Warehouse-Daten in einem Modell ab, das auf die Bücher zurückzuführen ist, und stellt es über MCP bereit, sodass ein vibe-gecodetes Tool keine eigene Datenpipeline braucht, ein Analyst keinem Copy-Paste von vor drei Wochen vertrauen muss und das LLM, das die Tool-Logik schreibt, den “aktuellen MRR” oder die “Bruttomarge, letztes Quartal” aus einer Quelle ziehen kann, die ihre Herkunft belegen kann. Das Tool entsteht immer noch an einem Nachmittag. Die Zahl, die es anzeigt, hat jetzt einen Beleg dahinter statt eine Vermutung.

Das ist auch der Grund, warum die Lösung nicht auf “dann lasst doch den Code-Interpreter das korrekt berechnen” hinausläuft: ein deterministischer Rechner löst die Arithmetik, nicht die Herkunft dessen, was berechnet wird. Warum “einfach einen Code-Interpreter nutzen” KI in der Finanzabteilung nicht sicher macht behandelt genau diese Lücke: korrekte Mathematik auf einer falschen oder nicht nachvollziehbaren Eingabe bleibt eine falsche Antwort, nur eine, die unterwegs sauber durchgerechnet wurde.

Fazit

Vibe Coding hat der Finanzabteilung kein neues Risiko gebracht: es hat ein altes schneller gemacht. Teams haben schon immer Ad-hoc-Tabellen und einmalige Tools auf Daten gebaut, die niemand erneut geprüft hat; der Unterschied ist heute, dass ein LLM so etwas in Minuten hinstellt und es dabei so poliert aussieht, dass man ihm ohne Nachfrage vertraut. Die Lösung ist nicht, das Tool-Bauen zu verlangsamen. Sie besteht darin, sicherzustellen, dass alles, was gebaut wird (auf welcher Reifestufe auch immer) seine Zahlen aus etwas Abgestimmtem zieht statt aus etwas Exportiertem.

Wenn Ihr Team bereits interne Finanztools vibe-codet (und das tun die meisten, ob offiziell oder nicht), lohnt sich die Frage, woher diese Tools ihre Zahlen beziehen und ob sich eine davon auf Nachfrage bis zur Quelle zurückverfolgen ließe. Zum größeren Muster, wie KI selbstsicher wirkende, unbelegte Zahlen im Finanzbereich produziert, siehe den Grundlagenartikel zu KI-Halluzinationen bei Finanzdaten. Um zu sehen, wie eine abfragbare, abgestimmte Datenbasis an Ihren eigenen Daten aussieht, vereinbaren Sie eine Demo.