Vibe Coding in Prod Responsibly

Una guida completa su come utilizzare il “vibe coding” in produzione in modo responsabile, basata sul talk di Eric Schulntz, ricercatore di Anthropic specializzato in coding agents.

Introduzione

Il vibe coding rappresenta un nuovo paradigma nello sviluppo software. Ma cos’è esattamente? E soprattutto, come possiamo utilizzarlo in produzione senza compromettere la qualità e la sicurezza del nostro codice?

Eric Schulntz, ricercatore di Anthropic e co-autore di “Building Effective Agents”, ha vissuto questa trasformazione in prima persona. Durante due mesi con la mano ingessata dopo un incidente in bici, Claude ha scritto tutto il suo codice. Questa esperienza lo ha portato a sviluppare le best practice per utilizzare il vibe coding in modo efficace e responsabile.

Cos’è il Vibe Coding

Molti confondono il vibe coding con il semplice uso estensivo di AI per generare codice. Ma non è così semplice.

Quando si usa Cursor o Copilot in un feedback loop stretto con il modello, quello non è vero vibe coding. Per capire cos’è veramente, dobbiamo guardare alla definizione di Andrej Karpathy:

Vibe coding è quando ti lasci completamente andare alle vibes, abbracci gli esponenziali, e dimentichi che il codice esiste.

La parte cruciale è: “dimentichi che il codice esiste”.

Perché è Importante

Il vibe coding ha entusiasmato le persone al di fuori dell’industria engineering. Improvvisamente, chi non sapeva programmare poteva costruire un’intera app da solo. Questo è stato un grande unlock per moltissime persone.

Naturalmente, ci sono stati problemi:

• “Cose random stanno succedendo”
• “Hanno esaurito i limiti delle mie API keys”
• “Le persone bypassano la subscription”
• “Creano dati random nel database”

I casi di successo del vibe coding erano tutti low-stakes: videogiochi, progetti personali, cose dove un bug non è un problema.

L’Esponenziale

Perché dovremmo preoccuparci del vibe coding se sembra rischioso per prodotti reali?

La risposta sta nell’esponenziale: la lunghezza dei task che l’AI può gestire raddoppia ogni sette mesi.

Oggi siamo a circa un’ora di lavoro. Va bene, puoi usare Cursor, puoi far scrivere una feature a Claude Code in un’ora e rivedere tutto il codice rimanendo intimamente coinvolto.

Ma cosa succede l’anno prossimo? O tra due anni?

Quando l’AI sarà abbastanza potente da generare un’intera giornata di lavoro alla volta, o un’intera settimana, non sarà possibile tenere il passo se dobbiamo ancora muoverci in lockstep.

L’Analogia del Compiler

Nei primi giorni dei compiler, molti sviluppatori non si fidavano. Usavano il compiler, ma leggevano comunque l’assembly generato per assicurarsi che fosse come l’avrebbero scritto loro.

Ma questo non scala.

A un certo punto, inizi a lavorare su sistemi così grandi che devi semplicemente fidarti del sistema. La domanda è: come farlo responsabilmente?

Il Principio Fondamentale

La risposta di Eric è chiara:

Dimenticheremo che il codice esiste, ma non che il prodotto esiste.

Tornando all’analogia del compiler: sappiamo tutti che c’è assembly sotto il cofano, ma la maggior parte di noi non ha bisogno di pensare a quale assembly sia realmente. Eppure riusciamo ancora a costruire buon software senza capire quell’assembly.

Arriveremo allo stesso livello con il software.

Non è un Problema Nuovo

Questo potrebbe sembrare rivoluzionario, ma in realtà non è un problema nuovo:

• Come gestisce un CTO un esperto in un dominio in cui non è lui stesso esperto?
• Come revisiona un PM una feature engineering quando non può leggere tutto il codice?
• Come verifica un CEO il lavoro del commercialista quando non è esperto in contabilità finanziaria?

Questi sono problemi che esistono da centinaia o migliaia di anni, e abbiamo soluzioni:

