Este artículo es una traducción del artículo original en inglés.
La mayoría de los desarrolladores escuchan "Claude Code tiene una función de vista previa" y asumen que funciona como un editor visual. No es así. Ese malentendido define cómo la gente la configura, qué espera de ella y por qué terminan frustrados cuando se comporta de manera diferente a una herramienta como Figma o un editor visual de CMS.
Aquí te explicamos qué hace realmente la función de vista previa, cómo configurarla correctamente y dónde falla el modelo si tu equipo necesita que más de una persona participe en el ciclo visual. También cubriremos a qué recurren los equipos cuando un agente en una máquina local no es suficiente. (Si eres nuevo en Claude Code, empieza con qué es Claude Code o nuestra guía para principiantes.)
TLDR: Si necesitas un editor visual empresarial donde los no-desarrolladores puedan publicar UI de producción sin tocar código, Claude Code Preview no es la opción — Builder.io sí lo es.
La función de vista previa de Claude Code es un navegador integrado en la app Claude Desktop que permite al agente de IA verificar sus propios cambios de código tomando capturas de pantalla, inspeccionando el DOM e interactuando con la aplicación en ejecución. No es un editor visual. Es la capa de auto-verificación de la IA.
Esa distinción importa. Cuando trabajas en un editor visual tradicional, haces cambios y los ves reflejados de inmediato en un lienzo de diseño o una vista previa en vivo. Eres tú quien edita visualmente. En la vista previa de Claude Code, es la IA quien hace el trabajo visual. Abre tu aplicación en ejecución, toma una captura de pantalla, busca problemas visuales, hace clic en elementos, rellena formularios y luego decide si hacer cambios adicionales en el código según lo que ve.
Puedes ver cómo ocurre esto. Puedes interactuar con la aplicación tú mismo en el mismo navegador integrado. Pero el principal beneficiario del ciclo de retroalimentación visual es la IA, no tú ni tu equipo.
Entender esto desde el principio te ahorrará tener que reconfigurar la función, dejar de esperar un Webflow y evitar terminar con algo muy diferente.
Respuesta directa: Cuando autoVerify está habilitado (lo está por defecto), Claude Code inicia tu servidor de desarrollo después de editar los archivos del proyecto, luego usa el navegador integrado para tomar capturas de pantalla e inspeccionar la aplicación en ejecución. Si encuentra problemas visuales, hace cambios adicionales en el código y vuelve a verificar antes de completar su respuesta.
El flujo de trabajo es el siguiente:
- Le pides a Claude que haga un cambio de UI: actualizar un color, corregir un layout, añadir un componente
- Claude edita los archivos relevantes
- El servidor de desarrollo se inicia automáticamente (o ya estaba en ejecución)
- Claude abre el navegador integrado, toma una captura de pantalla e inspecciona el DOM
- Si algo parece mal — elemento desalineado, estilo faltante, error en la consola — Claude hace otra pasada
- Una vez satisfecho, completa la respuesta
Este es un ciclo de retroalimentación cerrado entre el código y la salida visual, y realmente ayuda. Detectar un layout roto antes de abrir una pestaña del navegador es más rápido que descubrirlo después. La vista previa integra el paso de verificación dentro de la propia ejecución de tareas de la IA. Para más formas de aprovechar este flujo de trabajo, consulta nuestros consejos y mejores prácticas de Claude Code.
Desde el panel de vista previa, Claude puede:
- Tomar capturas de pantalla en cualquier punto del flujo de trabajo
- Inspeccionar el DOM para identificar qué elementos cambiaron
- Hacer clic en elementos y rellenar formularios para probar interacciones
- Iniciar y detener el servidor de desarrollo desde el menú desplegable Preview en la barra de herramientas de la sesión
- Mantener cookies y almacenamiento local entre reinicios del servidor seleccionando "Persist sessions", para que no tengas que volver a iniciar sesión durante el desarrollo
Respuesta directa: Claude Code crea .claude/launch.json en la raíz de la carpeta que abriste al iniciar una sesión. Este archivo indica a la vista previa cómo iniciar tu servidor de desarrollo. Puedes editarlo manualmente o hacer clic en "Edit configuration" en el menú desplegable Preview para abrirlo en tu editor de código.
Claude detecta automáticamente la configuración de tu servidor de desarrollo en la mayoría de los casos. Pero si tu proyecto usa un comando personalizado, un puerto no estándar o una estructura de monorepo, tendrás que configurar este archivo manualmente.
Aquí está el esquema completo:
{
"version": "0.0.1",
"configurations": [
{
"name": "my-app",
"runtimeExecutable": "npm",
"runtimeArgs": ["run", "dev"],
"port": 3000,
"cwd": "${workspaceFolder}",
"env": {
"NODE_ENV": "development"
},
"autoPort": true
}
]
}Referencia de campos:
| Campo | Tipo | Descripción |
|---|---|---|
string | Identificador único para esta configuración de servidor | |
string | Comando a ejecutar — , , , etc. | |
string[] | Argumentos pasados a , p. ej. | |
number | Puerto en el que escucha el servidor. Por defecto 3000 | |
string | Directorio de trabajo relativo a la raíz del proyecto. Usa para hacer referencia a la raíz | |
object | Variables de entorno adicionales. No pongas secretos aquí — este archivo se incluye en tu repositorio | |
boolean | Gestión de conflictos de puerto (ver abajo) | |
string | Un script de Node.js para ejecutar directamente, en lugar de hacerlo a través de un gestor de paquetes | |
string[] | Argumentos pasados a (solo se usa cuando está configurado) |
Usa runtimeExecutable con runtimeArgs cuando inicies un servidor de desarrollo a través de un gestor de paquetes:
{
"name": "next-app",
"runtimeExecutable": "yarn",
"runtimeArgs": ["dev"],
"port": 3000
}Usa program cuando tengas un script de Node.js independiente que quieras ejecutar directamente con node:
{
"name": "api-server",
"program": "server.js",
"args": ["--verbose"],
"port": 4000
}
{
"version": "0.0.1",
"configurations": [
{
"name": "frontend",
"runtimeExecutable": "npm",
"runtimeArgs": ["run", "dev"],
"port": 3000,
"cwd": "apps/web",
"autoPort": true
},
{
"name": "api",
"runtimeExecutable": "npm",
"runtimeArgs": ["run", "dev"],
"port": 8080,
"cwd": "apps/api",
"autoPort": false,
"env": { "NODE_ENV": "development" }
}
]
}Importante: Los secretos de tu perfil de shell (
.zshrc,.bashrc) se heredan automáticamente. No pongas claves de API, credenciales de base de datos ni otros secretos en el campoenv: este archivo generalmente se incluye en tu repositorio.
Si quieres que Claude recuerde las convenciones del proyecto más allá de la configuración del servidor de desarrollo — bibliotecas preferidas, reglas de estilo, cosas que evitar — combina launch.json con un archivo AGENTS.md bien elaborado. Ahí es donde le enseñas al agente cómo funciona tu base de código, no solo cómo iniciarlo.
Respuesta directa: Auto-verify está activado por defecto. Para desactivarlo en un proyecto específico, añade "autoVerify": false a tu objeto de configuración en .claude/launch.json. También puedes activarlo o desactivarlo desde el menú desplegable Preview sin tocar el archivo.
{
"version": "0.0.1",
"configurations": [
{
"name": "my-app",
"runtimeExecutable": "npm",
"runtimeArgs": ["run", "dev"],
"port": 3000,
"autoVerify": false
}
]
}Cuando auto-verify está desactivado, el panel de vista previa y el navegador integrado siguen disponibles. Puedes pedirle a Claude que compruebe el estado visual actual en cualquier momento; simplemente la verificación no se ejecutará automáticamente después de cada edición. Esto es útil para aplicaciones que tardan mucho en reconstruirse o cuando quieres agrupar varios cambios antes de activar una comprobación visual.
Respuesta directa: La vista previa de Claude Code es local, pensada para uso individual y centrada en la IA. Funciona bien para un desarrollador que itera con Claude en un servidor de desarrollo local. Tiene limitaciones reales para monorepos, gestión de secretos y cualquier cosa que requiera edición visual por parte de humanos.
Detección de subcarpetas. La vista previa usa la carpeta raíz que seleccionaste al iniciar tu sesión como directorio de trabajo. Si abriste una raíz de monorepo, Claude no detectará automáticamente los servidores de desarrollo en subcarpetas. Solución: inicia tu sesión directamente dentro de la subcarpeta o añade manualmente la configuración del servidor de esa subcarpeta a launch.json.
Conflictos de puerto. El campo autoPort controla qué ocurre cuando tu puerto preferido ya está en uso:
autoPort: true— Claude encuentra un puerto libre y lo pasa al servidor a través de la variable de entornoPORTautoPort: false— Claude falla con un error. Úsalo cuando tu servidor deba usar un puerto exacto (callbacks de OAuth, listas de permitidos de CORS)- Sin configurar — Claude te pregunta la primera vez y guarda tu respuesta
Gestión de secretos. El archivo launch.json se incluye en tu repositorio por defecto. No pongas claves de API, credenciales de base de datos ni otros secretos en el campo env. Usa tu perfil de shell o un archivo .env en .gitignore para valores sensibles.
Modelo centrado en la IA para uso individual. La limitación más importante no es un problema de configuración, sino una decisión de diseño del flujo de trabajo. El ciclo de retroalimentación visual en la vista previa de Claude Code existe para la IA. Claude toma las capturas de pantalla. Claude lee el DOM. Claude decide qué hay que corregir. Un diseñador revisando un pull request o un PM comprobando una función en staging no pueden unirse a este ciclo de forma nativa. Ven el resultado desplegado, pero la iteración visual en tiempo real ocurre entre Claude y su navegador integrado: un agente, una sesión local, sin acceso compartido.
Esto también define cómo Claude Code se compara con otras herramientas de IA para programar. Si lo estás evaluando frente a Cursor, la compensación principal es autonomía del agente versus interactividad del IDE — consulta Claude Code vs Cursor para un análisis detallado. Si lo comparas con un agente centrado en la delegación como Devin, las diferencias son más fundamentales — Devin vs Claude Code cubre dónde encaja cada uno.
Respuesta directa: No, no en el sentido tradicional. Claude Code tiene una vista previa de tu aplicación en ejecución que la IA usa para auto-verificación. Esto es fundamentalmente diferente de un editor visual, donde un humano hace clic en elementos y esos clics generan o modifican código.
Cuando haces clic en un elemento en el navegador integrado de Claude Code, le estás dando a la IA contexto adicional para tu siguiente prompt: señalando lo que quieres cambiar para que Claude entienda qué elemento te refieres. La IA entonces escribe código para hacer ese cambio y verifica el resultado visual. Nunca editaste el elemento directamente.
Una extensión creada por la comunidad llamada Playground Skill (popularizada por el desarrollador Adam Sandler) adopta un enfoque interesante para salvar esta brecha. En lugar de editar la aplicación en vivo, Playground genera una herramienta HTML interactiva — con controles deslizantes, selectores de color y campos de entrada — que te permite ajustar parámetros visuales antes de que Claude escriba la implementación final. Haces clic hasta que se ve bien y luego genera el prompt de implementación para ti.
Es una solución ingeniosa que acerca a más personas a Claude Code. Pero opera en el ajuste aislado de parámetros para fragmentos de código, no en tu aplicación en vivo. Y no es nativa de Claude Code: la instalas por separado.
Para los equipos donde los diseñadores y PMs necesitan proponer y validar cambios visuales sin gestionar una terminal local, esto sigue siendo una brecha abierta en el ecosistema de Claude Code. Si eres diseñador específicamente, Claude Code para diseñadores cubre flujos de trabajo seguros y a dónde acudir cuando Claude Code solo no es suficiente.
Lo que la vista previa de Claude Code acierta fundamentalmente es esto: los ciclos de retroalimentación visual aceleran el desarrollo. Ver un resultado renderizado — no solo leer código — detecta problemas más rápido y comprime el ciclo de iteración. Esa idea es correcta, y la función de vista previa actúa en consecuencia.
La limitación es de alcance. Claude Code le da ese ciclo visual a la IA que trabaja en tu máquina local. Builder.io se lo da a todo tu equipo, en cada rama, sin que nadie necesite un entorno de desarrollo local.
Cómo funciona en la práctica: Un ingeniero conecta el repositorio a Builder una vez — comandos del servidor de desarrollo, variables de entorno, lógica de ramas. Después de eso, cualquier miembro del equipo puede abrir una rama, hacer cambios visuales directamente en la UI en vivo y generar un pull request limpio. Sin terminal. Sin clonar el repositorio localmente. Sin desviaciones del entorno entre lo que el diseñador ve en Figma y lo que llega al código base.
Mientras Claude Code ejecuta un agente en una sesión en una máquina local, Builder.io puede ejecutar más de 20 agentes en paralelo simultáneamente — cada uno en su propio contenedor en la nube, cada uno con acceso a vista previa en el navegador. El mismo ciclo de verificación que Claude Code usa de forma privada se convierte en un flujo de trabajo compartido y persistente. Para una visión más amplia de cómo están evolucionando los roles de la IA en los equipos de frontend, consulta El ingeniero de software de IA en 2026.
| Claude Code Preview | Builder.io | |
|---|---|---|
Quién ve el ciclo visual | Solo el agente de IA | Todo el equipo |
Infraestructura | Tu máquina local | Nube (sin configuración local) |
Acceso del diseñador | Descripciones de texto o capturas de pantalla | Click para editar en la rama en vivo |
Validación del PM | Despliegue manual en staging | Vista previa de rama en tiempo real |
Agentes en paralelo | Una sesión | Más de 20 simultáneos |
Persistencia de sesión | Local, vinculado a tu máquina | En la nube, compartible |
Si eres un desarrollador en solitario que itera rápido con Claude Code, la vista previa es la herramienta adecuada para ese flujo de trabajo. Si tu equipo — diseñadores, PMs, desarrolladores — todos necesitan participar en el ciclo de iteración visual, Builder.io está construido para esa colaboración.
La función de vista previa de Claude Code es un avance significativo en el desarrollo de frontend asistido por IA. El flujo de trabajo de auto-verify — editar, capturar pantalla, inspeccionar, corregir — acorta el ciclo entre escribir código y confirmar que se ve bien.
Para los desarrolladores en solitario, los pasos de configuración que importan:
- Deja que Claude detecte automáticamente tu servidor de desarrollo en la primera ejecución, luego edita
.claude/launch.jsonpara que coincida con tu configuración real - Usa
runtimeExecutableyruntimeArgspara servidores con gestores de paquetes; usaprogrampara scripts de Node.js independientes - Establece
autoPort: falsesi tu servidor requiere un puerto exacto para OAuth o CORS;truepara todo lo demás - Mantén los secretos fuera de
launch.json— usa tu perfil de shell o un archivo.enven el.gitignore - Abre las subcarpetas directamente en su propia sesión si Claude no detecta automáticamente sus servidores de desarrollo
Para los equipos que desarrollan funciones que múltiples stakeholders necesitan ver, revisar y validar, la vista previa de Claude Code cubre un lado de la brecha de colaboración. Builder.io cubre el resto.
Para una comparación completa del panorama de herramientas de IA para programar, las mejores herramientas de IA para programar en 2026 desglosa dónde encaja cada categoría de herramientas en un flujo de trabajo de frontend moderno.
P: ¿Cuál es la diferencia entre autoVerify y el navegador integrado?
R: El navegador integrado siempre está disponible en el panel de vista previa. autoVerify controla si Claude lo abre automáticamente y toma capturas de pantalla después de cada edición de código. Con auto-verify desactivado, el navegador sigue ahí — activas la verificación manualmente pidiéndole a Claude que compruebe el estado visual actual.
P: ¿Puedo usar la vista previa de Claude Code con un servidor remoto?
R: Claude Code Desktop admite entornos remotos (sesiones en la nube alojadas por Anthropic) y conexiones SSH a máquinas que tú gestionas. La función de vista previa se conecta a un servidor de desarrollo local por defecto. El comportamiento en sesiones remotas depende de tu configuración específica.
P: ¿Se incluye .claude/launch.json en el repositorio?
R: Sí, por defecto. El archivo vive en la raíz de tu proyecto y no se excluye automáticamente del repositorio — eso es intencional, para que todo el equipo comparta la misma configuración del servidor de desarrollo sin pasos manuales de configuración inicial. Lo que nunca debes poner ahí son secretos. Cualquier valor en el campo env quedará visible en el historial de tu repositorio. Usa tu perfil de shell (.zshrc, .bashrc) o un archivo .env en el .gitignore para claves de API, credenciales de base de datos y otros valores sensibles. Esos se heredan automáticamente por el proceso del servidor de desarrollo sin quedar expuestos en el archivo que se incluye en el repositorio.
Builder.io visually edits code, uses your design system, and sends pull requests.
Builder.io visually edits code, uses your design system, and sends pull requests.
Connect a Repo
