Il Vibe Coding è Arrivato in Finanza. Serve un Livello di Base Riconciliato.

Qualcuno nel team FP&A ha chiesto a un LLM di costruire una dashboard sul churn. Venti minuti dopo ne aveva una: un’applicazione web funzionante, grafici, filtri, un layout pulito, distribuita su un URL interno. Nessuno ha scritto una specifica. Nessuno ha aperto un ticket con l’ingegneria. Semplicemente esiste ora, e per venerdì tre persone la stanno usando per decidere quali account ricevono una chiamata di rinnovo.

Questo è vibe coding, ed è diventato silenziosamente normale nelle funzioni finanziarie. Un analista descrive ciò che vuole in linguaggio semplice, il modello scrive l’app, e l’analista itera descrivendo cosa non va finché non sembra giusto. Per un grafico occasionale o un calcolo al volo, questo è un autentico guadagno di produttività, più veloce che aprire un ticket, più veloce che costruire una tabella pivot a mano. La modalità di fallimento emerge dopo, quando la stessa abitudine usa-e-getta produce uno strumento di cui altre persone iniziano a fidarsi.

La logica viene revisionata. I numeri mai

Ecco il meccanismo specifico, e vale la pena essere precisi perché “gli strumenti IA possono sbagliare” è troppo vago per agire di conseguenza. Uno strumento finanziario vibe-coded ha due livelli: la logica scritta dall’LLM (la formula del churn, l’aggregazione, il grafico) e i numeri su cui quella logica gira (dati clienti, cifre di ricavo, qualunque cosa venga incollata o instradata da un’API). Il vibe coding è genuinamente decente sul primo livello: un codice che gira, si visualizza, e fa più o meno quanto richiesto è facile da controllare a occhio, perché si vede il grafico aggiornarsi e sembra plausibile.

Il secondo livello non riceve nessuno di questi controlli. L’LLM non verifica da dove vengano i numeri in ingresso; si fida di qualunque cosa sia nel CSV, nella tabella incollata o nella risposta dell’API, allo stesso modo in cui si fida di qualunque cosa sia in una cella di foglio di calcolo che gli viene chiesto di leggere. Se le cifre sorgente sono obsolete, riconciliate a metà o sottilmente sbagliate, l’app costruita sopra di esse renderà quel numero sbagliato in modo splendido. Un grafico pulito non è prova di un numero corretto; è prova che il codice si è compilato. Nessuno fa code review dei dati come farebbe code review della funzione, perché i dati non sono codice, sono solo un input che lo strumento accetta sulla fiducia.

È esattamente questa la fessura da cui entrano in produzione numeri allucinati o corrotti: non perché l’IA abbia inventato una cifra dal nulla, ma perché niente nella pipeline è mai stato chiamato a verificare la cifra che gli è stata consegnata. Lo strumento sembra rigoroso. Il numero sottostante non è mai stato controllato rispetto a una fonte.

Una linea di maturità, e dove l’affidabilità smette di essere opzionale

Non ogni strumento vibe-coded richiede la stessa soglia. Il rischio segue quanto lontano viaggia l’output dalla persona che lo ha costruito.

Fase	Come si presenta	Chi è esposto se un numero è sbagliato	Requisito di affidabilità
Calcolo al volo	Una persona, una domanda, buttato via dopo	Solo l’autore, che ha il contesto	Basso, l’esplorazione è il punto
Strumento interno riutilizzabile	Link condiviso, un team lo controlla settimanalmente	Un team che non lo ha costruito e non vede le ipotesi	Medio, prima o poi qualcuno agirà su un numero che non ha generato
Flusso di lavoro in produzione	Alimenta un report, una previsione, una decisione con denaro coinvolto	Chi firma a valle, possibilmente un board o un revisore	Alto, il numero ha bisogno di una fonte tracciabile, non di una sensazione

La maggior parte degli strumenti vibe-coded nasce alla fase uno e nessuno si accorge quando attraversano verso la fase due. Non esiste un cancello di distribuzione per “ora tre persone lo controllano ogni lunedì”. Succede e basta, di solito perché lo strumento era genuinamente utile e la voce si è sparsa. Quando arriva ad alimentare un report sugli scostamenti alla fase tre, gira ancora sugli stessi input non tracciati del primo giorno, il codice è diventato più raffinato, i dati sottostanti non sono mai stati verificati.

L’errore è trattare questo come un problema di qualità di costruzione. Non lo è. Una dashboard splendidamente progettata sopra un’esportazione CSV non riconciliata resta comunque una supposizione splendidamente progettata.

Perché “riscriverlo semplicemente per bene” è l’istinto sbagliato

