Prendi due persone con lo stesso strumento e lo stesso modello di intelligenza artificiale. La prima scrive una frase, accetta tutto quello che riceve e va avanti così. La seconda, prima di chiedere qualcosa, decide cosa vuole costruire; alla fine controlla che il risultato sia quello giusto.
Lo strumento è lo stesso. I risultati, dopo qualche settimana di lavoro, no.
In questo articolo racconto dove sta la differenza, cosa resta compito delle persone e come lavoriamo noi in microPP quando sviluppiamo software con gli agenti AI.
Che cos'è il vibe coding
Il termine l'ha usato per la prima volta Andrej Karpathy, in un post del 2 febbraio 2025: un modo di programmare in cui ti lasci andare e "dimentichi che il codice esista". Dici all'AI cosa vuoi, lei scrive il codice, tu non lo guardi e provi se funziona; se non funziona, le chiedi di sistemare.
Simon Willison lo riassume così: vibe coding è costruire software con un'AI senza rivedere il codice che produce.
Per un prototipo o un esperimento del fine settimana funziona, ed è anche divertente. Il problema nasce quando lo stesso approccio viene usato per un software su cui contano altre persone: clienti, colleghi, utenti.
Bisogna rileggere il codice scritto dall'AI?
È la domanda che ricorre più spesso, e le risposte autorevoli non coincidono:
- Simon Willison non fa commit di codice che non saprebbe spiegare a un'altra persona.
- Andrej Karpathy osserva che nel lavoro con l'AI di solito l'AI genera e l'umano verifica, quindi la verifica deve essere veloce.
- Salvatore Sanfilippo (antirez), il creatore di Redis, scrive: controlla le idee, non il codice.
La mia esperienza va nella direzione di antirez. Un anno fa leggevo tutto e correggevo; oggi i modelli sono migliorati e leggere ogni riga mi rallenta e basta. Funziona come in un'azienda che cresce: chi la guida non conosce più ogni singola azione, ma conosce il piano, il senso e le motivazioni delle scelte.
C'è però una condizione: se non leggo il codice, devo avere un altro modo serio per controllarlo. Ci arrivo tra poco.
Cosa resta compito dell'umano: specifiche e scelte
Per delegare così bisogna saper programmare. Il motivo è semplice: l'AI tende a proporre per prima la scelta più familiare, quella più diffusa. Spesso va bene, ma non sempre è la migliore per quel progetto. Chi ha la visione d'insieme e conosce architettura e design la riconosce e la scarta; chi non ha queste competenze si tiene la scelta familiare, e spesso non se ne accorge.
Una ricerca su otto modelli va nella stessa direzione: senza contesto, i modelli privilegiano librerie e linguaggi popolari rispetto a quelli più adatti. Misura librerie e linguaggi, non l'architettura, quindi la cito come un'indicazione, non come una prova.
Due esempi da BlockLog, un'app che stiamo sviluppando per una palestra di arrampicata (backend in Go, una parte in Python che riconosce le prese sulla parete con l'AI, app in Flutter):
- Il login. L'app doveva avere un solo accesso con la scelta del ruolo: chi arrampica o chi traccia i percorsi. Il mockup lo mostrava. L'AI ha deciso che le app fossero due. La mia specifica era ambigua, e il modello ha riempito il vuoto a modo suo.
- Le prese. Avevo chiesto di evidenziare le prese di un blocco mettendo la parete in grigio e le prese a colori. Il modello ha lasciato la parete a colori e ha coperto le prese con quadrati gialli uniti da una linea tratteggiata. Ha seguito l'idea, non l'implementazione richiesta.
In entrambi i casi me ne sono accorto guardando gli screenshot di un flusso d'uso, non leggendo il codice.
Come lavoriamo: il ciclo con gli agenti
Con BlockLog abbiamo affidato lo sviluppo agli agenti, ma non con un singolo comando:
- Definizione dell'app a partire dall'idea.
- Discussione dell'architettura con l'AI, da pari: funziona se arrivi preparato e sai già dove vuoi andare.
- Una ventina di passi, ognuno chiuso da una verifica nell'emulatore con screenshot.
- Checkpoint in cui provo l'app di persona e propongo correzioni.
Non usiamo lo stesso modello per tutto: lo scegliamo in base alla difficoltà del compito, perché ogni modello ha un costo reale. Un agente coordina il lavoro, un altro tiene aggiornata la documentazione del progetto, l'implementazione la fa il modello più adatto a quel compito.
Come verifichiamo senza rileggere il codice
Tre livelli, dal più importante:
- Prove sul comportamento. L'agente usa l'app nell'emulatore come farebbe una persona e salva gli screenshot di ogni passaggio; poi la proviamo noi. È così che sono emersi i due episodi di BlockLog.
- Test, controllati a loro volta. Il codice Go ha i suoi test, ma l'AI tende a scrivere test che passano sempre. Per questo li verifichiamo con il mutation testing: si introducono piccole modifiche nel codice e si controlla che i test se ne accorgano. Anche le ricerche recenti indicano che i test scritti dai modelli possono avere una buona copertura ma trovare pochi difetti.
- Review incrociate. Il codice viene rivisto da modelli di famiglie diverse da quella che l'ha scritto, perché hanno punti ciechi diversi. È un aiuto, non una garanzia: i modelli tendono a preferire i propri output, ma i modelli migliori sbagliano spesso nello stesso modo anche tra fornitori diversi. La verifica vera resta quella sul comportamento.
Vibe coding o programmare con l'AI? Cinque domande per capirlo
- Ho scritto le specifiche, o ho solo descritto un'idea vaga?
- Come verifico il risultato?
- Chi lo verifica?
- Saprei riconoscere una scelta solo familiare e scartarla?
- Cosa delego, e a quale modello?
Se non sai rispondere, sei più vicino al vibe coding di quanto pensi. Non è un problema per un prototipo; lo è per un software su cui contano altre persone.
In sintesi: specifiche all'inizio, perché è lì che l'AI riempie i vuoti a modo suo; prove alla fine, perché è lì che scopri cosa è successo davvero; e competenza da sviluppatore in mezzo, per scartare la scelta ovvia e arrivare a quella giusta.
Stai pensando a un software su misura e vuoi capire come l'AI può accorciare i tempi senza rinunciare alla qualità? Raccontaci il tuo progetto: ti rispondiamo entro 24 ore.
Le ricerche citate sono indicazioni che vanno nella stessa direzione della mia esperienza, non prove definitive.