Tutorial di Kimi Vibe Coding: creare un prodotto senza scrivere codice è più facile, ma pubblicarlo non lo è

Kimi ha trasformato un flusso di lavoro un tempo tecnico in uno conversazionale, ma il cambiamento crea un nuovo conflitto tra costruire rapidamente e pubblicare in modo responsabile. Questo tutorial di Kimi vibe coding esamina tale conflitto attraverso un percorso completo di prodotto, da una specifica iniziale a una distribuzione pubblica.

Il cambiamento importante non è che un modello di IA possa generare una landing page. Gli agenti di coding ora possono ispezionare i file di progetto, modificare diversi componenti, eseguire comandi, avviare test e adattare i loro piani dopo gli errori. Kimi Code, Qwen Code e i servizi di coding basati su GLM portano questo flusso di lavoro all'interno di terminali e ambienti di sviluppo.

Ciò mette chi crea per la prima volta in una posizione insolita. Può produrre più software prima di comprendere i sistemi sottostanti. Tuttavia, hosting, autenticazione, database, sicurezza, configurazione del dominio e obblighi normativi continuano a comportarsi come problemi di ingegneria.

Andrej Karpathy ha dato a questa pratica un nome memorabile nel febbraio 2025. La sua descrizione sottolineava l'accettazione delle modifiche generate e il dimenticare temporaneamente che il codice esistesse. Questo atteggiamento funzionava per progetti sperimentali del fine settimana, ma un prodotto pubblico impone uno standard diverso.

La domanda utile non è più se una persona senza esperienza di programmazione possa creare un'applicazione. Può farlo. La domanda più difficile è se possa comprendere, testare, gestire e ripristinare l'applicazione dopo che un agente l'ha creata.

Gli agenti di coding Kimi ora gestiscono più della generazione di codice

Il passaggio da assistente chat ad agente di coding cambia chi può avviare un progetto software, ma non rimuove la responsabilità dal creatore.

Un modello chat di solito restituisce testo o esempi di codice isolati. Un agente di coding può lavorare all'interno di un progetto, ispezionarne la struttura, modificare file, eseguire comandi e osservare l'output risultante. Questo ciclo di feedback consente al sistema di continuare dopo la prima risposta.

La distinzione è importante per un creatore non tecnico. Copiare codice tra un browser e un editor richiede di sapere dove appartiene ogni frammento. Un agente può individuare i file pertinenti e coordinare le modifiche tra interfaccia, server, database e configurazione.

Kimi descrive il suo client da riga di comando come un agente in grado di leggere e modificare il codice, cercare file, eseguire comandi shell e rivedere il proprio piano in base al feedback. La sua attuale guida di Kimi Code spiega inoltre come il client possa generare un file AGENTS.md dopo aver analizzato un progetto.

Quel file agisce come contesto operativo per l'agente. Può registrare la struttura del progetto, i comandi di build, le convenzioni e altre istruzioni che dovrebbero persistere tra le attività. L'agente ottiene una mappa invece di trattare ogni prompt come una richiesta isolata.

Qwen Code segue un modello simile. La sua panoramica dell'agente descrive uno strumento per terminale che trasforma istruzioni di prodotto in codice e supporta l'uso scriptato e non interattivo. Può inoltre connettersi tramite diverse opzioni di autenticazione e fornitori di modelli.

Questi prodotti rappresentano un cambiamento più ampio nell'interfaccia dello sviluppo software. L'utente descrive comportamento, vincoli e criteri di accettazione. L'agente traduce quell'intento in file, comandi e test.

Tuttavia, il linguaggio naturale non è una specifica completa. Una richiesta come “crea un portale clienti” lascia senza risposta domande critiche. Non dice nulla sul recupero dell'account, sulle autorizzazioni di accesso, sulla conservazione dei dati, sui pagamenti non riusciti, sui registri di audit o sulla prevenzione degli abusi.

Un ingegnere esperto nota queste lacune perché assomigliano a guasti precedenti. Un principiante spesso vede l'interfaccia visibile e presume che il sistema sia quasi finito. Gli agenti di coding comprimono il tempo di implementazione, ma possono anche nascondere decisioni incomplete dietro una schermata rifinita.