1. Il CTO può scrivere acceptance test per un esperto che lavora per lui, anche senza capire l’implementazione
2. Il PM può usare il prodotto che il team ha costruito e verificare che funzioni come previsto
3. Il CEO può fare spot check su fatti chiave che capisce per costruire fiducia nel modello finanziario complessivo

L’Abstraction Layer

Il modo per essere sicuri e responsabili è trovare un abstraction layer che puoi verificare anche senza conoscere l’implementazione sottostante.

Il Problema del Tech Debt

C’è un’importante eccezione oggi: il tech debt.

Attualmente non esiste un buon modo per misurare o validare il tech debt senza leggere il codice tu stesso. La maggior parte degli altri sistemi nella vita ha modi per verificare ciò che ti interessa senza conoscere l’implementazione.

Il tech debt è una di quelle rare cose dove non c’è davvero un buon modo per validarlo se non essere un esperto nell’implementazione stessa.

La Soluzione: Focus sui Leaf Nodes

Questo non significa che non possiamo fare vibe coding. Significa che dobbiamo essere molto intelligenti e mirati su dove lo applichiamo.

La risposta è: concentrarsi sui leaf nodes nella codebase.

         ┌─── [Leaf Node]
         │
    ┌────┴─── [Leaf Node]
    │
────┴───────── Core Architecture (evitare vibe coding qui)

I leaf nodes sono parti del codice dove:

• Niente dipende da loro
• Sono la feature finale
• Sono il bell & whistle finale

È relativamente OK se c’è tech debt nei leaf nodes perché nient’altro dipende da loro. È improbabile che cambino o che altre cose vengano costruite sopra.

Al contrario, i trunk e i branch sottostanti (l’architettura core) sono ciò che noi ingegneri dobbiamo ancora capire profondamente, perché:

• È quello che cambierà
• È quello su cui altre cose verranno costruite
• Deve rimanere estensibile, comprensibile e flessibile

Come Avere Successo nel Vibe Coding

Chiediti: Cosa Puoi Fare per Claude?

Ask not what Claude can do for you, but what you can do for Claude.

Quando fai vibe coding, stai fondamentalmente agendo come product manager per Claude. Devi pensare come un PM.

Domanda chiave: Quali guidance o contesto avrebbe bisogno un nuovo dipendente nel tuo team per avere successo in questo task?

Troppo spesso siamo abituati a una chat veloce avanti e indietro con l’AI:

• “Fai questa feature”
• “Fixa questo bug”

Ma se fosse il primo giorno di un umano sul lavoro e gli dicessi “Ehi, implementa questa feature”, non ti aspetteresti che abbia successo. Avresti bisogno di:

• Dargli un tour della codebase
• Spiegargli i requirements e le specifiche
• Illustrare i constraints che deve capire

Man mano che facciamo vibe coding, diventa nostra responsabilità fornire tutte queste informazioni a Claude.

Il Processo di Preparazione

Quando Eric lavora su feature con Claude, spesso spende 15-20 minuti raccogliendo guidance in un singolo prompt, poi lascia Claude lavorare.

Quei 15-20 minuti non sono solo lui che scrive il prompt a mano. Spesso è una conversazione separata dove:

1. Parla avanti e indietro con Claude
2. Claude esplora la codebase
3. Cercano file insieme
4. Costruiscono un piano che cattura l’essenza di:
   • Cosa vuole ottenere
   • Quali file dovranno essere modificati
   • Quali pattern nella codebase seguire

Una volta raccolte tutte queste informazioni, le dà a Claude (in un nuovo contesto o dicendo “Eseguiamo questo piano”) e tipicamente Claude ha un tasso di successo molto molto alto.

Case Study: 22,000 Linee in Produzione

Il team di Eric ha recentemente mergiato un cambiamento da 22,000 linee nella loro production reinforcement learning codebase, scritto pesantemente da Claude.

Come l’hanno fatto responsabilmente?

1. Essere il PM di Claude

Non è stato un singolo prompt che hanno poi mergiato. Ci sono stati giorni di lavoro umano per:

• Definire i requirements
• Guidare Claude
• Capire cosa dovesse essere il sistema

