Da vibe coding a AI4Code: come smettere di sperare e iniziare a costruire

Nell'ultima settimana ho letto due commenti, sotto due post diversi, scritti da due persone che non si conoscono.

Uno, un senior developer, diceva che nello sviluppo assistito da AI la cosa più importante non è lo strumento ma avere qualcuno che orchestra: mantiene la coerenza del codice, valida sicurezza e compliance. E precisava: questo non è vibe programming.

L'altro, un AI engineer, lo chiudeva così: il vibe coding beneficia chi sa cosa sta facendo.

Due angoli diversi. Stessa identica tesi.

Non "chi ha lo strumento migliore".

Chi sa cosa sta facendo.

Se hai passato gli ultimi mesi a generare codice con l'AI e a sperare che funzioni, questo articolo è per te. Non per farti sentire in colpa. Per darti la mappa che porta dall'altra parte.

🤨​ La differenza in una riga

Nel vibe coding chiedi e speri.

Nell'AI4Code chiedi, guidi e verifichi.

Sembra una sfumatura. È un abisso.

Il vibe coding delega il pensiero al modello. Descrivi vagamente cosa vuoi, il modello riempie i buchi con le sue assunzioni, e tu accetti il risultato perché gira in demo.

L'AI4Code delega solo l'esecuzione. Il pensiero, l'architettura, i vincoli, i controlli restano tuoi. L'AI diventa un esecutore velocissimo di decisioni che hai già preso tu.

La prova più chiara di questa differenza sta in due prompt.

🎯​ Due prompt, stesso obiettivo, due mondi

Prendi un caso banale: un'app per gestire delle foto.

Ecco come lo chiede chi fa vibe coding: "Fammi un'app per gestire le foto."

Ed ecco come lo chiede chi fa AI4Code: "Realizza un'app web per gestire foto. Frontend in React, backend in Go, storage secondo standard S3 su AWS. Tra backend e storage inserisci un database di appoggio. In fase di scrittura attieniti a KISS e SOLID, preferendo implementazioni semplici a soluzioni sofisticate. Scrivi unit test sul backend con coverage minima all'80%. Se non sai come implementare qualcosa, chiedi. Non prendere iniziative."

Stesso obiettivo. Stesso identico modello dietro.

Due risultati che non hanno niente in comune.

Guarda cosa contiene il secondo prompt. Non è più lungo per vezzo. Ogni riga è una decisione tecnica: quale architettura, quali linguaggi, quale pattern di storage, quali principi di scrittura, quale soglia di test, quale comportamento in caso di dubbio.

Il primo prompt spera che il modello indovini tutto questo.

Il secondo glielo detta.

E qui c'è il punto che quasi nessuno capisce: per scrivere il secondo prompt devi già sapere cosa sono SOLID e KISS, perché uno storage S3 ha senso, cosa vuol dire coverage all'80%. Il prompt è una specifica tecnica. Se non sai scrivere una specifica, non è l'AI il problema.

🛣️​ Il percorso: come ci arrivi davvero

Passare da un prompt all'altro non è questione di imparare "il prompt giusto". Non esiste una formula da copiare. Esiste un percorso da fare. Cinque fasi.

Fase 1. Studia i fondamentali, non i framework

I framework scadono. Le basi no.

Prima dell'ultima libreria uscita ieri, assicurati di sapere:

• come si struttura un'architettura e perché si separano le responsabilità
• cosa significano davvero SOLID, KISS, DRY, oltre l'acronimo
• come funziona un database sotto il cofano: indici, query, transazioni
• cosa succede in una richiesta HTTP, dal client alla risposta

L'AI scrive il codice al posto tuo. Ma se non sai leggerlo, non hai idea di cosa stai mandando in produzione.

Il codice che non capisci non è tuo. È un debito che hai contratto senza accorgertene.

Fase 2. Impara a chiedere

Un prompt vago produce codice vago. Sempre.

Smetti di scrivere "fai un'app" e inizia a specificare: architettura, linguaggio, vincoli, pattern, test, comportamento nei casi dubbi.

