Qué es v0
v0 es el constructor de aplicaciones con IA de Vercel. Convierte instrucciones, referencias visuales y código existente en interfaces y aplicaciones que pueden revisarse, modificarse y desplegarse. Su alcance incluye tanto la parte visible como conexiones y lógica de servidor; no es únicamente un generador de imágenes de pantallas.
La distinción útil es entre intención, implementación y servicio operativo. Una petición describe lo deseado; el código propone cómo hacerlo; el servicio debe demostrar que funciona con sus datos, usuarios y condiciones reales. v0 acorta el recorrido entre esas etapas, pero no las convierte en equivalentes. También puede intervenir en un proyecto existente, por lo que importa delimitar qué se autoriza a cambiar.
Documentación de referencia: What is v0?.
Historia y evolución del producto
Vercel anunció el paso de v0 de alfa a beta el 11 de octubre de 2023, inicialmente centrado en interfaces con React, Tailwind CSS y shadcn/ui. La disponibilidad general llegó en 2024, según la retrospectiva del proveedor.
El 11 de agosto de 2025, v0.dev pasó a v0.app, acompañado por funciones de planificación, investigación y depuración. El 3 de febrero de 2026 se presentó una renovación orientada a repositorios existentes y ejecución en sandbox. En marzo se anunció la incorporación del equipo de new.website para desarrollar herramientas e integraciones. Esa incorporación expresa una dirección de producto; no acredita que todas las funciones prometidas quedaran disponibles ese mismo día.
Documentación de referencia: Announcing v0: Generative UI · v0.dev becomes v0.app · Introducing the new v0 · new.website joins forces with v0.
Cómo combina modelos, herramientas y ejecución
Vercel describe un proceso que combina instrucciones dinámicas, transformaciones durante la generación denominadas LLM Suspense y correcciones automáticas. Su métrica de generación satisfactoria se refiere a obtener una web que se renderiza en la vista previa. No equivale a demostrar que una aplicación resuelve correctamente todos sus requisitos.
Los chats respaldados por máquina virtual usan un sandbox con Node.js, archivos, comandos y servidor de desarrollo. Está separado de la producción. Esa separación permite inspeccionar un cambio antes de hacerlo público, pero no implica que todos los servicios externos conectados sean de prueba. Un entorno aislado que recibe credenciales con permisos amplios aún puede actuar sobre recursos reales.
Documentación de referencia: How we made v0 an effective coding agent · Sandbox.
Entradas y especificación del comportamiento
Se pueden aportar archivos y capturas para que v0 analice composición, colores y componentes. La documentación advierte que también infiere funcionamiento a partir de los elementos visibles. Una captura muestra un estado, no las reglas completas de una aplicación.
Un encargo útil describe qué recibe cada pantalla, qué devuelve y qué ocurre si falta información. Para un filtro, especificar si combina criterios, conserva la selección al cambiar de idioma y muestra un estado sin coincidencias. Para un formulario, identificar campos obligatorios, errores y destino del envío. Pedir «igual que esta imagen» puede resolver la apariencia y dejar sin definir justo el comportamiento que necesita el usuario.
Documentación de referencia: Screenshots and Files.
Diseño visual y componentes reutilizables
Design Systems 2.0 permite guardar un sistema de diseño como una skill que orienta el uso de componentes, tokens y convenciones reales. Puede partir de paquetes, repositorios, documentación y referencias de Figma. El propósito es reutilizar reglas de diseño, no depender de que cada conversación recuerde una apariencia.
En un proyecto de Sabentis, el encargo debería especificar el azul corporativo #2A62FE, los activos autorizados y las variantes de los componentes. Después se comprueba su uso real: contraste, foco visible, etiquetas y comportamiento con textos largos. La coherencia visual no se valida solo mirando la portada; las pantallas de error y los estados vacíos también forman parte del producto.
Documentación de referencia: Design Systems 2.0.
Código, ramas y revisión de cambios
Al conectar GitHub, el repositorio pasa a ser la referencia del código. v0 crea una rama de trabajo a partir de la rama base y envía allí los cambios generados. El flujo permite consultar diferencias, comprobaciones y solicitudes de integración antes de publicar.
El equipo debe leer las diferencias con un objetivo concreto: detectar cambios fuera del alcance, recursos eliminados y modificaciones de permisos. Una corrección de estilo no debería introducir una nueva base de datos sin una necesidad explícita. Mantener requisitos y ejemplos junto al proyecto facilita explicar por qué se acepta un cambio. El historial resulta útil cuando varias personas trabajan sobre el mismo producto y una mejora visual afecta una función existente.
Documentación de referencia: GitHub.
Vista previa, publicación y operación
Las vistas previas de ramas tienen URL propias; publicar actualiza el despliegue de producción y su dirección estable. En el flujo documentado con GitHub, la publicación integra la solicitud de cambios en la rama base. Guardar, revisar y publicar son estados distintos.
Antes de publicar, comprobar dominio, visibilidad y conexiones del entorno. Después, abrir la URL final y repetir las acciones esenciales: una compilación correcta no prueba que los enlaces, formularios y permisos públicos sean los esperados. También hace falta definir quién recibe incidencias, cómo se restaura una versión anterior y quién mantiene dependencias y contenido. El botón de publicación termina una fase de construcción, pero inicia una fase de operación.
Documentación de referencia: Deployments · GitHub.
Datos, APIs y conexiones MCP
v0 integra persistencia mediante proveedores de bases de datos y almacenamiento; documenta conexiones como Neon, Supabase, Upstash, Vercel Blob y Snowflake. En integraciones SQL puede generar y ejecutar operaciones que crean, modifican o eliminan tablas. MCP añade herramientas de servidores externos y servicios del Marketplace.
Conviene clasificar cada conexión por lo que permite hacer, no solo por el nombre del servicio. Leer un catálogo, modificarlo y enviar información a terceros son capacidades distintas. Para un prototipo, usar datos ficticios y permisos acotados permite probar el flujo sin confundirlo con un registro operativo. El contrato de entrada y salida debe incluir errores y ausencia de datos, además del caso en que todo responde correctamente.
Documentación de referencia: Databases · MCP Integrations.
Web, iOS y acceso programático
Vercel describió su aplicación iOS en noviembre de 2025: se construyó con React Native y Expo y se planteó alrededor de la conversación, sin buscar paridad completa con la web. La API renovada se anunció como disponible de forma general el 5 de agosto de 2026, con chats que mantienen el estado de una aplicación y devuelven vistas previas.
La API permite incorporar la generación a otro producto o proceso. Esto añade responsabilidades: relacionar cada petición con su proyecto, conservar resultados y controlar quién puede desplegar. Un proceso automático no debe interpretar una nueva vista previa como una orden de publicación. Para trabajo móvil, reservar una revisión en pantalla amplia cuando sea necesario inspeccionar tablas, diferencias de código o varios estados de una interfaz.
Documentación de referencia: How we built the v0 iOS app · Introducing the new v0 API.
Planes, modelos y costes de uso
La documentación consultada distingue Free, Plus, Business y Enterprise; también mantiene Premium, en retirada y cerrado a nuevos usuarios. El consumo depende de créditos y del trabajo generado, no de una cantidad fija de aplicaciones terminadas. La selección de modelos depende del plan y de la configuración del espacio; Enterprise añade control del propietario sobre modelos personalizados.
La comparación económica debe incluir generación, despliegue y servicios conectados. Una suscripción al constructor no convierte en gratuitos el almacenamiento, el dominio o cualquier API incorporada. Para estimar un proyecto, medir una tarea representativa con sus revisiones, registrar consumo y separar la construcción inicial del mantenimiento. Las ofertas de créditos y los límites cambian; comprobarlos en la cuenta antes de comprometer una cadencia de trabajo.
Documentación de referencia: Pricing · Choosing models.
Datos, propiedad del código y seguridad
La política de IA efectiva en marzo de 2026 vincula el uso para entrenamiento al plan y las preferencias; excluye los datos de clientes Enterprise. La documentación distingue secretos de servidor y variables NEXT_PUBLIC_, expuestas al navegador. Vercel indica que no reclama la propiedad del código generado, aunque puede contener errores o similitudes con material de terceros.
Por tanto, propiedad, privacidad y seguridad son comprobaciones separadas. Tener derecho a utilizar una salida no demuestra que sus dependencias estén bien licenciadas ni que su formulario proteja los datos. Antes de introducir material interno, verificar las preferencias efectivas del equipo y el alcance de cada proveedor conectado. Los secretos deben gestionarse como configuración, no copiarse en instrucciones o incluirse en archivos públicos.
Documentación de referencia: Vercel AI Policy · Security · FAQs.
Reconocimiento y un incidente del proveedor
v0 obtuvo el Webby de 2025 en Developer Tools. Es un reconocimiento del producto, no una certificación de la seguridad de las aplicaciones que genera.
Vercel comunicó el 19 de abril de 2026 un acceso no autorizado a sistemas internos, relacionado con un tercero y con variables de entorno de un subconjunto de clientes. El boletín actualizado declara completada la remediación y cerrado el incidente el 16 de octubre. No permite concluir que todas las aplicaciones de v0 estuvieran afectadas.
Para elegir una herramienta, estos hechos aconsejan evaluar tanto el producto como su cadena de servicios. El criterio práctico es conocer qué credenciales existen, quién puede revocarlas y dónde se consultan los avisos relevantes. Esta ficha no atribuye una incidencia de seguridad al proyecto hipotético descrito a continuación.
Documentación de referencia: v0 from Vercel — Webby Winner 2025 · Vercel April 2026 security incident.
Aplicaciones en seguridad y salud en el trabajo
Sabentis propone v0 como apoyo al diseño y desarrollo de interfaces para contenidos preventivos. Son escenarios de uso, no resultados de una implantación ni capacidades de evaluación de riesgos.
- Biblioteca preventiva: explorar tarjetas, temas e idiomas para que una persona localice el documento correcto y distinga su versión. La información de vigencia debe proceder del catálogo aprobado.
- Campaña: ensayar la jerarquía entre mensaje principal, recursos de apoyo y contacto. El prototipo permite observar si la llamada a la acción se entiende en móvil y con teclado.
- Explicación de indicadores: crear una demostración con datos claramente ficticios para revisar cómo se interpretan filtros, denominadores y periodos. La presentación no debe parecer un resultado real de la organización.
El aporte a SST está en reducir obstáculos para comprender y encontrar información. No se obtiene una herramienta preventiva validada únicamente porque una interfaz tenga aspecto profesional. El contenido técnico, los permisos y los criterios de actualización deben seguir teniendo responsables identificados.
Caso hipotético: biblioteca de recursos en tres idiomas
Un equipo quiere evaluar una biblioteca pública con tarjetas por tema, selector de idioma y enlaces a documentos. Se prepara un catálogo pequeño con título, idioma, tema, fecha de revisión, URL y estado. Los recursos retirados y los ejemplos se identifican expresamente.
- Definir la tarea: localizar un recurso concreto en español, catalán e inglés. Precisar que no se inventarán traducciones, fechas ni documentos que falten en el catálogo.
- Construir la primera versión: pedir filtros combinables, tarjetas legibles y un estado sin resultados. Mantener los datos públicos separados de la presentación.
- Revisar los extremos: probar un título largo, un idioma sin recurso equivalente, un enlace retirado y una búsqueda sin coincidencias. No aceptar que cambiar el rótulo del idioma conserve silenciosamente otro documento.
- Evaluar acceso: comprobar móvil y escritorio, navegación por teclado, foco, etiquetas y contraste. Pedir a una persona que encuentre el recurso sin indicarle dónde está, registrando dificultades.
- Revisar el cambio: inspeccionar código y diferencias, verificar todos los enlaces y decidir qué versión cumple los criterios para publicarse.
La aceptación exige que cada tarjeta lleve a la fuente prevista, que las ausencias se expliquen y que el responsable pueda actualizar el catálogo. Si el prototipo necesita autenticación o datos internos, eso abre una nueva fase de requisitos y revisión. Este caso no describe una prueba realizada con usuarios ni un servicio ya publicado.
Límites y criterios de calidad
Una aplicación puede compilar y fallar en su propósito: un formulario puede confirmar un envío que nunca se almacena; un indicador puede sumar valores incompatibles; un selector puede cambiar solo una etiqueta. Las pruebas deben observar esas consecuencias, además de la apariencia.
Sabentis propone revisar cinco dimensiones: contenido correcto, comportamiento completo, accesibilidad, manejo de datos y mantenibilidad. Para cada una conviene una evidencia concreta. Por ejemplo, reabrir un registro demuestra persistencia mejor que ver un mensaje de éxito; navegar sin ratón revela barreras que una captura no muestra.
Los cambios sucesivos pueden introducir regresiones. Conservar unos pocos casos representativos permite verificar que una mejora no rompe lo ya aceptado. El responsable debe poder comprender y mantener el proyecto después de la conversación; de lo contrario, la rapidez inicial puede convertirse en dependencia operativa.
Cuándo elegir v0 y herramientas complementarias
v0 resulta pertinente cuando se necesita convertir una idea de interfaz en código revisable y existe capacidad de mantenerlo. Figma puede aportar referencias de diseño; GitHub Copilot puede complementar el desarrollo posterior. La elección depende de dónde está el trabajo pendiente: diseño, comportamiento, integración o mantenimiento.
Si basta con comunicar un concepto estático, construir una aplicación puede añadir obligaciones innecesarias. Si se quiere observar cómo un usuario filtra, navega o interpreta información, un prototipo interactivo ofrece evidencia más útil. Definir de antemano quién revisa cada aspecto evita aceptar una versión únicamente por su acabado visual.
Preguntas frecuentes
¿Una vista previa es la versión publicada?
No. La vista previa permite revisar un trabajo; el despliegue de producción sirve la dirección estable del proyecto. Debe comprobarse cuál se está compartiendo.
¿Puede una captura definir toda la aplicación?
No. Hay que aportar comportamiento, permisos, datos y estados alternativos. Lo que no se ve en la imagen puede ser decisivo para el usuario.
¿Generar código elimina la necesidad de desarrollo?
Reduce parte de la escritura inicial, pero siguen existiendo decisiones de arquitectura, revisión, pruebas y mantenimiento. La capacidad de trabajar con el código generado es parte del criterio de selección.
