Vibe Coding nel 2026: come sviluppare software su larga scala con l'IA (dalla tua prima app alle dimensioni di Google)

Due anni fa, l’idea di “descrivere semplicemente ciò che si vuole e lasciare che l’IA scriva il codice” sembrava una battuta. Nel 2026, invece, è proprio così che viene sviluppata una quota enorme e in continua crescita del software mondiale. GitHub riferisce che all’incirca Il 46% di tutto il nuovo codice è ora generato dall'intelligenza artificiale. Google ha dichiarato che circa un quarto del proprio codice è sviluppato con l'ausilio dell'intelligenza artificiale. Gartner prevede che 60% di tutto il nuovo codice software dovrà essere scritto al computer entro la fine di quest'anno. Il “vibe coding” non solo è sopravvissuto al ciclo dell’hype, ma ha silenziosamente conquistato il settore.

Realizzo software di produzione quasi esclusivamente impartendo istruzioni agli agenti di IA in inglese semplice. Niente sintassi digitata a mano, niente laurea in informatica: solo istruzioni precise, revisioni rigorose e un metodo che impedisce all’intero sistema di crollare sotto il proprio peso. Questa è la guida che avrei voluto ricevere il primo giorno: cos’è davvero il “vibe coding” nel 2026, come partire da zero, gli strumenti e i modelli esatti su cui vale la pena investire il proprio tempo in questo momento e — la parte che tutti vorrebbero segretamente sapere — se è davvero possibile utilizzarlo per creare qualcosa delle dimensioni di Google o Facebook.

In breve: con il “vibe coding” si possono ottenere risultati sorprendentemente ambiziosi, ben oltre le aspettative di quasi tutti. Ma chi realizza software seri e su larga scala basati sull’IA non è certo chi si limita a lanciare prompt a un chatbot sperando per il meglio. Si tratta di persone che seguono un processo rigoroso. Alla fine di questo articolo saprai esattamente in cosa consiste tale processo e avrai a disposizione uno stack che potrai iniziare a utilizzare già da oggi.

Che cos’è davvero il “Vibe Coding”? (La definizione del 2026)

Il termine è stato coniato da Andrej Karpathy nel febbraio 2025 ed è diventato così popolare che il Collins Dictionary lo ha nominato “Parola dell’anno” per il 2025. La sua definizione originale era volutamente generica: ci si lascia trasportare dall’atmosfera, si descrive ciò che si desidera e si accetta qualsiasi risultato restituisca il modello senza preoccuparsi troppo dei dettagli.

Quella versione informale è ormai superata e, onestamente, buon viaggio. Nel 2026, lo “vibe coding” assume un significato più maturo: Tu redigi specifiche precise in linguaggio naturale, un agente di intelligenza artificiale le implementa e tu rimani coinvolto in tutto il processo in qualità di architetto, revisore e autorità finale. Non sei tu a scrivere il codice. Sei tu a dare indicazioni al sistema che scrive il codice — e sei tu il responsabile di ciò che viene rilasciato.

Lo stesso Karpathy ha cambiato le regole del gioco all’inizio del 2026, definendo il “vibe coding” ormai superato e proponendo “ingegneria agenziale” anziché: “agentico”, perché si orchestrano agenti piuttosto che scrivere codice il 99% delle volte; “ingegneristico”, perché farlo bene è un vero e proprio mestiere che richiede una reale competenza. Il nome non ha ancora preso piede del tutto — la maggior parte delle persone continua a dire “vibe coding” — ma il cambiamento che descrive è esattamente quello giusto. Il baricentro si è spostato da digitazione a regia.

Ecco i dati che contano. Informazioni su 92% di sviluppatori statunitensi utilizzano ormai quotidianamente strumenti di programmazione basati sull'intelligenza artificiale, e 82% di sviluppatori in tutto il mondo li utilizzano almeno una volta alla settimana. Tra i recenti gruppi di Y Combinator, una percentuale notevole di startup ha codebase generati dall’IA per oltre il 90%. Non si tratta più di una tecnica marginale. È lo standard, e o la padroneggi alla perfezione oppure rimani indietro.

La verità nuda e cruda su “Vibe Coding Google o Facebook”

Affrontiamo subito la questione del sogno, perché è la domanda che mi viene posta più spesso.

Riusciresti a sederti questo fine settimana e a realizzare in un colpo solo un clone funzionante di google.com o facebook.com? No. Chiunque ti dica il contrario sta cercando di venderti un corso. Google è composto da migliaia di ingegneri, un’infrastruttura su scala planetaria, un decennio di sistemi accumulati e una tecnologia di ricerca e ranking che è davvero complessa. Uno screenshot di un “clone di Facebook creato con un solo prompt” è un prototipo di interfaccia utente senza un vero backend, senza autenticazione su larga scala, senza un modello di dati in grado di reggere il contatto con gli utenti e senza una sicurezza degna di questo nome.

Ma ecco la parte che è È vero, ed è proprio questa la verità più interessante: I software di grandi dimensioni e destinati alla produzione vengono senza dubbio sviluppati in questo modo proprio in questo momento — anche all’interno delle aziende che state cercando di imitare. La statistica di Google, secondo cui un quarto di tutto il codice è generato dall’IA, è rivelatrice. La differenza tra una demo di facciata e qualcosa di concreto non sta nei prompt, ma nel metodo.

Una demo è semplice. Un software che è sicuro, scalabile e di facile manutenzione è difficile — e proprio questo divario costituisce la tensione fondamentale del “vibe coding” nel 2026. I team che riescono a superarlo trattano gli agenti di IA come ingegneri junior veloci, instancabili e a volte troppo sicuri di sé, e li sottopongono alla stessa disciplina che una buona organizzazione ingegneristica applica agli esseri umani: architettura chiara, lavoro suddiviso in parti, contesto di progetto persistente, test automatizzati e revisione della sicurezza in cui ogni riga di output dell’IA viene considerata inaffidabile fino a prova contraria.