La guida cinese proveniente da AIHOT coglie bene questo nuovo flusso di lavoro. Presenta modelli nazionali, inclusi Kimi, GLM e Qwen, come percorsi accessibili da un'idea a un prodotto online. Il suo consiglio più forte appare verso la fine: un creatore può evitare di scrivere codice, ma non può evitare di comprendere l'architettura.

Questa distinzione dovrebbe definire qualsiasi serio tutorial di Kimi vibe coding. L'agente può eseguire attività, mentre l'essere umano rimane responsabile della definizione del sistema e della valutazione del suo funzionamento.

Una specifica di prodotto deve venire prima del primo prompt

Un'idea vaga produce una demo persuasiva, mentre una specifica delimitata dà all'agente la possibilità di produrre un prodotto gestibile.

Il primo risultato non dovrebbe essere il codice. Dovrebbe essere una breve specifica di prodotto che copra utenti, attività, dati, autorizzazioni, stati di errore e criteri di successo. Questo documento diventa il riferimento quando l'agente inizia a formulare ipotesi.

Inizia con un utente e un'attività. “I freelance devono trasformare gli appunti delle riunioni in messaggi di follow-up per i clienti” è più attuabile di “crea una piattaforma di produttività IA”. L'affermazione più ristretta identifica un input, una trasformazione e un output.

Poi, definisci il percorso completo più piccolo. Un utente crea un account, importa una nota, rivede un follow-up generato, lo modifica ed esporta il risultato. Ogni passaggio dovrebbe includere ciò che l'utente vede e cosa accade quando l'azione fallisce.

I dati meritano una sezione dedicata. Elenca ogni tipo di informazione che l'applicazione memorizza, da dove proviene, chi può leggerla e quando dovrebbe essere eliminata. I documenti sensibili richiedono misure di protezione diverse dai dati di catalogo pubblici.

Anche le autorizzazioni richiedono un linguaggio esplicito. Un amministratore, un utente normale e un visitatore anonimo non dovrebbero condividere le stesse capacità. Se il prodotto supporta i team, specifica se i membri possono visualizzare i record degli altri e chi può rimuovere l'accesso.

Quindi definisci il sistema come diversi componenti:

• L'interfaccia visualizza schermate, moduli, navigazione e feedback.

• Il servizio applicativo applica le regole aziendali e coordina le richieste.

• Il database memorizza utenti, record, autorizzazioni e stato.

• L'autenticazione verifica l'identità e controlla le sessioni.

• I servizi esterni forniscono e-mail, pagamenti, inferenza IA o archiviazione di file.

• L'hosting rende disponibile l'applicazione e fornisce log, rete e backup.

Un principiante non deve conoscere ogni dettaglio di implementazione prima di iniziare. Deve riconoscere questi componenti e chiedersi dove risieda ogni responsabilità. Altrimenti, l'agente può combinare silenziosamente responsabilità non correlate in codice fragile.

La modalità di pianificazione è utile in questa fase. Invece di chiedere all'agente di creare subito, chiedigli di ispezionare la specifica, individuare le decisioni mancanti, proporre un'architettura e dividere il lavoro in traguardi.

Il piano dell'agente dovrebbe indicare le principali entità di dati, route, dipendenze e strategia di test. Dovrebbe inoltre dichiarare le ipotesi. Le ipotesi nascoste diventano costose quando diverse funzionalità dipendono da esse.

Chiedi all'agente di descrivere l'architettura senza codice. Se la spiegazione resta confusa, il prodotto non è pronto per un'implementazione autonoma. Rielabora il piano finché non riesci a spiegare il flusso delle richieste in linguaggio semplice.

I prompt utili definiscono prove, non entusiasmo. “Aggiungi il login” è incompleto. “Aggiungi il login via e-mail, rifiuta le sessioni scadute, impedisci agli utenti di accedere ai record di un altro account e scrivi test per questi casi” crea requisiti osservabili.

La stessa disciplina si applica al lavoro sull'interfaccia. Descrivi stati vuoti, stati di caricamento, errori di convalida, schermi piccoli, navigazione da tastiera e azioni distruttive. Una dashboard generata che gestisce solo dati ideali è ancora un mockup.

