La demo non mostra mai questa parte. Uno strumento di vibe coding genera in un solo prompt un pulsante ben fatto “Collega il tuo Google Calendar”, e sembra finito. Quello che la demo salta è tutto ciò che sta tra il clic su quel pulsante e la sincronizzazione effettiva del calendario: un’applicazione sviluppatore registrata nella console del provider, credenziali OAuth configurate, redirect URI impostati e, in alcuni casi, un passaggio di verifica del dominio che non ha nulla a che fare con la logica della tua app e tutto a che fare con dimostrare che possiedi il dominio su cui stai costruendo.
Questa è la parte del vibe coding per cui non esiste alcun prompt. Non puoi descriverti la via per evitarla, perché il provider (Google, Slack, Stripe, chiunque sia) richiede a un builder solo gli stessi passaggi di registrazione che richiede a un intero team di ingegneri.
Cosa richiede davvero “collega il tuo calendario”
Per un’integrazione come Google Calendar non esiste una API key che puoi semplicemente incollare in un campo di configurazione. Il codice generato ha bisogno di un’identità reale, registrata presso il provider, prima di poter chiedere a chiunque di autorizzare qualcosa. In pratica questo significa:
- Creare un’applicazione sviluppatore nella console del provider (Google Cloud Console, la dashboard delle app di Slack, il portale sviluppatori di Stripe).
- Configurare le credenziali OAuth per quell’applicazione: un client ID e un secret che identificano la tua app presso il provider.
- Impostare i redirect URI che corrispondano esattamente al punto in cui il provider deve rimandare l’utente dopo l’autorizzazione, fino al protocollo e alla barra finale.
- Superare la verifica del dominio, laddove il provider richiede la prova che controlli il dominio su cui l’app viene eseguita prima di concedere un accesso di livello produzione.
- Selezionare e richiedere gli scope, i permessi specifici che l’app sta chiedendo, che vengono verificati (a volte dal provider, a volte semplicemente da chi sta costruendo l’app in fretta).
Niente di tutto questo è logica applicativa. È amministrazione di account sulla piattaforma di qualcun altro, e va fatta correttamente prima che un solo evento di calendario possa apparire nell’interfaccia generata.
Due modi di sbagliare gli scope, entrambi negativi
Gli scope sono il punto in cui questo smette di essere semplicemente noioso e diventa rischioso. Sbagliare in una direzione o nell’altra produce un fallimento completamente diverso.
Troppi scope è il fallimento di sicurezza. Richiedere accesso completo a Drive quando la funzionalità aveva bisogno solo di eventi Calendar in lettura non è una scorciatoia, è un rischio permanente: ogni file di quell’account diventa ora raggiungibile tramite una credenziale che l’app non aveva bisogno di toccare. Resta lì, silenzioso, finché un giorno un token non viene trafugato o una sessione compromessa, e a quel punto il raggio del danno è l’intero scope concesso, non la funzionalità effettivamente costruita. È lo stesso tipo di problema del 45% di codice generato dall’IA con vulnerabilità di classe OWASP: il codice funziona bene e fa una demo perfetta mentre l’esposizione resta sotto, invisibile finché qualcosa non va storto.
Troppo pochi scope è la modalità di fallimento silenziosa. Manca un solo scope richiesto e l’integrazione non lancia un errore chiaro, semplicemente smette di funzionare in un modo difficile da diagnosticare. Una sincronizzazione del calendario che non restituisce nulla, una notifica Slack che non viene mai inviata, un webhook Stripe che si attiva ma il cui handler non riesce a leggere il campo di cui ha bisogno. Un builder non tecnico che fissa un risultato vuoto non ha modo di sapere se il bug è nel codice generato, nella configurazione degli scope o dal lato del provider, e l’IA non può ispezionare la concessione OAuth per dirglielo.
Ottenere l’elenco esatto degli scope, e verificarlo di nuovo ogni volta che l’insieme delle funzionalità cambia, è una competenza specifica e ristretta. Non è coperta dal prompting “descrivi cosa vuoi”, perché l’IA che genera il codice di integrazione non controlla ciò che la console del provider autorizzerà davvero.
Dove finiscono per vivere le credenziali
Una volta che il balletto OAuth funziona, il client ID, il secret e qualsiasi token di accesso risultante devono vivere da qualche parte. Quel “qualche parte” è una vera decisione architetturale, non un dettaglio. Testare l’integrazione in locale significa che l’app ha bisogno di variabili d’ambiente che puntino a credenziali reali, e i builder non tecnici che non sanno gestire correttamente i file .env finiscono regolarmente per scrivere quei valori direttamente nel codice, in modo fisso. I secret scritti in modo fisso nel codice che finiscono per essere spinti per errore in un repository pubblico di GitHub capitano con una frequenza tale da essere una modalità di fallimento documentata e riconosciuta di tutta la categoria, non un errore raro. Una volta che un secret entra nella storia di un repository pubblico, ruotarlo e confermare che nessuno ha sfruttato quella finestra è un lavoro di pulizia a parte, oltre all’integrazione che si stava cercando di consegnare.
Idraulica, non prodotto
Vale la pena chiamarlo con il suo nome: lavoro infrastrutturale, non la funzionalità che si stava cercando di costruire. Nessuno si sveglia con la voglia di configurare un redirect URI. Il bisogno di business era “mostra i prossimi appuntamenti del cliente” oppure “avvisa il team su Slack quando un affare si chiude”. La console OAuth, l’elenco degli scope e la conservazione delle credenziali sono il costo inevitabile per arrivarci su una piattaforma in cui ogni integrazione viene costruita da zero, e crescono in base al numero di servizi terzi che l’app tocca, non in base a quanto rifinita appare la funzionalità.
È esattamente in questo ambito che una piattaforma come Softr è lo strumento giusto per il lavoro, non un ripiego. I suoi connettori nativi per Google Calendar, HubSpot, Stripe e strumenti business simili sono applicazioni OAuth pre-verificate e già approvate: un builder autorizza il proprio account in un flusso di login, e gli scope e la conservazione delle credenziali vengono gestiti lato server, completamente fuori dal client, perché Softr ha già fatto la registrazione in console una volta per tutti. Ma per un portale clienti o uno strumento interno il cui compito è per lo più “sincronizza un calendario e pubblica su Slack”, la tassa dell’integrazione è il tipo di idraulica che costa meno acquistare come infrastruttura di piattaforma che reinventare progetto per progetto.
Questo scambio smette di avere senso nel momento in cui l’integrazione stessa è il prodotto. Se stai collegando un provider per cui nessuno ha un connettore, o hai bisogno di controllo sul refresh dei token e sulla gestione degli errori, vuoi possedere il flusso OAuth invece di ereditare quello di qualcun altro. Questo è lavoro da sviluppatore, e appartiene agli strumenti per sviluppatori: Cursor dentro una vera codebase dove puoi leggere cosa fanno davvero le credenziali, oppure Replit dove le variabili d’ambiente e la gestione dei secret sono di prima classe invece di essere aggiunte dopo. Nessuno dei due elimina la registrazione in console, perché niente lo fa. Ti mettono solo nella posizione di impostare gli scope correttamente in modo deliberato, invece di scoprirli per tentativi ed errori.
Il loop dei fix peggiora questo nel tempo, non lo migliora. Ogni aggiustamento di scope o nuova integrazione è un altro giro di configurazione in console, un altro redirect URI da impostare esattamente, e un’altra occasione per concedere troppo o troppo poco. È un costo che si accumula a ogni funzionalità aggiunta, che è esattamente la forma del problema del Giorno Due: l’app che ha fatto una demo impeccabile il primo giorno continua a generare nuovo lavoro di idraulica ogni volta che cresce.