Quindi ridefinisci l'obiettivo. Non hai intenzione di puff una ricerca su Google. Tu può Realizza un prodotto vero e proprio, ambizioso e ricco di funzionalità — un social network, un marketplace, una piattaforma SaaS — con una qualità di produzione autentica, da solo o con un team ridotto, in una frazione del tempo che ci voleva un tempo. Non si tratta di una versione edulcorata del sogno. Per un fondatore che lavora da solo, è quasi una magia. Il resto di questa guida spiega come farlo concretamente.

Come iniziare a programmare in Vibe (le nozioni di base)

Se non l'hai mai fatto, ecco l'intero modello mentale riassunto in una sola frase: Tu sei l'architetto e il regista; l'IA è il costruttore. Fai tuo questo concetto e tutto il resto verrà da sé.

Ecco come ottenere il tuo primo risultato concreto, passo dopo passo.

1. Scegli un agente e un progetto. Non perdere una settimana a cercare gli strumenti giusti. Scegli un unico strumento di programmazione basato sull’intelligenza artificiale (vedi i consigli qui sotto) e seleziona un progetto piccolo ma concreto: un sito web personale, un’app per tenere traccia delle abitudini, un piccolo strumento che ti serve davvero. La pratica batte il tutorial.
2. Descrivi il risultato, non la modalità di attuazione. Informare l'agente cosa che vuoi e perché, in parole povere: “Costruiscimi un sito personale pulito con una homepage, un blog con pagine dedicate ai singoli post, la modalità scura e un modulo di contatto che mi invii un’e-mail”. Non devi ancora sapere cosa siano React o PostgreSQL. Devi sapere cosa vuoi.
3. Informati su come funziona — non limitarti ad accettarlo così com’è. Questa è l’unica abitudine che distingue chi porta a termine il lavoro da chi invece soffre di “postumi da entusiasmo”. Quando l’agente spiega il proprio piano, leggilo. Quando scrive il codice, chiedigli di spiegarti tutto ciò che non ti è chiaro. Non stai memorizzando la sintassi; stai sviluppando la capacità di valutare se il lavoro sia sensato.
4. Procedi per piccoli passi ben definiti. “Ora aggiungi un pulsante per attivare la modalità scura.” “Il modulo di contatto dovrebbe verificare la validità dell’indirizzo e-mail prima dell’invio.” Una modifica alla volta. I piccoli passi garantiscono la precisione dell’agente e mantengono tu in grado di capire quando qualcosa si è rotto.
5. Provalo continuamente. Clicca su tutti i pulsanti. Cerca di far andare in errore i tuoi moduli. Chiedi all’agente di scrivere dei test. Prima si individua un problema, meno costa risolverlo.
6. Considera l'IA come un pari, non come un oracolo. Contrasta. Esprimi il tuo dissenso. Chiediti: “C’è un modo più semplice?”. La regola d’oro del “vibe coding” del 2026 è chiara e diretta: Non rilasciare mai codice che non comprendi, almeno a livello generale. Non è necessario leggere ogni riga. È invece importante sapere a cosa serve ogni parte.

Ecco fatto. Questo è il ciclo. Tutto il resto di questo articolo riguarda l'esecuzione di questo ciclo meglio, presso su scala più ampia, con il strumenti adeguati.

Gli strumenti: cosa usare davvero nel 2026

L'agente è quello con cui interagisci. Analizza il tuo codice, pianifica le modifiche, modifica più file contemporaneamente, esegue comandi e test e procede per iterazioni con un intervento manuale minimo. Il settore si è suddiviso in tre schieramenti ben distinti, e la maggior parte degli utenti esperti che conosco ne utilizza due o tre, distribuendo il lavoro in base al tipo di attività.

Agenti "terminal-first" (dove si svolge il lavoro vero e proprio)

Questi programmi si eseguono nel terminale, consentono di modificare i file direttamente sul proprio computer con un ciclo di feedback rapido e tendono ad essere i più adatti per attività di ingegneria vere e proprie.

• Claude Code — La mia auto di tutti i giorni e la numero uno in termini di prestazioni pure. Alimentata da Claude Opus 4.8, è in testa alla classifica verificata da SWE-bench a 88.6%. È altamente programmabile (hook, “routine” pianificate, tutto il necessario) e legge un CLAUDE.md file nel tuo repository per caricare automaticamente il contesto del progetto ad ogni sessione. I piani a pagamento partono da circa $20 al mese.
• OpenAI Codex — Basato su GPT-5.5, è in testa alla classifica di Terminal-Bench e riunisce in un unico account CLI, cloud, web e dispositivi mobili, con un prezzo di partenza di circa $8 al mese. Ottimo se fai parte dell’ecosistema ChatGPT.
• Codice aperto — Il fiore all’occhiello dell’open source (oltre 172.000 stelle su GitHub, con licenza MIT). Si tratta di un vero e proprio agente di terminale, non di un wrapper, ed è indipendente dal modello: basta fornire la chiave API di qualsiasi modello — Claude, GPT, Gemini, Kimi, GLM, DeepSeek, Qwen — e lo si può utilizzare. La velocità di introduzione delle nuove funzionalità è elevata perché la comunità lavora in modo rapido. Questa è la soluzione ideale se si desidera non dipendere da un unico fornitore.
• Aider, Cline, Hermes Agent, Goose, Kilo Code — Un solido livello open source. Tutto gratuito; paghi solo per i token dei modelli che fai passare attraverso di essi.

Ambienti di lavoro nativi IDE e visivi (dove la modifica incontra la regia)