I creatori possono conservare requisiti, note delle fonti, decisioni sui modelli e osservazioni sui test all'interno di un ambiente ricercabile flusso di lavoro IA. Questo contesto diventa prezioso quando un agente chiede perché sia stata presa una precedente scelta architetturale.

Una specifica cambierà durante lo sviluppo. È normale. La regola importante è aggiornare il documento sorgente prima di chiedere all'agente di implementare la nuova direzione.

Il tutorial di Kimi Vibe Coding dal piano alla realizzazione funzionante

Il flusso di lavoro agentico più sicuro utilizza piccoli traguardi verificabili invece di un unico prompt che richiede un'intera applicazione.

Crea il progetto in un repository sottoposto a controllo di versione prima che inizi l'implementazione principale. Il controllo di versione registra le modifiche come commit, consentendo a chi sviluppa di confrontare le revisioni e recuperare uno stato precedente. Il commit iniziale dovrebbe contenere la specifica e uno scheletro minimo del progetto.

Chiedi all'agente di proporre uno stack tecnologico basato sulla semplicità operativa. La risposta dovrebbe spiegare perché esiste ciascun componente, come verrà distribuito e quali alternative sono state scartate. Evita di scegliere un framework solo perché il modello lo ha generato per primo.

Il primo traguardo dovrebbe stabilire lo scheletro dell'applicazione. Include il comando di sviluppo, la configurazione dell'ambiente, la navigazione di base, un controllo di integrità e un comando di test. Nessuna funzionalità di business dovrebbe procedere finché un altro ambiente pulito non riesce a eseguire quello scheletro.

Il secondo traguardo dovrebbe implementare il modello dati principale. Chiedi all'agente di mostrare le entità, le loro relazioni e le regole di proprietà prima di generare le migrazioni. Una migrazione è una modifica controllata del database che può essere applicata in modo coerente nei vari ambienti.

Rivedi lo schema in linguaggio semplice. Quale record appartiene a quale utente? Cosa succede quando un account viene eliminato? Due record possono fare accidentalmente riferimento a dati mancanti? Le risposte rivelano se il modello sottostante corrisponde al prodotto.

Il terzo traguardo aggiunge autenticazione e autorizzazione. L'autenticazione risponde a chi è l'utente. L'autorizzazione risponde a ciò che quell'utente può fare. Molte applicazioni generate implementano la prima trattando la seconda come una questione di interfaccia.

L'autorizzazione deve essere applicata dal server per ogni operazione protetta. Nascondere un pulsante non è un controllo degli accessi. Un utente malintenzionato o curioso può inviare richieste senza usare l'interfaccia prevista.

Il quarto traguardo implementa un percorso di prodotto completo. Resisti all'aggiunta di pagine delle impostazioni, pannelli analitici o perfezionamenti visivi prima che il percorso principale funzioni. Una sezione verticale ristretta evidenzia prima i problemi di integrazione.

Dopo ogni attività, richiedi all'agente di riassumere:

• I file che ha modificato

• Il comportamento che ha aggiunto

• Le ipotesi che ha formulato

• I test che ha eseguito

• I test che richiedono ancora il giudizio umano

• Qualsiasi conseguenza sulla sicurezza o sulla distribuzione

Esegui l'applicazione dopo ogni traguardo. Prova prima il comportamento previsto, poi usala in modo improprio. Invia moduli vuoti, input sovradimensionati, richieste duplicate, sessioni scadute, URL non validi e l'identificatore del record di un altro utente.

Quando qualcosa non funziona, segnala il comportamento osservato invece di chiedere all'agente di “risolvere tutto”. Includi il comando, il risultato atteso, il risultato effettivo e l'output di log pertinente. Un feedback preciso aiuta il modello a distinguere un difetto da un requisito frainteso.

Non accettare riscritture ampie come risposta predefinita a un bug locale. Chiedi una spiegazione della causa principale e una patch minima. Le grandi modifiche generate sono più difficili da rivedere e possono rimuovere comportamenti funzionanti.

Effettua un commit dopo ogni traguardo verificato. Usa descrizioni che indichino la modifica al prodotto, non la cronologia della conversazione. Una cronologia pulita ti consente di tornare a uno stato noto quando un agente introduce diversi errori collegati.

