In questo articolo
- Che cos'è il vibe coding secondo la SDAIA?
- La regola chiave: ciò che produce l'IA è una bozza
- 4 rischi indicati dalla guida e come si presentano nel tuo progetto
- 6 cose che l'IA non garantisce
- 5 controlli umani prima che il codice arrivi ai tuoi clienti
- Domande da fare al tuo sviluppatore o fornitore questa settimana
- Il punto di vista di Origami
- Fonti
Se la tua app, il tuo sito o il tuo sistema interno è stato costruito con strumenti di IA, o se il tuo sviluppatore li usa, la guida «Vibe Coding» pubblicata dall'Autorità saudita per i dati e l'intelligenza artificiale (SDAIA) ad aprile 2026 fissa una regola chiara: tutto ciò che l'IA genera è una bozza non approvata finché una persona non l'ha rivista, verificata e approvata formalmente. La guida conta 57 pagine, si rivolge ai team tecnici della pubblica amministrazione e del settore privato, indica 4 rischi principali e 6 limiti fondamentali, e stabilisce 5 punti in cui una persona deve intervenire prima che il codice arrivi ai tuoi clienti. In questo articolo la trasformiamo in domande pratiche da porre al tuo team o al tuo fornitore questa settimana.
Che cos'è il vibe coding secondo la SDAIA?
La guida definisce il vibe coding (in arabo «al-barmaja al-tawlidiya», programmazione generativa) come un approccio in cui l'utente descrive ciò che vuole in linguaggio comune e gli strumenti di IA scrivono il codice. Va oltre la scrittura, fino a quella che chiama IA agentica: strumenti che costruiscono il codice, eseguono i test e gestiscono il deploy da soli, mentre una persona guida le decisioni chiave.
La guida divide l'uso in 3 ambiti: design ed esperienza utente (idee e prototipi), programmazione (scrivere e migliorare il codice) e test (piani di test, dati di test e analisi dei guasti). Cita Microsoft, secondo cui questi strumenti generano circa il 30% del codice prodotto internamente, e Google, secondo cui circa il 25% del suo nuovo codice è generato dall'IA e poi rivisto da persone prima del merge. Il messaggio è chiaro: le più grandi aziende usano questi strumenti ogni giorno, ma all'interno di un sistema di revisione.
La regola chiave: ciò che produce l'IA è una bozza
La prima definizione della guida è la «bozza generata dall'IA»: qualunque output del sistema resta una prima bozza non approvata finché non passa per revisione umana, verifica e approvazione. Descrive il principio «Human-in-the-loop» (la persona nel ciclo) come un principio di governance obbligatorio all'interno del suo metodo. E aggiunge che l'intervento umano diventa obbligatorio quando agli strumenti di IA vengono dati permessi di esecuzione che possono avere un impatto operativo, legale o commerciale rilevante.
Detto da imprenditore: se uno strumento di IA può pubblicare un aggiornamento della tua app o modificare il tuo database clienti senza che nessuno approvi, è esattamente ciò da cui la guida mette in guardia. Per chiarezza, la guida è di indirizzo, non una norma con sanzioni, ma è finora il riferimento ufficiale saudita più chiaro su cosa sia un «uso responsabile» di questi strumenti, e completa il Quadro nazionale per la gestione dei rischi dell'IA.
4 rischi indicati dalla guida e come si presentano nel tuo progetto
- Allucinazione: codice che sembra corretto ma chiama API inesistenti, o consiglia pacchetti e librerie inventati o non supportati. Il risultato sono errori di integrazione con gli altri sistemi e, forse, una falla di sicurezza se qualcuno installa per nome un pacchetto suggerito senza verificarlo.
- Eccesso di fiducia: accettare codice generato senza revisione di sicurezza o funzionale, o portarlo direttamente nell'ambiente di produzione usato dai tuoi clienti.
- Copertura superficiale: un'analisi di sicurezza generica che lascia passare vulnerabilità, e test incompleti, che danno la falsa sensazione che vada tutto bene.
- Risultati non deterministici: lo stesso prompt produce codice diverso ogni volta, rendendo i risultati difficili da riprodurre e da verificare.
6 cose che l'IA non garantisce
La guida elenca 6 limiti fondamentali: l'IA capisce l'intento della tua attività solo nella misura in cui lo hai messo per iscritto; non sa valutare i rischi o le priorità specifici della tua organizzazione; non sostituisce il pensiero architetturale né le decisioni di progettazione; non garantisce che il codice sia corretto o adatto all'uso reale; non produce sempre risultati identici; e i suoi output non sono né una prova formale di test né un sostituto dei test reali. La guida lo dice chiaramente: la responsabilità di verifica, test e approvazione è «interamente umana».
5 controlli umani prima che il codice arrivi ai tuoi clienti
- Rivedere ogni modifica al codice prima del merge nel branch principale.
- Valutare se ogni rilascio è pronto prima del deploy.
- Supervisionare la decisione di fare il deploy o il rollback.
- Spiegare qualsiasi comportamento inatteso in produzione.
- Approvare i piani di sviluppo e la roadmap tecnica di lungo periodo.
Domande da fare al tuo sviluppatore o fornitore questa settimana
- Chi rivede il codice scritto dall'IA prima del merge, ed esiste una revisione registrata per ogni modifica?
- I test vengono davvero eseguiti sul sistema, o lo strumento ha semplicemente «detto» che il codice funziona?
- Che permessi hanno gli strumenti di IA? Possono fare il deploy o accedere al database reale? (Guarda cosa è successo con gli agenti di programmazione che hanno eseguito il comando di un attaccante.)
- I dati di test sono sintetici? La guida chiede dati di test conformi alle regole sulla privacy che escludano l'uso di qualsiasi dato reale o sensibile, un punto importante per i dati personali dei tuoi clienti.
- Chi approva un rilascio prima che vada online, e chi decide il rollback se qualcosa si rompe?
Se non ottieni una risposta chiara a tre di queste cinque domande, il problema non è lo strumento di IA ma il modo di lavorare. Se stai scegliendo un nuovo partner di sviluppo, aggiungi queste domande ai tuoi criteri per scegliere una software house.
Il punto di vista di Origami
Usiamo strumenti di IA nel design, nella programmazione e nei test perché fanno risparmiare tempo reale ai nostri clienti. Ma trattiamo ciò che scrivono esattamente come lo descrive la guida della SDAIA: come una bozza. Ogni modifica passa per la revisione di uno sviluppatore, i test vengono davvero eseguiti, i dati reali dei clienti non entrano mai nell'ambiente di test e la decisione del deploy la prende una persona. La velocità senza revisione si paga dopo, in disservizi e falle di sicurezza. Se hai costruito un prototipo con l'IA e vuoi trasformarlo in un sistema su cui i tuoi clienti possano contare, parliamone.
Fonti
Domande frequenti
La guida vibe coding della SDAIA è vincolante per la mia azienda?
La guida è di indirizzo, non una norma con sanzioni, ed è rivolta ai team tecnici della pubblica amministrazione e del settore privato. Resta comunque il riferimento ufficiale saudita più chiaro sull'uso responsabile degli strumenti di programmazione con IA, e descrive la revisione umana come un principio di governance obbligatorio all'interno del suo metodo.
Posso creare un'app completa con l'IA e senza sviluppatore?
Puoi creare un prototipo rapido per verificare un'idea. Per un sistema da cui dipendono i tuoi clienti, la guida afferma che l'IA non garantisce che il codice sia corretto o adatto all'uso, e che la responsabilità di verifica, test e approvazione è interamente umana: ti serve uno sviluppatore che lo rivede prima del lancio.
Qual è il rischio più grande del codice scritto dall'IA?
La guida indica 4 rischi: l'allucinazione, come suggerire librerie o API che non esistono; l'eccesso di fiducia, portando il codice in produzione senza revisione di sicurezza; la copertura superficiale di analisi e test; e risultati che cambiano ogni volta.
Come mi assicuro che il mio sviluppatore riveda il codice generato dall'IA?
Chiedigli dei 5 punti di controllo della guida: rivedere ogni modifica prima del merge, valutare se il rilascio è pronto, approvare il deploy o il rollback, spiegare i comportamenti inattesi e approvare il piano di sviluppo. Chiedi che revisioni e test siano registrati, non solo promessi.