• Cursore — L’esperienza di editing più pulita e completa. Il suo modello Composer ha un costo contenuto per output e Cursor 2.0 può eseguire fino a otto agenti in parallelo. Se vuoi vedi Se vuoi scrivere il codice mentre dirigi, inizia da qui.
• Google Antigravità — L'ambiente di lavoro di Google incentrato sugli agenti, gratuito per i privati in anteprima pubblica, con impostazione predefinita su Gemini 3.5 Flash e gestione visiva degli agenti in parallelo. L’interessante jolly. (Nota: il vecchio livello gratuito della CLI di Gemini da 1.000 richieste al giorno termina 18 giugno 2026 poiché Google lo sta integrando nella CLI di Antigravity — quindi, se lo utilizzavate, oggi è il giorno giusto per passare a un'altra soluzione.)
• GitHub Copilot — L'opzione nativa di GitHub: la scelta migliore se il tuo codice è già ospitato lì e desideri automatizzare il passaggio dagli issue alle pull request. Il piano Pro prevede $10 al mese.
• Windsurf / Devin Desktop — Windsurf si è evoluto in Devin Desktop, puntando su agenti cloud autonomi e paralleli che aprono pull request mentre tu fai altro.

Una nota tecnica che vale la pena conoscere: ormai quasi tutti gli agenti più affidabili supportano il Protocollo di contesto del modello (MCP), uno standard aperto che consente di integrare gli stessi strumenti esterni (ricerca sul web, database, il proprio sistema di gestione dei progetti, ecc.) in qualsiasi agente con la stessa configurazione. Basta imparare MCP una volta sola per poterlo utilizzare ovunque.

I modelli: la gamma 2026 (e quando utilizzare ciascuno di essi)

Il tuo agente è la cabina di pilotaggio; il modello è il motore. E la metà del 2026 è stato un periodo davvero frenetico per il lancio di nuovi modelli: tre dei più importanti, elencati qui di seguito, sono stati presentati proprio nelle ultime settimane prima della stesura di questo articolo.

I modelli "frontier" chiusi (prestazioni al top, prezzo premium)

• Claude Opus 4.8 (Anthropic) — Rilasciato il 28 maggio 2026. Leader indiscusso in termini di qualità per l’ingegneria complessa, con più file e contesti estesi: 88,61 TP3T su SWE-bench Verified. Il prezzo è di $5 per milione di token in ingresso e $25 per milione di token in uscita. È la soluzione a cui ricorro quando un errore potrebbe costare caro: architettura, rifattorizzazioni di grandi dimensioni, qualsiasi cosa che sia fondamentale per il sistema.
• GPT-5.5 (OpenAI) — A pari merito con Opus e leader nella classifica di Terminal-Bench. Eccellente nel produrre risultati utilizzabili anche quando il prompt tralascia casi limite, il che lo rende perfetto per la prototipazione rapida.
• Gemini 3.1 Pro / 3.5 Flash (Google) — Potente, profondamente integrato nell’ecosistema di Google e in Antigravity, con Flash ottimizzato per la velocità.

L’ascesa della categoria open-weight (la vera storia del 2026)

È qui che la cosa si fa interessante, ed è qui che si trovano i risparmi. Un'ondata di modelli open-weight — molti dei quali provenienti da laboratori cinesi — è diventata davvero competitiva con i modelli all'avanguardia, e sono economici o gratuiti da ospitare autonomamente. La geopolitica è uno dei fattori trainanti in questo contesto: le recenti restrizioni statunitensi alle esportazioni dei principali modelli americani all'estero hanno reso i modelli open-weight con licenze permissive molto più attraenti dal punto di vista strategico in tutto il mondo.

• Kimi K2.7-Code (Moonshot AI) — Pubblicato 12 giugno 2026. Un colosso senza limiti di peso, progettato con un approccio “coding-first”: un modello Mixture-of-Experts da 1 trilione di parametri (32 miliardi attivi per token), un Finestra di contesto da 256K token, input multimodale e una licenza MIT modificata che ne consente l'uso commerciale. Moonshot sostiene che circa 30%: riduzione dell'utilizzo dei token di ragionamento rispetto al suo predecessore, oltre a guadagni a doppia cifra rispetto al benchmark, il che è importante perché i token sono denaro. Si abbina alla CLI Kimi Code, progettata per l’uso su terminale (piani a partire da $19 al mese), e costa circa $0,95 per ogni milione di token immessi tramite API. Realizzato appositamente per cicli di agenti a lungo termine con fasi di pianificazione, esecuzione e debug. Una scelta eccellente per esecuzioni automatiche di lunghissima durata.
• GLM 5.2 (Z.ai, precedentemente Zhipu AI) — Rilasciato 13 giugno 2026, un giorno dopo Kimi. Un MoE con 744 miliardi di parametri (circa 40 miliardi di parametri attivi) con un finestra di contesto utilizzabile da 1 milione di token — abbastanza capiente da poterci caricare un intero repository — e pesi open source con licenza MIT disponibili su Hugging Face. Z.ai sostiene di superare GPT-5.5 in alcuni benchmark di programmazione a lungo termine a circa un sesto del costo, anche se va notato che tali benchmark sono stati riportati dal fornitore e non sono ancora stati verificati in modo indipendente al momento del lancio. La caratteristica fondamentale per i programmatori "vibe": viene fornito tramite un endpoint compatibile con Anthropic e il Il piano di codifica GLM prevede circa $10 al mese, quindi si integra perfettamente con Claude Code, OpenCode, Cline, Roo Code, Goose e simili. È perfetto per il front-end e per i lavori incentrati sull’interfaccia utente, e offre un rapporto qualità-prezzo incredibile per la maggior parte della tua programmazione orientata agli agenti.
• DeepSeek V4 (e il più economico V4-Flash) — La scelta ideale per lavori su larga scala in cui il costo è un fattore determinante e si desidera una qualità discreta a prezzi stracciati.
• Qwen 3.5 — Ottimo rapporto prestazioni/parametri, in particolare per le varianti più piccole che funzionano velocemente su hardware di uso comune.