Avvia una nuova sessione dell'agente quando il contesto diventa confuso. Fornisci alla nuova sessione la specifica, l'architettura, il traguardo attuale e lo stato verificato del repository. Le conversazioni lunghe possono conservare ipotesi obsolete dopo che il prodotto è cambiato.

Questo approccio graduale sembra più lento della generazione in un solo passaggio. In pratica, riduce il costoso ciclo in cui un'applicazione rifinita crolla durante la distribuzione. L'obiettivo non è il massimo output di codice per prompt, ma il massimo progresso verificato per modifica.

La distribuzione trasforma una demo in un sistema operativo

La pubblicazione aggiunge compiti di infrastruttura, identità, regolamentazione e ripristino che l'agente di programmazione non può assumersi personalmente.

Un'applicazione locale funziona su una macchina in condizioni favorevoli. Una distribuzione pubblica riceve traffico imprevedibile, richieste malformate, scansioni automatizzate e dati reali degli utenti. Quell'ambiente cambia il significato di “funzionante”.

Separa gli ambienti di sviluppo e produzione. Lo sviluppo è lo spazio per la sperimentazione. La produzione è il sistema da cui dipendono gli utenti reali. Non dovrebbero condividere lo stesso database, le stesse credenziali o un accesso amministrativo illimitato.

Archivia la configurazione tramite variabili d'ambiente o un servizio gestito per i segreti. Non inserire mai password del database, chiavi API o segreti di firma nei file sorgente. Chiedi all'agente di analizzare la cronologia del repository alla ricerca di credenziali inserite accidentalmente prima del lancio.

Scegli l'hosting in base ai componenti dell'applicazione. Un'interfaccia statica, un server a esecuzione prolungata, un processo pianificato e un database relazionale hanno requisiti diversi. Il piano di distribuzione dovrebbe identificare come ciascun componente si avvia, comunica, registra gli errori e si riavvia.

Un dominio aggiunge un ulteriore livello. I suoi record DNS indirizzano gli utenti verso il servizio di hosting, mentre TLS cifra le connessioni. Il prodotto necessita anche di una strategia per reindirizzare le forme alternative del dominio e rinnovare i certificati.

I prodotti ospitati nella Cina continentale possono essere soggetti a ulteriori obblighi di registrazione. Le norme ICP riviste della Cina norme di registrazione ICP affermano che i servizi di informazione internet non commerciali forniti all'interno del Paese devono completare le procedure di registrazione.

Le norme affermano inoltre che le domande complete dovrebbero ricevere una decisione sulla registrazione entro 20 giorni lavorativi. Si tratta di un massimo normativo, non della promessa che ogni lancio si concluderà secondo un calendario fisso. Chi sviluppa dovrebbe trattare la registrazione come un filone di lavoro iniziale.

L'obbligo esatto dipende dal servizio, dalla configurazione dell'hosting, dal modello di business e dalla giurisdizione. Un agente di programmazione può organizzare i requisiti, ma non può fornire un'autorizzazione legale autorevole. Consulta il fornitore pertinente e consulenti legali qualificati quando l'ambito è incerto.

La distribuzione necessita anche di controlli sulle migrazioni del database. Esegui il backup dei dati di produzione prima di applicare una modifica distruttiva. Testa la migrazione su dati rappresentativi e documenta come annullarla.

Crea una checklist di rilascio che copra il successo della build, i test automatizzati, i controlli di sicurezza, le migrazioni, la configurazione, il monitoraggio e il rollback. Ogni elemento dovrebbe produrre evidenze anziché una garanzia verbale dell'agente.

I log dovrebbero indicare cosa non è riuscito, quando non è riuscito e quale operazione è stata interessata. Non dovrebbero esporre password, token, documenti privati o informazioni personali non necessarie. Registrare più dati non è automaticamente più sicuro.

Il monitoraggio dovrebbe coprire la disponibilità di base, gli errori del server, la latenza, i processi in background non riusciti e i limiti di archiviazione. Un avviso necessita di un responsabile umano e di un percorso di risposta. Una notifica che nessuno comprende è solo rumore aggiuntivo.

