Vibe coding con architettura: il workflow che usiamo davvero

"Vibe coding" è diventata una parolaccia in molti circoli tecnici, ed è un peccato. La definizione caricaturale (chiedi qualcosa al modello, accetti l'output, vai avanti) è facile da deridere. Ma c'è un modo serio di lavorare insieme all'AI che assomiglia molto al vibe coding nella forma, e zero al vibe coding nei risultati. È quello che facciamo noi.

La differenza non è quanto codice scrive l'AI rispetto a noi. La differenza è dove finisce il nostro tempo.

Il cambio mentale

Per anni il lavoro di chi sviluppa è stato dominato dalla scrittura di codice. Loop, branching, glue code, mappature, validazioni, parsing, conversioni di tipo: ore al giorno spese a tradurre intenzioni in sintassi. L'AI oggi sa fare quella traduzione molto bene, sui task in cui ha contesto e vincoli chiari.

Il punto non è "l'AI accelera il mio lavoro di scrittura". Il punto è che il lavoro di scrittura del codice di routine non è più il collo di bottiglia. Quel tempo lo possiamo finalmente spendere su cose che prima saltavamo o riducevamo per arrivare a fine sprint:

• Architettura: capire dove vivono le boundary, che accoppiamenti accettiamo, dove serve flessibilità.
• Performance: profilare prima, non dopo. Decidere cosa cacheare, cosa indicizzare, cosa lazy-loadare.
• Sicurezza: threat model serio, hardening degli endpoint, gestione delle credenziali, audit dei permessi.
• Validazione: schema espliciti, eval set, test di integrazione su scenari reali.

Questa è la parte che fa la differenza fra un sistema che regge e un sistema che si rompe in produzione.

Come è fatta una giornata tipo

Senza romanticizzare nulla, una sessione di lavoro reale assomiglia a questo:

1. Apertura del task. Discovery del problema con chi lo porta, allineamento sulle aspettative, prima ipotesi di approccio.
2. Scrittura della direttiva. Cosa deve fare il modulo, quali input, quale output, quali vincoli. Pochi minuti, ma scritti.
3. Sessione con Claude Code. L'AI legge il repo, propone il piano, scrive il primo draft. Noi guardiamo, chiediamo modifiche, indirizziamo.
4. Review umana. Letta riga per riga. Si guarda l'errore di logica nascosto, l'edge case dimenticato, il pattern dissonante con il resto del codice.
5. Test ed eval. Unit test sui contratti, eval set se è un componente AI, prove di carico quando ha senso.
6. Hardening. Validazione input, gestione errori, rate limit, sanitizzazione output, log strutturati.
7. Architettura. Domanda finale: questo modulo si incastra bene con il resto? Avremo problemi quando crescerà di un ordine di grandezza?

I punti 1, 2, 4, 5, 6, 7 sono nostri. Il punto 3 è sempre più dell'AI. È esattamente la ridistribuzione di tempo di cui parlavamo.

Cosa NON deleghiamo all'AI

Per chiarezza assoluta, ci sono cose che non lasciamo decidere all'AI, mai:

• Scelte di stack. Costo, rischio, manutenibilità a 3 anni: decisioni da prendere con il cliente, non con un modello.
• Threat model. Capire chi attacca cosa e perché richiede contesto di business che l'AI non ha.
• Trade-off architetturali. CAP, consistency vs availability, accoppiamento vs autonomia: trade-off che vanno discussi e firmati.
• Decisioni irreversibili. Migrazione di schema in produzione, scelte di pricing, contratti API pubbliche. L'AI propone, noi decidiamo.

L'AI è bravissima a generare codice all'interno di vincoli chiari. È pessima a stabilire quei vincoli al posto tuo, perché non ha skin in the game.

Lo strumentario

Per chi lavora così, lo stack quotidiano è abbastanza definito:

• Claude Code in CLI per le sessioni lunghe sul repo. Permessi granulari, checkpoint, review dei diff prima dell'apply.
• Direttive in markdown committed accanto al codice, come spec viva.
• Eval set in CI per ogni componente AI, baseline misurabile.
• Pre-commit hook standard (lint, typecheck, test) e mai bypassati.
• PR review umana anche su codice generato. Soprattutto su codice generato.

Niente di magico. Strumenti normali, applicati con disciplina. Quel che è cambiato è la quantità di codice che può uscire da una sessione, e di conseguenza la quantità di lavoro architetturale che possiamo permetterci nel tempo restante.

Quando il vibe coding diventa un problema

Lo diventa quando:

• Si accetta codice che non si è capito. Sempre, senza eccezioni.
• Si salta l'eval perché "tanto sembra funzionare".
• Si lascia decidere all'AI dove finisce il modulo, dove inizia il prossimo, come si parlano fra loro.
• Si ottimizza per produrre codice in fretta invece che per produrre sistemi che reggono.

Sono tutte abitudini che si possono evitare, se si è onesti con se stessi su cosa l'AI sa fare bene e cosa no.

La misura della differenza

Il vero indicatore se il workflow funziona o no non è quanto codice produci in un giorno. È cosa succede al sistema sei mesi dopo. Se il debito tecnico è sotto controllo, se le evolutive non rompono nulla, se l'on-call è tranquillo, se chi eredita il codice riesce a leggerlo: il workflow funziona.

Vibe coding con architettura significa esattamente questo: usare l'AI come strumento serio in mano a chi sa già dove sta andando. Senza quel "dove", il codice esce comunque, ma il sistema non regge. Con quel "dove", l'AI diventa la cosa che ti permette di fare il lavoro che davvero conta.