Eseguire i modelli in autonomia: Ollama e Ollama Cloud

Se la privacy, il controllo dei costi o semplicemente il fatto di non dover dipendere dall’API di nessuno ti interessano, Ollama è il “momento Docker per gli LLM locali”: un unico comando per scaricare ed eseguire modelli open source (Llama, Qwen, Mistral, DeepSeek, Gemma e altri) in locale, con un’API compatibile con OpenAI all’indirizzo localhost:11434 a cui qualsiasi agente possa fare riferimento.

Il problema con l'elaborazione locale è sempre stato l'hardware: i modelli open source di fascia alta richiedono una notevole quantità di VRAM. Ed è proprio questo che Nuvola di Ollama risolve, ed è ora disponibile per tutti. Si tratta di un’inferenza gestita: si eseguono quegli stessi modelli aperti di grandi dimensioni sulle GPU del data center di Ollama con non è necessaria una GPU locale, e — questa è la parte ingegnosa — mette in luce il identico API HTTP come configurazione locale. Nessuna riscrittura del codice, nessun nuovo SDK. Basta selezionare un modello cloud e il gioco è fatto. I prezzi sono accessibili: un livello gratuito, un Piano Pro a circa $20 al mese, e un livello Max più elevato, intorno a $100 al mese, fatturato in base al tempo di utilizzo della GPU anziché ai token. Ollama garantisce inoltre l’assenza di registrazione dei dati, nessun addestramento sui dati dell’utente e una conservazione pari a zero presso i propri partner di hosting — aspetto importante se si lavora su dati sensibili o soggetti al GDPR.

La strategia di instradamento multimodello

Ecco lo schema che i migliori professionisti utilizzano effettivamente, ed è la leva più importante in termini di costi nella programmazione delle vibrazioni: Non utilizzare sempre il modello più costoso per tutte le operazioni. Percorso per attività.

• Utilizza un modello di frontiera (Opus 4.8, GPT-5.5) per quella piccola parte del lavoro in cui un errore comporta costi davvero elevati: architettura, progettazione di schemi, logica sensibile alla sicurezza, rifattorizzazioni di ampia portata.
• Utilizza un modello aperto, economico e resistente (GLM 5.2, Kimi K2.7, DeepSeek V4) per la maggior parte del lavoro di routine: implementazione delle funzionalità, codice standard, interfaccia utente, test.
• Utilizzo locale o Ollama Cloud modelli aperti per inferenze su grandi volumi e a basso rischio: classificazione, sintesi, modifiche semplici.

I team che adottano questo approccio riducono sistematicamente i costi di inferenza del 60–80% senza alcuna perdita significativa in termini di qualità. Con un agente indipendente dal modello come OpenCode, il passaggio è semplice come cambiare una chiave API.

Il file system che rende possibili i grandi progetti di programmazione in Vibe (AGENTS.md, CLAUDE.md e altri)

Questa è la sezione più importante dell’articolo e — per essere del tutto sincero — la parte per cui è stata pensata il resto di questa guida. È qui che quasi tutti falliscono, me compreso quando ho iniziato. Quindi procediamo con calma e in modo concreto, perché è proprio questo che fa la differenza tra un progetto che cresce nel corso dei mesi e uno che crolla silenziosamente già nella seconda settimana.

Ecco la cruda realtà: Gli agenti di intelligenza artificiale non conservano alcuna memoria tra una sessione e l'altra. Chiudi il terminale e tutto ciò che l’agente “sapeva” del tuo progetto svanisce nel nulla. Apri una nuova sessione domani e sarà di nuovo un perfetto sconosciuto: non ricorda il tuo stack, le tue convenzioni, le decisioni che hai preso la settimana scorsa, né a che punto era la compilazione. Passa da Claude Code a Cursor, oppure sostituisci un modello con un altro, e ricomincerai da zero a secondo tempo. In un progetto di piccole dimensioni è possibile spiegare nuovamente tutto in un solo paragrafo. In uno di grandi dimensioni, invece, è proprio questo il problema: si impiega più tempo a fornire nuovamente le indicazioni all’agente che a sviluppare il codice, ciò contraddice le scelte già fatte e il codice finisce per trasformarsi in un groviglio.

Il punto cruciale è proprio questo, quindi lo dirò senza giri di parole: La memoria del tuo progetto deve risiedere nei file presenti nel repository, non nella chat. La chat è temporanea. I file sono permanenti. Ad ogni sessione, l’agente ricostruisce la propria comprensione tramite leggere prima quei file — e poiché si tratta di semplici file Markdown presenti nel tuo repository, qualsiasi agente, modello o strumento è in grado di leggerli. Non dovrai più spiegare il tuo progetto da capo e lo documenterai una volta sola, in modo corretto. È questo che permette a un progetto di sopravvivere a cambiamenti di contesto, sostituzioni di modelli e cambiamenti di strumenti. È anche, non a caso, ciò che permette a una sola persona di nutrire un’ambizione grande come quella di Google: non la tieni nella tua testa. La conservi su disco.

Ecco il livello di documentazione che inserisco nella directory principale di ogni progetto serio:

