Què és v0
v0 és el constructor d’aplicacions amb IA de Vercel. Converteix instruccions, referències visuals i codi existent en interfícies i aplicacions que es poden revisar, modificar i desplegar. L’abast inclou tant la part visible com connexions i lògica de servidor; no és únicament un generador d’imatges de pantalles.
La distinció útil és entre intenció, implementació i servei operatiu. Una petició descriu allò que es vol; el codi proposa com fer-ho; el servei ha de demostrar que funciona amb les seves dades, usuaris i condicions reals. v0 escurça el recorregut entre aquestes etapes, però no les converteix en equivalents. També pot intervenir en un projecte existent, de manera que importa delimitar què s’autoritza a canviar.
Documentació de referència: What is v0?.
Història i evolució del producte
Vercel va anunciar el pas de v0 d’alfa a beta l’11 d’octubre de 2023, inicialment centrat en interfícies amb React, Tailwind CSS i shadcn/ui. La disponibilitat general va arribar el 2024, segons la retrospectiva del proveïdor.
L’11 d’agost de 2025, v0.dev va passar a v0.app, acompanyat de funcions de planificació, recerca i depuració. El 3 de febrer de 2026 es va presentar una renovació orientada a repositoris existents i execució en sandbox. Al març es va anunciar la incorporació de l’equip de new.website per desenvolupar eines i integracions. Aquesta incorporació expressa una direcció de producte; no acredita que totes les funcions promeses estiguessin disponibles aquell mateix dia.
Documentació de referència: Announcing v0: Generative UI · v0.dev becomes v0.app · Introducing the new v0 · new.website joins forces with v0.
Com combina models, eines i execució
Vercel descriu un procés que combina instruccions dinàmiques, transformacions durant la generació anomenades LLM Suspense i correccions automàtiques. La mètrica de generació satisfactòria es refereix a obtenir una web que es renderitza a la vista prèvia. No equival a demostrar que una aplicació resol correctament tots els requisits.
Els xats basats en màquina virtual utilitzen un sandbox amb Node.js, fitxers, ordres i servidor de desenvolupament. Està separat de la producció. Aquesta separació permet inspeccionar un canvi abans de fer-lo públic, però no implica que tots els serveis externs connectats siguin de prova. Un entorn aïllat que rep credencials amb permisos amplis encara pot actuar sobre recursos reals.
Documentació de referència: How we made v0 an effective coding agent · Sandbox.
Entrades i especificació del comportament
Es poden aportar fitxers i captures perquè v0 analitzi composició, colors i components. La documentació adverteix que també infereix funcionament a partir dels elements visibles. Una captura mostra un estat, no les regles completes d’una aplicació.
Un encàrrec útil descriu què rep cada pantalla, què retorna i què passa si falta informació. Per a un filtre, especificar si combina criteris, conserva la selecció en canviar d’idioma i mostra un estat sense coincidències. Per a un formulari, identificar camps obligatoris, errors i destinació de l’enviament. Demanar «igual que aquesta imatge» pot resoldre l’aparença i deixar sense definir justament el comportament que necessita l’usuari.
Documentació de referència: Screenshots and Files.
Disseny visual i components reutilitzables
Design Systems 2.0 permet desar un sistema de disseny com una skill que orienta l’ús de components, tokens i convencions reals. Pot partir de paquets, repositoris, documentació i referències de Figma. El propòsit és reutilitzar regles de disseny, no dependre que cada conversa recordi una aparença.
En un projecte de Sabentis, l’encàrrec hauria d’especificar el blau corporatiu #2A62FE, els actius autoritzats i les variants dels components. Després se’n comprova l’ús real: contrast, focus visible, etiquetes i comportament amb textos llargs. La coherència visual no es valida només mirant la portada; les pantalles d’error i els estats buits també formen part del producte.
Documentació de referència: Design Systems 2.0.
Codi, branques i revisió de canvis
En connectar GitHub, el repositori passa a ser la referència del codi. v0 crea una branca de treball a partir de la branca base i hi envia els canvis generats. El flux permet consultar diferències, comprovacions i sol·licituds d’integració abans de publicar.
L’equip ha de llegir les diferències amb un objectiu concret: detectar canvis fora de l’abast, recursos eliminats i modificacions de permisos. Una correcció d’estil no hauria d’introduir una base de dades nova sense una necessitat explícita. Mantenir requisits i exemples amb el projecte facilita explicar per què s’accepta un canvi. L’historial resulta útil quan diverses persones treballen sobre el mateix producte i una millora visual afecta una funció existent.
Documentació de referència: GitHub.
Vista prèvia, publicació i operació
Les vistes prèvies de branques tenen URL pròpies; publicar actualitza el desplegament de producció i l’adreça estable. En el flux documentat amb GitHub, la publicació integra la sol·licitud de canvis a la branca base. Desar, revisar i publicar són estats diferents.
Abans de publicar, comprovar domini, visibilitat i connexions de l’entorn. Després, obrir l’URL final i repetir les accions essencials: una compilació correcta no prova que els enllaços, formularis i permisos públics siguin els esperats. També cal definir qui rep incidències, com es restaura una versió anterior i qui manté dependències i contingut. El botó de publicació acaba una fase de construcció, però inicia una fase d’operació.
Documentació de referència: Deployments · GitHub.
Dades, API i connexions MCP
v0 integra persistència mitjançant proveïdors de bases de dades i emmagatzematge; documenta connexions com Neon, Supabase, Upstash, Vercel Blob i Snowflake. En integracions SQL pot generar i executar operacions que creen, modifiquen o eliminen taules. MCP afegeix eines de servidors externs i serveis del Marketplace.
Convé classificar cada connexió pel que permet fer, no només pel nom del servei. Llegir un catàleg, modificar-lo i enviar informació a tercers són capacitats diferents. Per a un prototip, utilitzar dades fictícies i permisos acotats permet provar el flux sense confondre’l amb un registre operatiu. El contracte d’entrada i sortida ha d’incloure errors i absència de dades, a més del cas en què tot respon correctament.
Documentació de referència: Databases · MCP Integrations.
Web, iOS i accés programàtic
Vercel va descriure l’aplicació iOS el novembre de 2025: es va construir amb React Native i Expo i es va plantejar al voltant de la conversa, sense buscar paritat completa amb la web. L’API renovada es va anunciar com a disponible de manera general el 5 d’agost de 2026, amb xats que mantenen l’estat d’una aplicació i retornen vistes prèvies.
L’API permet incorporar la generació a un altre producte o procés. Això afegeix responsabilitats: relacionar cada petició amb el seu projecte, conservar resultats i controlar qui pot desplegar. Un procés automàtic no ha d’interpretar una vista prèvia nova com una ordre de publicació. Per treballar amb mòbil, reservar una revisió en pantalla ampla quan calgui inspeccionar taules, diferències de codi o diversos estats d’una interfície.
Documentació de referència: How we built the v0 iOS app · Introducing the new v0 API.
Plans, models i costos d'ús
La documentació consultada distingeix Free, Plus, Business i Enterprise; també manté Premium, en retirada i tancat a nous usuaris. El consum depèn de crèdits i del treball generat, no d’una quantitat fixa d’aplicacions acabades. La selecció de models depèn del pla i de la configuració de l’espai; Enterprise afegeix control del propietari sobre models personalitzats.
La comparació econòmica ha d’incloure generació, desplegament i serveis connectats. Una subscripció al constructor no converteix en gratuïts l’emmagatzematge, el domini o qualsevol API incorporada. Per estimar un projecte, mesurar una tasca representativa amb les revisions, registrar consum i separar la construcció inicial del manteniment. Les ofertes de crèdits i els límits canvien; comprovar-los al compte abans de comprometre una cadència de treball.
Documentació de referència: Pricing · Choosing models.
Dades, propietat del codi i seguretat
La política d’IA efectiva el març de 2026 vincula l’ús per a entrenament al pla i les preferències; n’exclou les dades de clients Enterprise. La documentació distingeix secrets de servidor i variables NEXT_PUBLIC_, exposades al navegador. Vercel indica que no reclama la propietat del codi generat, tot i que pot contenir errors o similituds amb material de tercers.
Per tant, propietat, privacitat i seguretat són comprovacions separades. Tenir dret a utilitzar una sortida no demostra que les dependències estiguin ben llicenciades ni que el formulari protegeixi les dades. Abans d’introduir material intern, verificar les preferències efectives de l’equip i l’abast de cada proveïdor connectat. Els secrets s’han de gestionar com a configuració, no copiar-los a les instruccions ni incloure’ls en fitxers públics.
Documentació de referència: Vercel AI Policy · Security · FAQs.
Reconeixement i un incident del proveïdor
v0 va obtenir el Webby de 2025 en Developer Tools. És un reconeixement del producte, no una certificació de la seguretat de les aplicacions que genera.
Vercel va comunicar el 19 d’abril de 2026 un accés no autoritzat a sistemes interns, relacionat amb un tercer i amb variables d’entorn d’un subconjunt de clients. El butlletí actualitzat declara completada la remediació i tancat l’incident el 16 d’octubre. No permet concloure que totes les aplicacions de v0 estiguessin afectades.
Per triar una eina, aquests fets aconsellen avaluar tant el producte com la cadena de serveis. El criteri pràctic és conèixer quines credencials existeixen, qui pot revocar-les i on es consulten els avisos rellevants. Aquesta fitxa no atribueix cap incidència de seguretat al projecte hipotètic descrit a continuació.
Documentació de referència: v0 from Vercel — Webby Winner 2025 · Vercel April 2026 security incident.
Aplicacions en seguretat i salut en el treball
Sabentis proposa v0 com a suport al disseny i desenvolupament d’interfícies per a continguts preventius. Són escenaris d’ús, no resultats d’una implantació ni capacitats d’avaluació de riscos.
- Biblioteca preventiva: explorar targetes, temes i idiomes perquè una persona localitzi el document correcte i en distingeixi la versió. La informació de vigència ha de provenir del catàleg aprovat.
- Campanya: assajar la jerarquia entre missatge principal, recursos de suport i contacte. El prototip permet observar si la crida a l’acció s’entén amb mòbil i teclat.
- Explicació d’indicadors: crear una demostració amb dades clarament fictícies per revisar com s’interpreten filtres, denominadors i períodes. La presentació no ha de semblar un resultat real de l’organització.
L’aportació a SST és reduir obstacles per comprendre i trobar informació. No s’obté una eina preventiva validada únicament perquè una interfície tingui aspecte professional. El contingut tècnic, els permisos i els criteris d’actualització han de continuar tenint responsables identificats.
Cas hipotètic: biblioteca de recursos en tres idiomes
Un equip vol avaluar una biblioteca pública amb targetes per tema, selector d’idioma i enllaços a documents. Es prepara un catàleg petit amb títol, idioma, tema, data de revisió, URL i estat. Els recursos retirats i els exemples s’identifiquen expressament.
- Definir la tasca: localitzar un recurs concret en espanyol, català i anglès. Precisar que no s’inventaran traduccions, dates ni documents que faltin al catàleg.
- Construir la primera versió: demanar filtres combinables, targetes llegibles i un estat sense resultats. Mantenir les dades públiques separades de la presentació.
- Revisar els extrems: provar un títol llarg, un idioma sense recurs equivalent, un enllaç retirat i una cerca sense coincidències. No acceptar que canviar el rètol de l’idioma conservi silenciosament un altre document.
- Avaluar l’accés: comprovar mòbil i escriptori, navegació amb teclat, focus, etiquetes i contrast. Demanar a una persona que trobi el recurs sense indicar-li on és, registrant-ne les dificultats.
- Revisar el canvi: inspeccionar codi i diferències, verificar tots els enllaços i decidir quina versió compleix els criteris per publicar-se.
L’acceptació exigeix que cada targeta porti a la font prevista, que les absències s’expliquin i que el responsable pugui actualitzar el catàleg. Si el prototip necessita autenticació o dades internes, això obre una fase nova de requisits i revisió. Aquest cas no descriu una prova realitzada amb usuaris ni un servei ja publicat.
Límits i criteris de qualitat
Una aplicació pot compilar i fallar en el propòsit: un formulari pot confirmar un enviament que mai no s’emmagatzema; un indicador pot sumar valors incompatibles; un selector pot canviar només una etiqueta. Les proves han d’observar aquestes conseqüències, a més de l’aparença.
Sabentis proposa revisar cinc dimensions: contingut correcte, comportament complet, accessibilitat, gestió de dades i mantenibilitat. Per a cadascuna convé una evidència concreta. Per exemple, reobrir un registre demostra persistència millor que veure un missatge d’èxit; navegar sense ratolí revela barreres que una captura no mostra.
Els canvis successius poden introduir regressions. Conservar uns quants casos representatius permet verificar que una millora no trenca allò que ja s’ha acceptat. El responsable ha de poder comprendre i mantenir el projecte després de la conversa; altrament, la rapidesa inicial pot convertir-se en dependència operativa.
Quan triar v0 i eines complementàries
v0 és pertinent quan cal convertir una idea d’interfície en codi revisable i hi ha capacitat de mantenir-lo. Figma pot aportar referències de disseny; GitHub Copilot pot complementar el desenvolupament posterior. L’elecció depèn d’on és el treball pendent: disseny, comportament, integració o manteniment.
Si n’hi ha prou de comunicar un concepte estàtic, construir una aplicació pot afegir obligacions innecessàries. Si es vol observar com un usuari filtra, navega o interpreta informació, un prototip interactiu ofereix evidència més útil. Definir prèviament qui revisa cada aspecte evita acceptar una versió únicament per l’acabat visual.
Preguntes freqüents
Una vista prèvia és la versió publicada?
No. La vista prèvia permet revisar un treball; el desplegament de producció serveix l’adreça estable del projecte. S’ha de comprovar quina s’està compartint.
Una captura pot definir tota l’aplicació?
No. Cal aportar comportament, permisos, dades i estats alternatius. Allò que no es veu a la imatge pot ser decisiu per a l’usuari.
Generar codi elimina la necessitat de desenvolupament?
Redueix part de l’escriptura inicial, però continuen existint decisions d’arquitectura, revisió, proves i manteniment. La capacitat de treballar amb el codi generat és part del criteri de selecció.
