Prima che Claude Code scrivesse la prima riga di codice, versel Era già nel campo della codifica dither con il suo servizio v0.
L’idea di base alla base dell’originale v0, rilasciata nel 2024, era quella di essere essenzialmente la versione 0. Questa è stata la prima versione di un’app che ha aiutato gli sviluppatori a risolvere il problema della tela bianca. Gli sviluppatori potevano farsi strada in un’impalcatura di interfaccia utente (UI) di bell’aspetto, ma il codice era usa e getta. Mettere in produzione questi prototipi ha richiesto riscritture.
Più di 4 milioni di persone hanno utilizzato v0 per costruire milioni di prototipi, ma alla piattaforma mancavano gli elementi necessari per entrare in produzione. È una sfida familiare con gli strumenti di codifica jitter, poiché esiste un divario tra ciò che gli strumenti forniscono e ciò di cui hanno bisogno i costruttori aziendali. Codice ClaudioAd esempio, crea in modo efficace logica e script di backend ma non distribuisce interfacce utente di produzione all’interno dei sistemi di progettazione aziendale esistenti, applicando al contempo le policy di sicurezza.
Questo crea quello che Tom Occhino, CPO di Vercel, chiama "Il più grande problema dello shadow IT al mondo." La creazione di software basato sull’intelligenza artificiale è già in atto in ogni organizzazione. Le credenziali vengono copiate nei prompt. I dati aziendali confluiscono in strumenti non gestiti. Le applicazioni vengono distribuite all’esterno dell’infrastruttura approvata. Nessuna traccia di controllo.
Vercel ha ricostruito la v0 per risolvere questa vulnerabilità della distribuzione in produzione. La nuova versione, generalmente disponibile oggi, importa i repository GitHub esistenti ed estrae automaticamente variabili e configurazioni di ambiente. Genera codice in un runtime basato su sandbox che si associa direttamente alle distribuzioni Vercel reali e applica controlli di sicurezza e flussi di lavoro git appropriati, consentendo anche ai non ingegneri di inviare il codice alla produzione.
"La cosa veramente bella di V0 è che il codice è ancora visibile, rivedibile e gestibile." Occhino ha raccontato a VentureBeat in un’intervista esclusiva. "I team iniziano a collaborare sul prodotto, non su PRD e simili."
Questo cambiamento è importante perché la maggior parte del lavoro sul software aziendale viene svolto su applicazioni esistenti, non su nuovi prototipi. I team hanno bisogno di strumenti che si integrino con la codebase e l’infrastruttura esistenti.
In che modo il runtime sandbox di v0 collega il codice generato dall’intelligenza artificiale ai repository esistenti?
La versione originale v0 supportava l’interfaccia utente tramite prompt e consentiva agli utenti di scorrere le conversazioni. Ma il codice viveva nell’ambiente isolato di v0; Ciò significava copiare file, riscrivere le importazioni e collegare manualmente tutto insieme per spostarlo in produzione.
La v0 ricostruita cambia radicalmente questo importando direttamente i repository GitHub esistenti. Un runtime basato su sandbox importa automaticamente variabili di ambiente, distribuzioni e configurazioni da Vercel; quindi ogni richiesta produce codice pronto per la produzione che comprende già l’infrastruttura dell’azienda. Il codice risiede nel repository, non in uno strumento di prototipazione separato.
In precedenza v0 era un ambiente di prototipazione separato. Ora è collegato alla base di codice effettiva, con il codice VS completo integrato nell’interfaccia; Ciò significa che gli sviluppatori possono modificare direttamente il codice senza modificare gli strumenti.
Un nuovo pannello git gestisce comodi flussi di lavoro. Chiunque nel team può creare rami dall’interno della v0, aprire richieste pull rispetto al master ed eseguire il deploy durante l’unione. Le richieste pull sono cittadini di prima classe e le anteprime si associano direttamente alle implementazioni Vercel effettive, non a demo isolate.
Questo è importante perché i product manager e gli esperti di marketing possono ora inserire il codice di produzione attraverso comodi flussi di lavoro git senza bisogno di ambienti di sviluppo locali o consegnare snippet di codice agli ingegneri per l’integrazione. La nuova versione aggiunge anche integrazioni dirette con i database Snowflake e AWS; in questo modo i team possono connettere le applicazioni alle origini dati di produzione con controlli di accesso appropriati integrati, anziché richiedere lavoro manuale.
L’esperienza di Vercel con React e Next.js spiega l’infrastruttura di distribuzione di v0
Prima di entrare in Vercel nel 2023, Occhino ha lavorato come ingegnere presso Meta (ex Facebook) per una dozzina di anni, guidando lo sviluppo dell’azienda del framework React JavaScript ampiamente utilizzato.
L’affermazione di fama di Vercel è che il fondatore dell’azienda Guillermo Rauch è il creatore di Next.js, un framework full-stack costruito su React. Nell’era della codifica delle vibrazioni, Next.js è diventato un framework sempre più popolare. La società ha recentemente pubblicato un elenco. Reagire alle migliori pratiche È progettato specificamente per aiutare i rappresentanti AI e gli LLM a studiare.
La piattaforma Vercel comprende le migliori pratiche e gli insegnamenti di Next.js e React. Questo decennio di creazione congiunta di framework e infrastrutture significa che v0 fornisce codice pronto per la produzione che utilizza la stessa infrastruttura utilizzata da Vercel per milioni di distribuzioni all’anno. La piattaforma include supporto per flussi di lavoro mediati, integrazione MCP, firewall per applicazioni Web, SSO e protezioni per la distribuzione. I team possono aprire qualsiasi progetto in un ambiente di sviluppo cloud e inviare le modifiche all’anteprima di Vercel o alla distribuzione in produzione con un solo clic.
Questa è la base fondamentale di Occhino, poiché non mancano offerte competitive nello spazio del jitter coding, tra cui Replit, Lovable e Cursor, tra gli altri.
"Ciò che fa la differenza più grande per noi è l’infrastruttura Vercel." disse Occhino. "Negli ultimi 10 anni ha costruito infrastrutture gestite, infrastrutture definite dal quadro e ora infrastrutture autogestite."
Perché la sicurezza della codifica Vibe richiede il controllo dell’infrastruttura e non solo delle policy?
Il problema dell’IT ombra non è che i dipendenti utilizzino strumenti di intelligenza artificiale. La maggior parte degli strumenti di codifica dithering operano interamente al di fuori dell’infrastruttura aziendale. Poiché non esiste un modo sicuro per connettere il codice generato ai database aziendali, le credenziali vengono copiate nei prompt. Poiché gli strumenti non si integrano con le pipeline di distribuzione aziendale, le applicazioni vengono distribuite su URL pubblici. Le fughe di dati si verificano perché non sono presenti controlli di visibilità.
La sfida tecnica è che la protezione del codice generato dall’intelligenza artificiale richiede il controllo di dove viene eseguito il codice e a cosa può accedere. I documenti politici non saranno d’aiuto se lo strumento stesso non è in grado di applicare queste politiche.
Emerge qui l’importanza delle infrastrutture. Quando gli strumenti di codifica Vibe vengono eseguiti su piattaforme separate, le aziende si trovano di fronte a una scelta: bloccare del tutto gli strumenti o accettare i rischi per la sicurezza. I controlli di sicurezza possono essere applicati automaticamente quando lo strumento di codifica Vibe viene eseguito sulla stessa infrastruttura delle distribuzioni di produzione.
v0 gira sull’infrastruttura di Vercel; Ciò significa che le organizzazioni possono impostare protezioni di distribuzione, controlli di visibilità e policy di accesso che si applicano al codice generato dall’intelligenza artificiale nello stesso modo in cui si applicano al codice scritto a mano. L’integrazione diretta con i database Snowflake e AWS consente ai team di connettersi ai dati di produzione con controlli di accesso adeguati anziché copiare le credenziali nei prompt.
"I team IT si sentono a proprio agio con la struttura creata dai loro team perché hanno il controllo su chi ha accesso." disse Occhino. "Queste applicazioni hanno il controllo su ciò a cui possono accedere da Snowflake o dai suoi sistemi di dati."
Interfaccia utente produttiva e software produttivo
Oltre alla nuova versione di v0, Vercel ha recentemente introdotto una tecnologia di interfaccia utente produttiva. json-render.
v0 è ciò che Vercel chiama software produttivo. Ciò differisce dal framework di rendering json dell’azienda per un’interfaccia utente veramente produttiva. Chris Tate, ingegnere del software Vercel, ha spiegato che v0 crea applicazioni e agenti full stack, non solo interfacce utente o front-end. Al contrario, json-render è un framework che consente all’intelligenza artificiale di eseguire direttamente il rendering dei componenti dell’interfaccia utente emettendo JSON anziché codice in fase di runtime.
"L’intelligenza artificiale non scrive software," Tate ha detto a VentureBeat. "Si collega direttamente al livello di elaborazione per creare interfacce spontanee e personalizzate su richiesta."
Questa distinzione è importante per i casi d’uso aziendali. I team utilizzano v0 quando devono creare applicazioni complete, componenti personalizzati o software di produzione.
Utilizzano il rendering JSON per elementi dell’interfaccia utente dinamici e personalizzati all’interno delle applicazioni, dashboard che si adattano ai singoli utenti, widget contestuali e interfacce che rispondono alla modifica dei dati senza modifiche del codice.
Entrambi sfruttano l’infrastruttura AI SDK integrata di Vercel per lo streaming e gli output strutturati.
Tre lezioni che le aziende hanno imparato adottando la codifica dither
Poiché negli ultimi due anni le aziende hanno adottato strumenti di codifica jitter, sono emersi diversi modelli relativi ai codici generati dall’intelligenza artificiale negli ambienti di produzione.
Lezione 1: La prototipazione senza implementazione in produzione crea progressi imprecisi. Le organizzazioni hanno visto i team creare demo impressionanti nelle prime versioni della v0 e poi scontrarsi con un muro quando hanno spostato tali demo in produzione. Il problema non era la qualità del codice generato. I prototipi vivevano in ambienti isolati e disconnessi dall’infrastruttura produttiva.
"Sebbene le demo siano facili da creare, penso che la maggior parte dell’iterazione che avviene in queste basi di codice avviene nelle applicazioni di produzione reali." disse Occhino. "Il 90% di ciò che dobbiamo fare è apportare modifiche al codice base esistente."
Lezione 2: Il ciclo di vita dello sviluppo software è già cambiato, indipendentemente dal fatto che le aziende lo pianifichino o meno. Gli esperti di dominio sviluppano il software direttamente anziché scrivere documenti sui requisiti del prodotto (PRD) che gli ingegneri devono interpretare. I product manager e gli esperti di marketing forniscono funzionalità senza attendere sprint di progettazione.
Questo cambiamento significa che le organizzazioni necessitano di strumenti che consentano ai non tecnici di inviare documenti mantenendo allo stesso tempo la visibilità e la gestione del codice. L’alternativa è creare colli di bottiglia forzando tutto il codice generato dall’intelligenza artificiale attraverso flussi di lavoro di sviluppo tradizionali.
Lezione 3: La disabilitazione degli strumenti di codifica del jitter non interrompe la codifica del jitter. Ciò semplicemente spinge l’attività fuori dalla visibilità dell’IT. Le aziende che cercano di limitare lo sviluppo basato sull’intelligenza artificiale continuano a trovare dipendenti che utilizzano gli strumenti, creando un problema IT ombra su larga scala.
L’implicazione pratica è che le organizzazioni dovrebbero concentrarsi meno sul fatto che la codifica jitter sia consentita e più sulla garanzia che avvenga all’interno di un’infrastruttura in grado di applicare le politiche di sicurezza e implementazione esistenti.