project-root/
├── README.md # Front door: cos’è, perché esiste, come eseguirlo
├── AGENTS.md # Istruzioni operative per gli agenti IA multi-strumento (lo standard)
├── CLAUDE.md # Linee guida specifiche per il codice Claude (sintetiche; importa AGENTS.md)
├── GEMINI.md # Linee guida specifiche per la CLI di Gemini (brevi; importa AGENTS.md)
├── CONVENTIONS.md     # Convenzioni di codifica (caricate automaticamente anche da aider)
├── CONTEXT.md # Descrizione dettagliata del contesto del progetto per gli utenti umani e i modelli di linguaggio di grandi dimensioni (LLM)
├── llms.txt # Mappa leggibile dalle macchine del repository e della documentazione per gli agenti
├── VISION.md # Il "perché" e l’obiettivo a lungo termine
├── ROADMAP.md # Dove è diretto il progetto: fasi e traguardi
├── TASKS.md # Elenco delle attività attive / backlog di lavoro (il "cursore")
├── TODO.md # Appunti informali e veloci per cose non ancora pianificate
├── DECISIONS.md # Indice delle decisioni architetturali (mai riaperte)
└── CHANGELOG.md # Cronologia leggibile e con controllo delle versioni di ciò che è stato rilasciato

Può sembrare una quantità enorme. In realtà non lo è, una volta capito che questi file svolgono tre funzioni diverse. Pensate a loro come a tre strati, dal più durevole al più usa e getta.

Livello 1 — Le regole (stabili, cambiano raramente)

Questi definiscono come un agente dovrebbe comportarsi nel tuo repository. Li scrivi all'inizio e li modifichi di tanto in tanto.