Hanno davvero abbracciato il loro ruolo di product manager per Claude.

2. Focus sui Leaf Nodes

Il cambiamento era largamente concentrato in leaf nodes della codebase dove sapevano che era OK avere un po’ di tech debt, perché non si aspettavano che quelle parti dovessero cambiare nel prossimo futuro.

Le parti che pensavano fossero importanti e dovessero essere estensibili? Pesante human review di quelle parti.

3. Stress Tests per la Stabilità

Hanno accuratamente progettato stress tests per la stabilità e hanno disegnato l’intero sistema per avere input e output facilmente verificabili da umani.

Questo ha permesso loro di creare verifiable checkpoints per assicurarsi che fosse corretto anche senza capire o leggere la piena implementazione sottostante.

4. Verifiability Without Reading Code

La loro maggiore preoccupazione era la stabilità, e sono stati in grado di misurarla anche senza leggere il codice:

• Creando stress tests
• Facendoli girare per lunghe durate
• Verificando correttezza basata su input/output del sistema

Hanno progettato il sistema per essere comprensibile e verificabile anche senza leggere tutto il codice.

Il Risultato

Combinando questi approcci, sono diventati confidenti in questo cambiamento quanto in qualsiasi altro che fanno alla codebase, ma lo hanno consegnato in una frazione minuscola del tempo e dello sforzo che sarebbe servito per scriverlo tutto a mano.

Principles for Responsible Vibe Coding

1. Sii il PM di Claude

Ask not what Claude can do for you, but what you can do for Claude.

Fornisci:

• Contesto completo del progetto
• Requirements chiari
• Esempi di pattern esistenti
• Constraints e considerazioni

2. Focus sui Leaf Nodes

Non fare vibe coding su:

• Core architecture
• Sistemi sottostanti
• Codice da cui dipendono altre parti

OK per vibe coding:

• Feature finali
• UI components isolati
• Tool utilities standalone

3. Pensa alla Verifiability

Progetta il tuo sistema in modo da poter verificare la correttezza senza leggere il codice:

• Test end-to-end che validano il comportamento
• Stress tests per performance e stabilità
• Input/output verificabili da umani
• Acceptance criteria chiari

4. Ricorda l’Esponenziale

Va bene oggi se non fai vibe coding, ma tra uno o due anni sarà un enorme svantaggio se insisti per leggere o scrivere ogni singola riga di codice.

Non sarai in grado di sfruttare le nuove wave di modelli che possono produrre chunk di lavoro molto molto grandi per te.

Diventerai il bottleneck se non diventi bravo in questo.

Insights dalla Q&A

Come Imparare Ancora?

Domanda: In passato imparavamo affrontando problemi di sintassi, librerie, connessioni tra componenti. Come impariamo ora? Come diventiamo coder migliori?

Risposta di Eric:

Ci sono ragioni per essere preoccupati e ragioni per essere ottimisti.

Preoccupazione: Non saremo lì nella struggle, nel grind. Alcuni professori dicono “i coder oggi non sono bravi come prima perché non hanno mai scritto assembly a mano”.

Ottimismo:

• Puoi imparare le cose molto più velocemente usando questi AI tool
• Quando revisioni il codice, puoi chiedere “Claude, non ho mai visto questa libreria. Spiegamela. Perché l’hai scelta invece di un’altra?”
• Avere sempre un pair programmer disponibile

Le persone pigre non impareranno - scivoleranno via. Ma se dedichi tempo e vuoi imparare, ci sono risorse incredibili.

Balance tra Troppe e Poche Informazioni

Domanda: Nel processo di pre-planning, qual è il balance tra dare troppa o troppo poca informazione? Dai un full PRD?

Risposta di Eric:

Dipende molto da cosa ti importa:

• Se non ti importa come lo fa: Non parlare di implementation details, solo requirements e cosa vuoi alla fine
• Se conosci bene la codebase: Vai più in profondità - “queste sono le classi che dovresti usare, guarda questo esempio di feature simile”