L’istinto immediato, una volta che qualcuno nota che uno strumento vibe-coded è diventato portante, è affidarlo all’ingegneria per una riscrittura. Di solito è eccessivo e uccide proprio ciò che rendeva prezioso lo strumento: un analista può descrivere una modifica in una frase e vederla dal vivo in pochi minuti. Forzare questo attraverso un ciclo di sprint e lo strumento smette di essere mantenuto, il che è a sua volta un rischio, ora c’è uno strumento obsoleto e non mantenuto di cui le persone continuano a fidarsi per abitudine.

La logica dello strumento non è mai stata davvero il problema. È leggibile, è veloce da cambiare, e l’LLM è bravo esattamente in questo tipo di impalcatura. Ciò che manca sta al di sotto: qualcosa che garantisca che i numeri con cui lo strumento viene alimentato si ricollegano davvero al registro contabile, al CRM o al warehouse, ovunque viva la cifra reale, invece di uno snapshot che qualcuno ha esportato tre settimane fa e dimenticato. Sostituite la fonte dati, non lo strumento. L’app vibe-coded mantiene il suo ciclo di iterazione di cinque minuti; il numero che sta rappresentando smette di essere una sensazione.

Questa è un’affermazione più circoscritta di “ricostruite il vostro stack dati”, ed è importante che resti circoscritta. Gran parte di ciò che questi strumenti calcolano (un tasso di churn, un margine, una segmentazione per coorte) è un’aggregazione diretta una volta che gli input sono affidabili. La parte difficile non è mai stata l’aritmetica. È sapere che il numero in ingresso è quello reale e non una copia obsoleta, che è esattamente il problema trattato più a fondo in perché un foglio di calcolo è la base sbagliata per l’IA finanziaria, lo stesso meccanismo di errore silenzioso, solo con un foglio di calcolo come input di fiducia invece di un’app vibe-coded.

Cosa significa “sotto, non al posto di” nella pratica

Concretamente, uno strumento vibe-coded ha bisogno di un’unica cosa aggiunta, non sostituita: una query che possa fare, in fase di costruzione o di esecuzione, che restituisca un numero legato a una fonte invece di qualunque cosa sia seduta in un file locale. Questa è la forma della soluzione, non una nuova interfaccia, non una migrazione, una connessione.

È qui che il ruolo di Rexfin nello stack è specifico. Rexfin riconcilia i dati contabili, bancari e di warehouse in un unico modello che quadra con il registro contabile, ed espone il tutto tramite MCP, così uno strumento vibe-coded non ha bisogno di una propria pipeline dati, un analista non deve fidarsi di un incollato di tre settimane fa, e l’LLM che scrive la logica dello strumento può prelevare “MRR attuale” o “margine lordo, ultimo trimestre” da una fonte che può mostrare il proprio lavoro. Lo strumento continua a essere costruito in un pomeriggio. Il numero che mostra ora ha una citazione dietro invece di un’ipotesi.

È anche per questo che la soluzione non si riduce a “lasciate semplicemente che l’interprete di codice lo calcoli correttamente”, un calcolatore deterministico risolve l’aritmetica, non la provenienza di ciò che viene calcolato. Perché “usare semplicemente un interprete di codice” non rende l’IA finanziaria sicura affronta direttamente questa lacuna: una matematica corretta su un input sbagliato o non tracciabile resta comunque una risposta sbagliata, solo una che si è calcolata in modo pulito lungo il percorso.

La conclusione

Il vibe coding non ha introdotto un nuovo rischio in finanza, ha reso più veloce uno vecchio. I team hanno sempre costruito fogli di calcolo estemporanei e strumenti occasionali su dati che nessuno riverificava; la differenza ora è che un LLM può crearne uno in pochi minuti e sembra abbastanza rifinito da fidarsene per default. La soluzione non è rallentare la costruzione degli strumenti. È assicurarsi che qualunque cosa venga costruita, a qualunque stadio di maturità, attinga numeri da qualcosa di riconciliato invece che da qualcosa di esportato.

Se il vostro team sta già facendo vibe coding di strumenti finanziari interni, e la maggior parte lo fa, ufficialmente o no, la domanda che vale la pena porsi è da dove quegli strumenti prendano i loro numeri, e se qualcuno potrebbe ricollegarne uno alla fonte su richiesta. Per il pattern più ampio dell’IA che produce cifre sicure e non tracciate in finanza, vedete il pilastro sulle allucinazioni dell’IA nei dati finanziari. Per vedere come si presenta un livello di base interrogabile e riconciliato sui vostri dati, prenotate una demo.