• AGENTS.md è il cuore del sistema e il file che risolve il problema della portabilità. È lo standard aperto e indipendente dagli strumenti che serve a comunicare qualsiasi Agente di programmazione basato sull’IA: come funziona il tuo progetto: lo stack tecnologico, come installarlo ed eseguirlo, come eseguire test e linting, le convenzioni da seguire e le cose da non fare mai. È nato nel 2025 da una collaborazione tra Sourcegraph, OpenAI, Google, Cursor e Factory, ed è ora gestito dalla Linux Foundation, adottato da oltre 30 strumenti e presente in oltre 60.000 repository. Il punto centrale è la portabilità: basta scriverlo una volta e Codex, Cursor, Windsurf, Cline, Copilot, Gemini CLI e altri lo leggono in modo nativo. Tutto ciò che viene condiviso si trova qui.
• CLAUDE.md è il file di istruzioni nativo di Claude Code — ed ecco il tranello che mette in difficoltà tutti, che potrebbe essere proprio ciò che ti ha creato problemi: A metà del 2026, Claude Code non legge automaticamente AGENTS.md. Si legge CLAUDE.md. Se il tuo repository contiene solo un AGENTS.md, Claude Code si carica zero istruzioni del progetto, e non ti avviserà. Ti ritroverai semplicemente con un risultato peggiore e ti chiederai perché. La soluzione è semplicissima ed è documentata ufficialmente: basta CLAUDE.md un file di poche righe che include quello condiviso con una sola riga — @AGENTS.md — quindi Claude legge le tue istruzioni generali oltre a eventuali elementi aggiuntivi specifici per Claude. (L'altro approccio comune è un collegamento simbolico: ln -s AGENTS.md CLAUDE.md, il che rende i due file letteralmente identici.) Un'unica fonte di verità, nessuna duplicazione, nessuna discrepanza.
• GEMINI.md Lo stesso vale per la CLI di Gemini di Google, ovvero il file delle istruzioni specifiche dello strumento. È bene che sia conciso e che rimandi a AGENTS.md anche questo. Lo schema non cambia mai: un unico file condiviso per tutti, un file "thin" per ogni strumento.
• CONVENTIONS.md contiene le convenzioni di codifica: denominazione, formattazione, modelli e regole architetturali. È utile di per sé ed è il file che l'agente aider carica nel contesto per convenzione. Fanne riferimento da AGENTS.md in modo che ogni strumento rispetti gli stessi standard.

Il risultato di questo livello è esattamente quello che volevi: vera indipendenza dagli strumenti. Poiché le regole condivise si trovano in AGENTS.md e ogni strumento si limita a puntare ad esso: puoi affidare lo stesso progetto oggi a Claude Code, domani a Cursor e la settimana prossima a OpenCode — e ognuno di essi funzionerà seguendo istruzioni identiche. Nessuna nuova istruzione, nessun vincolo. Ecco cosa significa, in pratica, la portabilità.

Livello 2 — La conoscenza e lo stato di vita (questa è la memoria vera e propria)

Questo livello è cosa il progetto è e la situazione attuale. I file “in questo momento” cambiano a ogni sessione: sono il vero rimedio contro l’amnesia.

• README.md — la pagina iniziale, pensata innanzitutto per gli utenti: cos’è il progetto, perché esiste, come funziona. Ogni nuovo utente (e ogni agente) inizia da qui.
• CONTEXT.md — un approfondimento dettagliato sia per gli esseri umani che per i modelli di linguaggio di grandi dimensioni (LLM): il settore di riferimento, il problema da risolvere, i concetti chiave e la terminologia, i vincoli. Si tratta del contesto approfondito che non trova spazio in un file di istruzioni sintetico, ma di cui un agente ha bisogno per prendere decisioni ponderate.
• VISION.md — la stella polare: il motivo per cui questo progetto esiste e la direzione che intende seguire nel lungo periodo. Ti aiuta a mantenere te e l’agente concentrati sullo stesso obiettivo quando siete immersi nello sviluppo di una singola funzionalità.
• llms.txt — una piccola mappa in Markdown leggibile da macchina che indirizza gli agenti (e gli strumenti di recupero dei documenti) verso i tuoi file più importanti con descrizioni di una sola riga, in modo che possano individuare rapidamente il contesto giusto e consumare meno token. Un avvertimento sincero: in quanto sito web pubblico Tattica SEO, llms.txt non è ancora stato dimostrato: le principali aziende del settore dell’IA non si sono impegnate a leggerlo e gli studi non evidenziano ancora alcun vantaggio misurabile in termini di posizionamento. Ma come repo/docs Indice degli agenti di codifica: fa davvero la sua parte.
• ROADMAP.md — la direzione che il progetto sta prendendo, suddivisa in fasi (vedi la sezione successiva) e tappe fondamentali. La tua mappa dell’intero percorso.
• TASKS.md — il file più importante in assoluto per garantire la continuità operativa quotidiana. Si tratta del cursore: cosa è stato fatto, cosa è in corso in questo momento, quali sono i prossimi passi e eventuali ostacoli. Quando una persona nuova alla sessione legge questo documento, sa esattamente da dove riprendere. Mantienilo conciso e aggiornato: serve per un rapido riorientamento, non è un saggio.
• TODO.md — spazio libero per annotare idee e piccole cose non ancora in programma. Consente di TASKS.md concentrati sul lavoro attivo senza tralasciare nulla.
• DECISIONS.md — un registro in cui vengono registrate solo le modifiche successive alle scelte architetturali che hai effettuato e perché. “Abbiamo scelto Postgres invece di SQLite perché abbiamo bisogno di scritture simultanee”. È proprio questo che impedisce a un agente di rimettere silenziosamente in discussione questioni già risolte o di contraddire una scelta tre sessioni dopo. Le voci più recenti in cima; mai modificate, solo aggiunte.
• CHANGELOG.md — un registro leggibile dall’utente, suddiviso in versioni, di ciò che è stato effettivamente pubblicato, in ordine cronologico. Rappresenta sia la cronologia del progetto sia il modo più veloce per una sessione già aperta di vedere cosa è cambiato di recente.

Livello 3 — La sessione (effimera, esiste solo nella chat)

Questa è la conversazione che stai avendo proprio ora. È l'unico livello che non viene conservato — e va bene così, perché tutto ciò che è importante viene riportato nel Livello 2 prima di chiudere. Tutto ciò che esiste solo qui è, per definizione, destinato a essere dimenticato.

Come si svolge effettivamente una sessione

Nel complesso, la routine quotidiana è quasi noiosa — ed è proprio questo il punto. Una sessione tipica si svolge così:

1. Apri la sessione. La prima cosa che fa l'agente è leggere le regole e lo stato: AGENTS.md (tramite CLAUDE.md/GEMINI.md), quindi ROADMAP.md, TASKS.md, e DECISIONS.md.
2. Riorientarsi. Il sistema risponde: “Siamo nella Fase 2, l’ultima attività era il flusso di accesso, la prossima è il middleware di autenticazione, nessun ostacolo”. Tu confermi o reindirizzi. Trenta secondi, zero sforzo, nessun nuovo briefing.
3. Svolgi un compito. Funziona su un singolo elemento da TASKS.md, attenendosi alle convenzioni e rispettando le decisioni definitive.
4. Riscrivi i dati nella memoria. Prima di chiudere, l'agente aggiorna TASKS.md (spostare il cursore), aggiunge una riga a CHANGELOG.md (ciò che è stato spedito) e registra ogni nuova scelta in DECISIONS.md.
5. Chiudi. La finestra di contesto si svuota — ma non importa, perché non conteneva nulla di importante. È tutto sul disco.

Domani, quando aprirai una nuova sessione o passerai a uno strumento completamente diverso, il passaggio 1 ricostruirà l'intero contesto in pochi secondi. Quello È così che si risolve il problema dell'amnesia, ed è proprio questo il motivo per cui un sviluppatore che lavora da solo riesce a mantenere la coerenza di un progetto di grandi dimensioni che si protrae per diversi mesi.

Questa è la “ingegneria agentica” nella pratica. L’era del mega-prompt unico è finita; l’era di scomposizione strategica È arrivato il momento. Non ti limiti a chattare con un'intelligenza artificiale: stai creando e gestendo un sistema operativo per i tuoi agenti, utilizzando questi documenti come unica fonte di verità. Configuralo una volta sola e il lavoro quotidiano tornerà a essere semplice, mentre il progetto si espanderà silenziosamente oltre ogni limite che una singola conversazione potrebbe mai raggiungere.

Una tabella di marcia realistica: lo sviluppo di un’app di grandi dimensioni con Vibe, fase per fase

Come si fa, quindi, a orientare tutto questo verso un obiettivo ambizioso — ad esempio, un vero e proprio social network o un marketplace? Non lo si costruisce tutto in una volta. Si procede per fasi e, all’interno di ciascuna di esse, si lascia che l’agente compia solo un piccolo passo alla volta.

• Fase 0 — Fondazioni. Configura il repository e il sistema di documentazione sopra indicato, quindi scegli il tuo stack. Fai funzionare un “hello world” in locale. Definisci le decisioni architetturali fondamentali prima di sviluppare qualsiasi funzionalità.
• Fase 1 — Architettura e dati. Definisci la struttura del sistema: il modello dei dati, i componenti principali e le modalità di interazione tra di essi. Si tratta di un lavoro all’avanguardia: se lo fai bene, tutto ciò che verrà dopo sarà più semplice.
• Fase 2 — Funzionalità principali. Sviluppare il nucleo del prodotto dall’inizio alla fine, fino a quando il percorso principale dell’utente non funziona correttamente. (Nel caso di un social network: account, profili, pubblicazione di post, feed.)
• Fase 3 — Integrazioni e autenticazione. Autenticazione reale, servizi esterni, persistenza, il tessuto connettivo.
• Fase 4 — Interfaccia e rifiniture. Il front-end, il design reattivo, l’internazionalizzazione, se necessaria. Ottimo lavoro per un modello incentrato sull’interfaccia utente come GLM 5.2.
• Fase 5 — Rafforzamento. Test, prestazioni, gestione degli errori e sicurezza — quella parte che le demo saltano sempre e che i prodotti reali non possono mai tralasciare.
• Fase 6 — Implementazione e gestione operativa. Mettilo in produzione. Configura la distribuzione, il monitoraggio, i backup e le procedure da seguire in caso di guasti.
• Fase 7 — Lancio e conformità. Pagine legali, documenti pubblici e (se si opera in un contesto come l'UE) i requisiti in materia di privacy e trasparenza, che sono imprescindibili per un sito commerciale.
• Fase 8 — Iterazione. Ora sei un vero e proprio prodotto. Correggi, migliora e cresci, all’infinito.

Notate cosa succede: trasforma un obiettivo che sembra impossibile da raggiungere (“creare un social network”) in una lunga sequenza di singole sessioni, tutte portabili a termine. È proprio questo il segreto. I progetti di grande portata non nascono da obiettivi ambiziosi, ma da mille piccoli passi ben mirati e ben documentati.

Le insidie (ovvero: come evitare i “postumi da vibrazioni”)

Il 2025 si è guadagnato un soprannome: l'anno del postumi da atmosfera. Molte squadre si sono affrettate a sostituire una progettazione accurata con soluzioni improvvisate e si sono scontrate di petto con la realtà. Imparate la lezione.

• La sicurezza è la questione più importante. Una società di sicurezza ha recentemente sviluppato 15 app identiche utilizzando cinque popolari strumenti di programmazione e ha scoperto che 69 vulnerabilità, sei delle quali critiche. Il codice generato dall'intelligenza artificiale è particolarmente soggetto a falle di sicurezza. Considerate ogni riga di codice generata dall'intelligenza artificiale come non affidabile finché non sia stata revisionata e sottoposta a scansione. Non permettete mai a un agente di creare autonomamente le proprie credenziali di autenticazione o di gestire informazioni riservate senza la vostra supervisione.
• Il degrado del codice è una realtà. Alcuni studi hanno rilevato un aumento del tasso di modifica del codice e una proliferazione del codice duplicato con l’aumentare del volume di IA. La disciplina nella rifattorizzazione è più importante che mai. Assicuratevi che l’agente ripulisca dopo aver terminato il proprio lavoro.
• Il divario di fiducia è salutare. In realtà, il grado di gradimento degli sviluppatori nei confronti degli strumenti di intelligenza artificiale cadde da 77% nel 2023 a circa 60% nel 2026, nonostante l’utilizzo continuasse a crescere. Non si tratta di pessimismo, ma di maturità. Il settore ha imparato a utilizzare questi strumenti senza fidarsi ciecamente di essi. Dovresti farlo anche tu.
• Il debug può prosciugare i tuoi risparmi. Una quota significativa di sviluppatori dichiara di spendere altro il tempo impiegato a correggere il codice generato dall’IA rispetto a quello che ci sarebbe voluto per scriverlo da soli — quasi sempre perché hanno accettato risultati che non capivano e hanno saltato i test. La soluzione è la stessa di sempre: piccoli passi, test costanti, revisione approfondita.

Nulla di tutto ciò è un motivo per evitare il "vibe coding". È un motivo per farlo come un professionista.

Uno stack di Vibe-Coding per Smart 2026 (il mio consiglio)

Se vuoi evitare di rimanere bloccato dall’eccesso di analisi, ecco una configurazione concreta che consiglierei volentieri a un principiante o lavorare a un progetto serio.

Lo stack di avvio snello e quasi gratuito

• Agente: OpenCode (gratuito, open source, indipendente dal modello) o Google Antigravity (gratuito in versione di anteprima).
• Modelli: GLM 5.2 tramite il piano di codifica da circa $10 al mese per la maggior parte del lavoro, oltre al livello gratuito di Ollama Cloud per le attività sporadiche ad alto volume.
• Metodo: il sistema "documentazione prima di tutto" descritto sopra. Non è negoziabile.
• Costo: più o meno il prezzo di un paio di caffè al mese.

Lo stack per sviluppatori seri (quello che uso io, in realtà)

• Agente principale: Claude Code, per le sue potenzialità intrinseche e per la sua programmabilità.
• Modello architettonico: Claude Opus 4.8 per le decisioni relative alle sollecitazioni strutturali.
• Modelli Workhorse: GLM 5.2 e Kimi K2.7: il codice per il lavoro quotidiano, integrato tramite una configurazione indipendente dal modello. Kimi è particolarmente indicato per sessioni autonome molto lunghe e senza supervisione, grazie alla sua efficienza in termini di token e al contesto da 256K.
• Livello economico/locale: Ollama Cloud (Pro) per inferenze ad alto volume e a basso rischio.
• Colla: MCP per gli strumenti e una rigorosa struttura di progetto basata sul principio “docs-first” che tiene insieme il tutto.

Qualunque cosa tu scelga, ricorda la lezione fondamentale: Lo strumento che scegli conta meno del flusso di lavoro che crei attorno ad esso. Un programmatore disciplinato che utilizza strumenti gratuiti supererà in termini di produttività uno sciatto che utilizza la suite di strumenti più costosa che il denaro possa comprare.

Domande frequenti

Nel 2026, una persona che non sa affatto programmare potrà davvero riuscire a creare qualcosa di concreto? Sì — è proprio questo il punto centrale dell’evoluzione degli strumenti. Anche chi non è un ingegnere riesce a rilasciare software funzionante semplicemente specificando l’intento e valutando i risultati. Servono comunque capacità di giudizio, pazienza e la volontà di comprendere a grandi linee cosa sta facendo l’IA, ma non è necessario scrivere codice a mano.

Il “vibe coding” è ancora attuale, oppure sta per essere sostituito dall'"ingegneria agenziale"? Stessa cosa, nome migliore. L“”ingegneria degli agenti“ non è altro che il ”vibe coding” applicato con disciplina: orchestrare gli agenti, definire i controlli di qualità e mantenere la supervisione umana nei punti critici. La maggior parte delle persone continua a usare il termine “vibe coding” nelle conversazioni; la pratica alla base si è semplicemente evoluta.

Qual è attualmente il miglior modello di intelligenza artificiale per la programmazione? Per quanto riguarda la massima qualità, Claude Opus 4.8 (88,61 TP3T su SWE-bench Verified) e GPT-5.5 sono i leader all’avanguardia. Per il miglior rapporto qualità-prezzo, i modelli open-weight come GLM 5.2 e Kimi K2.7-Code sono straordinariamente vicini alle prestazioni dei modelli di punta, ma a una frazione del costo. La soluzione più intelligente è utilizzarli entrambi: quelli di punta per i difficili 10%, quelli economici e resistenti per gli altri 90%.

Come posso scaricare musica in streaming gratuitamente (o quasi)? Utilizza un agente gratuito e open source come OpenCode, abbinalo al piano gratuito di Ollama Cloud o a un piano inferiore a $15 come il Coding Plan di GLM o Kimi Code, ed esegui modelli senza limiti di peso. Anche Google Antigravity è gratuito per gli utenti privati in versione preview. È possibile realizzare una quantità notevole di progetti al costo di un panino al mese.

Posso davvero creare una startup o un'app di grandi dimensioni in questo modo? Un vero e proprio prodotto completo e pronto per la produzione — sì, e ci sono persone che lo realizzano da sole continuamente. Un clone letterale di Google o Facebook su larga scala — no, quello richiede migliaia di ingegneri e un’infrastruttura su scala planetaria. L’obiettivo realistico e davvero entusiasmante è un prodotto ambizioso realizzato con standard di produzione da una sola persona o da un piccolo team, cosa che un tempo era impossibile.

Il codice generato dall'intelligenza artificiale è abbastanza sicuro da poter essere distribuito? Non di default. Il codice generato dall’IA è particolarmente soggetto a vulnerabilità, quindi è necessario rivederlo e sottoporlo a scansione, non lasciare mai che gli agenti gestiscano l’autenticazione o le credenziali senza supervisione e considerare tutti i risultati come non affidabili fino a quando non vengono verificati. Se si segue questa disciplina, il codice è perfettamente pronto per essere distribuito. Se invece si procede alla cieca, è una violazione in agguato.

Claude Code o Cursor: quale dovrebbe scegliere un principiante? Se vuoi l’agente più potente e ti trovi a tuo agio con un terminale, scegli Claude Code. Se invece preferisci vedere il tuo codice in un editor ben curato mentre dirigi l’IA, scegli Cursor. Molti usano entrambi. Entrambi sono ottimi punti di partenza; non tormentarti troppo sulla scelta.

Che cos’è Ollama Cloud e perché dovrei utilizzarlo? Ollama Cloud esegue modelli open source di grandi dimensioni su GPU di data center gestiti, così non è necessario disporre di hardware costoso, fornendo al contempo la stessa identica API utilizzata quando si esegue Ollama in locale: è quindi una soluzione immediatamente utilizzabile. Utilizzalo per un’inferenza rispettosa della privacy e a costi controllati, in particolare per lavori con volumi elevati, con un piano gratuito per iniziare.

Qual è la differenza tra AGENTS.md e CLAUDE.md? E Claude Code è in grado di leggere AGENTS.md? AGENTS.md è lo standard aperto e multipiattaforma (gestito dalla Linux Foundation e adottato da Codex, Cursor, Windsurf, Cline, Gemini CLI e oltre 30 altri progetti); CLAUDE.md è il file di istruzioni nativo di Claude Code. Il problema è che, a partire dalla metà del 2026, Claude Code non legge automaticamente AGENTS.md — se un repository contiene solo quel file, Claude Code non carica alcuna istruzione relativa al progetto e non visualizza alcun avviso. La soluzione consiste nel mantenere AGENTS.md come vostra fonte di riferimento condivisa e rendete CLAUDE.md un file di piccole dimensioni che lo importa con un solo @AGENTS.md riga (oppure creare un collegamento simbolico tra i due con ln -s AGENTS.md CLAUDE.md). Un unico file per il mondo, un file sottile per ogni strumento.

Come posso impedire a un agente IA di dimenticare il mio progetto tra una sessione e l'altra? Salva i file di memoria del progetto nel repository, non nella chat. Conserva un AGENTS.md per quanto riguarda le regole, a ROADMAP.md per il piano, un TASKS.md per il cursore corrente (completato / in corso / successivo) e un DECISIONS.md per le scelte bloccate. Fai in modo che l’agente legga tali informazioni all’inizio di ogni sessione e ne scriva gli aggiornamenti alla fine. Poiché sul disco si tratta esclusivamente di Markdown in formato semplice, il contesto rimane inalterato anche in caso di ripristino del contesto, sostituzione del modello e cambio di strumento.

E ora, cosa fare?

La programmazione Vibe nel 2026 non è una trovata pubblicitaria né una scorciatoia per i pigri. È una realtà concreta, potente e sempre più standard un modo di sviluppare software — che offre un enorme potenziale a chiunque sia disposto a imparare a gestirlo al meglio. La barriera alla creazione di software è crollata. La nuova barriera è costituita dal gusto, dal buon senso e dalla disciplina.

Quindi, oggi, inizia in piccolo. Scegli un agente, assegnagli un progetto reale e avvia il ciclo: descrivi, rivedi, ripeti, testa. Poi, quando sarai pronto a espanderti, imposta il sistema “documentazione prima di tutto”, in modo che il tuo progetto abbia una memoria e i tuoi agenti possano crescere insieme a te. Il divario tra “Ho un’idea” e «È online» non è mai stato così ridotto. L’unica domanda che rimane è: cosa realizzerai?.

---

Stai realizzando un progetto ambizioso e desideri il sistema di documentazione e prompt che permette alla programmazione collaborativa su larga scala di funzionare davvero? Si tratta di una guida a sé stante — e un’ottima lettura da non perdere su questo sito.