Tratta il prompt come un ticket dettagliato per un collega junior molto veloce ma senza contesto. Cosa deve sapere per non sbagliare? Scrivilo.

Più sai, più il tuo prompt diventa denso di decisioni. E più decisioni prendi tu, meno ne prende il modello a caso.

Fase 3. Orchestra, non delegare

Il vibe coder chiede tutta l'app in un colpo solo e aspetta il miracolo.

Il costruttore spezza il problema.

Un modulo alla volta. Prima l'architettura, poi il layer dati, poi la logica, poi l'interfaccia. Decidi tu l'ordine, i confini di ogni pezzo, le responsabilità.

Sei tu l'architetto. L'AI è la squadra che esegue. Un architetto che dice "costruitemi una casa" e torna dopo sei mesi non è un architetto. È un committente distratto. Orchestrare significa tenere in testa il disegno completo mentre l'AI lavora sui dettagli.

Fase 4. Verifica sempre

Il codice che gira non è il codice corretto. Ripetitelo finché non diventa un riflesso.

Un'app può funzionare perfettamente nella demo e crollare al primo utente vero, al primo dato sporco, al primo caso limite che non avevi considerato.

Cosa vuol dire verificare, in pratica:

• leggi ogni riga che accetti, non fare merge di codice che non capisci
• scrivi i test tu, o quantomeno leggi quelli che l'AI ha scritto e chiediti se testano davvero qualcosa
• controlla i casi limite, non solo il percorso felice
• chiediti sempre: e se gli utenti fossero diecimila invece di dieci?

La verifica è il momento in cui la tua competenza vale di più. È lì che si vede la differenza tra chi sa e chi ha solo generato.

Fase 5. Debugga da ingegnere

Quando qualcosa si rompe, come reagisci?

Il vibe coder scrive al modello: "non funziona".

Il costruttore isola il problema, fa un'ipotesi, e dà una pista: "l'errore compare dopo l'upload, credo sia la gestione delle credenziali S3, controlla lì".

Al modello serve una direzione, non un lamento. Più il tuo debug è preciso, più la correzione sarà chirurgica. E per essere preciso devi avere un'idea di dove possa nascondersi il problema. Che è esattamente ciò che ti danno i fondamentali della Fase 1.

Il cerchio si chiude. Tutto parte da lì.

🏋️‍♂️​ Come ti alleni concretamente

Le cinque fasi sono la mappa. Ma la mappa non ti allena. Serve pratica deliberata:

Riscrivi a mano il codice generato. Prendi qualcosa che l'AI ha prodotto e riscrivilo tu, meglio. All'inizio ci metterai il triplo. È il punto.

Leggi codice di chi è più bravo. Progetti open source seri. Leggere buon codice è come leggere buoni autori: ti cambia il modo di scrivere.

Fai code review dei tuoi prompt. Cosa hai lasciato decidere al modello? Quelle sono le tue lacune. Colmale.

Un fondamentale nuovo a settimana. Non un tool. Un concetto: come funziona un garbage collector, cosa fa un load balancer, perché esistono gli indici. Accumula comprensione, non icone sulla barra degli strumenti.

⚡​ Il punto che conta

L'AI non colma la distanza tra te e ciò che non sai. La espone. Più in fretta di prima.

Se sotto non c'è competenza da amplificare, con l'AI generi soltanto il tuo prossimo problema in metà del tempo. Codice che sembra giusto, che gira in demo, che accumula debito invisibile fino al giorno in cui presenta il conto.

Il vibe coding ti dà velocità.

L'AI4Code ti dà velocità sotto controllo.

La differenza non è quanto codice produci. È quanto ne capisci.

Ed è per questo che quei due commenti dicevano la stessa cosa senza essersi mai parlati. Non è un'opinione. È come funziona lo strumento.

L'AI è un amplificatore.

La domanda vera non è "so usarla".

È: ho qualcosa da amplificare?

La comfort zone, in questo mestiere, ha ormai una data di scadenza. Meglio scoprire adesso da che parte del confine ti trovi.