I backup necessitano di test di ripristino. Un processo di backup riuscito dimostra che i dati sono stati copiati da qualche parte. Non dimostra che il prodotto possa riprendersi entro un periodo accettabile.

Prima di invitare gli utenti, crea un percorso di rollback. Potrebbe significare ripristinare la versione precedente, disabilitare una nuova funzionalità o annullare una migrazione. Il team dovrebbe sapere quale azione si applica a ogni probabile errore.

È qui che la descrizione “no-code” diventa fuorviante. Chi sviluppa potrebbe non digitare l'implementazione, ma gestisce comunque un sistema con responsabilità tecniche e organizzative.

Il codice generato dall'IA necessita di protezione dei branch e test avversariali

La fiducia di un agente non è una prova che un prodotto sia sicuro, corretto o pronto per la produzione.

Il Stack Overflow Developer Survey 2025 ha rilevato un chiaro divario di fiducia riguardo all'output dell'IA. Sebbene l'84 percento degli intervistati utilizzasse o pianificasse di utilizzare strumenti di IA, il 46 percento ne diffidava dell'accuratezza. Solo il 33 percento ha espresso fiducia.

Lo stesso sondaggio tra sviluppatori ha rilevato che il 66% era frustrato da soluzioni di IA quasi corrette. Un ulteriore 45% ha identificato il debugging dispendioso in termini di tempo del codice generato come una grande frustrazione.

Queste cifre non dimostrano che gli agenti di coding non abbiano valore. Mostrano perché la verifica deve crescere di pari passo con l'adozione. Una generazione più rapida può creare un onere di revisione maggiore quando le modifiche si estendono a parti poco familiari di un sistema.

Proteggi il branch principale dopo la configurazione iniziale del progetto. La funzionalità di GitHub protezione del branch può richiedere pull request, controlli di stato superati, discussioni risolte o revisioni approvate prima che una modifica venga unita.

Anche un singolo sviluppatore può beneficiare di questa struttura. L'agente lavora su un branch separato, vengono eseguiti controlli automatici e lo sviluppatore esamina il riepilogo prima dell'unione. La pausa crea un confine tra generazione e rilascio.

Come minimo, la pipeline automatizzata dovrebbe installare le dipendenze da un file bloccato, compilare l'applicazione, eseguire i test e svolgere controlli orientati alla sicurezza. Un errore dovrebbe bloccare l'unione invece di diventare un avviso sepolto nei log.

I test dovrebbero operare a più livelli:

• I test unitari verificano regole di business isolate.

• I test di integrazione verificano la comunicazione con database e servizi esterni.

• I test end-to-end esercitano percorsi utente completi.

• I test di autorizzazione confermano che un account non possa accedere ai dati di un altro account.

• I test di migrazione verificano che le modifiche allo schema preservino i record esistenti.

• I test manuali esaminano l'usabilità, output ambigui e comportamenti imprevisti.

Chiedi all'agente di scrivere test prima di correggere un difetto confermato. Il test non riuscito cattura il problema e riduce la probabilità che si ripresenti. Richiedi poi che lo stesso test abbia esito positivo dopo la patch.

La sicurezza richiede un passaggio separato di modellazione delle minacce. Un modello delle minacce identifica risorse di valore, possibili aggressori, punti di ingresso esposti e probabili abusi. Trasforma “rendilo sicuro” in un insieme di domande concrete.

Cosa succede se un utente modifica un identificatore in una richiesta? Il contenuto caricato può eseguire codice? Il server recupera URL esterni? I ripetuti tentativi di password possono continuare senza limiti? Le route amministrative verificano i ruoli sul server?

OWASP avverte che i sistemi generati dall'IA o sviluppati da cittadini possono riutilizzare componenti vulnerabili e persino fare riferimento a pacchetti inesistenti. Le sue linee guida sui componenti non attendibili raccomandano di trattare le dipendenze generate come elementi che richiedono verifica.

Ispeziona ogni nuova dipendenza. Conferma che il pacchetto esista, provenga dal publisher previsto, riceva manutenzione e svolga uno scopo necessario. Un nome di pacchetto plausibile non è una prova di legittimità.