Principio: I modelli danno il meglio quando non li over-constrai troppo. Pensa a cosa daresti a un junior engineer per farlo avere successo.

Security e Vulnerabilità

Domanda: Come bilanci effectiveness e cybersecurity? Ci sono stati report di top 10 vibe-coded apps super vulnerabili.

Risposta di Eric:

Tutto torna al primo punto: essere il PM di Claude e capire abbastanza del contesto per sapere:

• Cosa è pericoloso
• Cosa è sicuro
• Dove devi essere attento

Le cose che ottengono molta stampa sul vibe coding sono persone che non hanno alcuna competenza a programmare che lo fanno. Va bene per giochi, va bene per creatività.

Ma per production systems, devi sapere abbastanza su quali domande fare per guidare Claude nella direzione giusta.

Test-Driven Development

Domanda: Tips per TDD? Claude spesso sputa fuori l’intera implementazione e poi scrive test che a volte falliscono.

Risposta di Eric:

TDD è molto molto utile nel vibe coding, finché puoi capire i test anche senza vedere l’implementazione (aiuta Claude a essere più auto-consistente).

Il problema: È facile per Claude andare in rabbit hole scrivendo test troppo implementation-specific.

La soluzione:

# Essere prescrittivo
"Scrivi solo tre test end-to-end:
- happy path
- error case 1
- error case 2

I test devono essere generali ed end-to-end."

Spesso quando fa vibe coding, la prima parte del codice che legge sono i test. Se è d’accordo con i test e i test passano, si sente abbastanza sicuro del codice.

Embracing Exponentials

Domanda: Come so se ho “abbracciato gli esponenziali”?

Risposta di Eric:

Non è solo che i modelli miglioreranno - miglioreranno più velocemente di quanto possiamo immaginare.

Non è che sta migliorando costantemente, è che migliora e poi va wild.

“Machines of Loving Grace non è science fiction. È una product roadmap.” — Dario Amodei e Mike Krieger

Se parli con qualcuno che faceva computer negli anni ‘90: “OK, ottimo, abbiamo un paio di kilobyte di RAM. Ora ne abbiamo un paio in più.”

Ma se vai avanti veloce a dove siamo ora: abbiamo terabyte. Non è solo il doppio - è milioni di volte meglio.

Questo è ciò che succede con gli esponenziali in 20 anni.

Non dovremmo pensare a 20 anni da ora come “cosa succede se questi modelli sono due volte migliori”. Dovremmo pensare “cosa succede se sono un milione di volte più intelligenti e veloci”.

È wild. Non possiamo nemmeno pensare a cosa significhi.

Conclusione

Il vibe coding in production rappresenta un cambiamento fondamentale nel modo in cui pensiamo allo sviluppo software. Non si tratta di abbandonare la responsabilità o la qualità, ma di evolvere il nostro ruolo da implementatori a product manager per i nostri AI agents.

Principi Chiave da Ricordare

1. Sii il PM di Claude - Fornisci il contesto e la guidance che un nuovo team member avrebbe bisogno
2. Focus sui Leaf Nodes - Mantieni il controllo sull’architettura core, lascia che l’AI gestisca le implementazioni finali
3. Pensa alla Verifiability - Progetta sistemi che puoi validare senza leggere ogni riga di codice
4. Ricorda l’Esponenziale - I modelli raddoppiano in capacità ogni 7 mesi; prepararsi ora è essenziale

Il Futuro

Tra uno o due anni, la capacità di fare vibe coding responsabilmente non sarà più un nice-to-have, sarà una necessità. I modelli saranno in grado di generare settimane di lavoro in poche ore, e chi insiste nel controllo micromanagement di ogni riga diventerà il bottleneck del proprio team.

Il vibe coding responsabile non significa dimenticare il codice e sperare per il meglio. Significa evolvere da craftsman che scolpisce ogni riga a architetto che progetta sistemi verificabili e guida intelligenze artificiali sempre più capaci.

Il futuro dello sviluppo software non è umani vs AI, ma umani e AI che collaborano - con noi nel ruolo di product manager, architetti e verificatori finali.

Buon vibe coding! 🚀