Usa un lockfile delle dipendenze ed evita pacchetti non necessari. Meno dipendenze riducono il numero di componenti esterni che possono guastarsi, cambiare proprietario o introdurre vulnerabilità.

Il codice di autenticazione generato merita un controllo speciale. L'archiviazione delle password, la gestione delle sessioni, i flussi di reimpostazione, le impostazioni dei cookie e i controlli di autorizzazione contengono dettagli sensibili per la sicurezza. Preferisci implementazioni consolidate e documentate alla logica personalizzata.

Non usare mai dati reali dei clienti durante i test iniziali. Genera record sintetici che assomiglino alla struttura necessaria senza esporre informazioni personali. Limita l'accesso alla produzione anche quando una sola persona gestisce il progetto.

Le funzionalità IA creano rischi aggiuntivi. Se il contenuto utente entra in un prompt del modello, tratta quel contenuto come non attendibile. Può tentare di sovrascrivere le istruzioni, rivelare contesto nascosto o attivare strumenti indesiderati.

Un agente con accesso a file e comandi dispone inoltre di significativi privilegi locali. Esamina le azioni richieste, limita le credenziali ed evita di concedere accesso alla produzione durante lo sviluppo ordinario. La comodità non dovrebbe cancellare i confini operativi.

Un fondatore non tecnico dovrebbe organizzare una revisione indipendente prima di lanciare un prodotto che gestisce denaro, informazioni sanitarie, documenti riservati o dati di identità sensibili. L'agente che ha generato il codice non dovrebbe essere l'unico revisore del proprio lavoro.

Cosa dovrebbero monitorare gli sviluppatori dopo il lancio

Il test decisivo per il vibe coding non è se un agente riesca a pubblicare la versione uno, ma se l'essere umano riesca a gestire la versione due.

Il primo segnale è l'affidabilità delle modifiche. Monitora con quale frequenza una funzionalità richiesta supera i test, raggiunge la produzione e rimane attiva senza rollback. Reversioni frequenti suggeriscono che l'architettura o il processo di verifica non riescono a sostenere la velocità dell'agente.

Il secondo segnale è la titolarità degli incidenti. Quando compare un avviso, lo sviluppatore dovrebbe identificare il componente interessato, ispezionare i log pertinenti e spiegare il percorso dell'errore. La dipendenza totale dalla risposta di un altro agente lascia il prodotto senza una diagnosi responsabile.

Il terzo segnale è la portabilità del modello. Kimi, Qwen, GLM e altri sistemi di coding continueranno a modificare i loro client, modelli, metodi di autenticazione e limiti. Un repository con documentazione chiara e strumenti standard può passare più facilmente da un agente all'altro.

La portabilità del modello non significa che ogni agente produca codice identico. Significa che i requisiti, l'architettura, i comandi e i test del progetto sono sufficientemente espliciti affinché un altro strumento o ingegnere possa continuare il lavoro.

Gli sviluppatori dovrebbero anche monitorare il divario tra output visibile e qualità operativa. Le nuove schermate dell'interfaccia sono facili da dimostrare. Tassi di errore inferiori, migrazioni più sicure, ripristino più rapido e autorizzazioni più chiare sono meno visibili ma più importanti.

Questo tutorial sul vibe coding con Kimi si conclude quindi con una definizione diversa di successo. Il successo non è raggiungere un URL attivo senza toccare un linguaggio di programmazione. È raggiungere un sistema attivo il cui comportamento, dati, rischi e percorso di ripristino puoi spiegare.

Inizia con un percorso utente e scrivine i requisiti prima di aprire l'agente di coding. Fai pianificare all'agente, implementare una milestone e fornire evidenze dai test. Esegui il commit solo delle modifiche verificate, poi sviluppa controlli di distribuzione e ripristino prima di invitare utenti reali.

Se non riesci a spiegare dove viene verificata l'identità, dove risiedono i dati o come viene annullato un rilascio non riuscito, sospendi il lancio. Chiedi all'agente di mappare quei sistemi finché le risposte non diventano chiare. Il vibe coding può ridurre il costo dell'implementazione, ma non può trasferire la responsabilità del prodotto a un modello.