Flujo de trabajo con Claude
La forma más fácil de perder el rumbo en un proyecto de vibe coding es pedir una aplicación entera de una vez. Empieza con una pantalla o una función, dile a Claude qué debe permanecer sin cambios y pídele una forma de probar el resultado. Vibe Code te ayuda a convertir esa idea en una instrucción inicial concreta.
Una petición vaga puede producir una vista previa convincente sin la funcionalidad que necesitas. Estos tres puntos de partida muestran cuándo conviene hacerle a Claude una petición más concreta y cuándo podría encajar mejor otro flujo de trabajo.
Puedes describir una lista de tareas, pero aún no sabes cómo pedirle a Claude que gestione el estado, las pantallas vacías o la persistencia. Empieza con una interacción que funcione y pide una explicación sencilla de cada archivo antes de añadir más funciones.
Si prefieres recibir sugerencias junto al código que ya estás editando, la guía de Copilot describe ese enfoque centrado en el editor.
Tu maqueta tiene buen aspecto, pero una pantalla estática no muestra qué ocurre cuando un campo está vacío o una acción falla. Pídele a Claude que implemente la interacción y enumere los estados que debes revisar.
Si quieres comparar otro modelo conversacional durante la fase de ideación, la guía de Gemini explica esa opción.
Ya tienes archivos y quieres añadir un filtro sin reescribir la aplicación. Proporciona solo los componentes pertinentes, describe el comportamiento actual y pide a Claude que identifique los archivos afectados antes de proponer cambios.
Si tu prioridad es hacer cambios dentro del editor, la guía de Copilot explica cómo mantener ese flujo de trabajo vinculado a los archivos actuales.
Usa la columna izquierda para detectar una petición poco específica. La columna derecha le plantea a Claude una tarea delimitada y un resultado observable. Cada flujo de trabajo incluye una petición de desarrollo y una comprobación posterior.
| Petición sin delimitar | Flujo de trabajo acotado con Claude | |
|---|---|---|
| Nueva pantalla · crear | «Hazme una aplicación de productividad». No se especifican el público, la pantalla ni las acciones esenciales. | «Crea una pantalla de lista de tareas con acciones para añadir, completar y eliminar tareas. Asegúrate de que la interfaz se pueda usar en un teléfono estrecho». |
| Nueva pantalla · comprobar | Aceptar una captura de pantalla como prueba de que los controles funcionan. | Pedir pruebas manuales que cubran una lista vacía, una tarea completada y la eliminación de una tarea después de actualizar la página. |
| Aplicación existente · modificar | «Mejora mi aplicación». Claude no tiene límites sobre lo que puede reemplazar. | Proporcionar los archivos pertinentes y pedir un filtro por estado que conserve el almacenamiento actual de las tareas y el diseño. |
| Aplicación existente · comprobar | Aplicar una reescritura extensa sin revisar las diferencias. | Pedir un resumen de los cambios archivo por archivo y, después, probar el comportamiento existente y el filtro nuevo. |
| Corrección de errores · investigar | «No funciona». No hay un fallo reproducible que diagnosticar. | Proporcionar el texto del error, los pasos para reproducirlo, el comportamiento esperado y el fragmento de código pertinente más pequeño posible. |
| Corrección de errores · comprobar | Suponer que una explicación plausible significa que el error está corregido. | Pedirle a Claude la causa probable, un parche mínimo y una prueba de regresión que puedas ejecutar. |
Esto es lo que podría incluir una respuesta útil a una solicitud de lista de tareas. Son ejemplos de texto ilustrativos; no implican que se haya ejecutado ninguna instrucción ni que se haya verificado su código.
Primer borrador
Ejemplo de respuesta: «Crearé una sola pantalla de lista de tareas con acciones para añadir, completar y eliminar. Las tareas se conservarán en el almacenamiento local. No añadiré cuentas, funciones para compartir ni un servidor. Explicaré la lógica del estado y el almacenamiento después de la implementación». Esos límites hacen que el primer resultado de vibe coding sea más fácil de revisar que una propuesta de aplicación demasiado amplia.
Revisión
Ejemplo de petición de seguimiento: «Después de actualizar la página, las tareas completadas aparecen sin marcar. Mantén el diseño actual y corrige únicamente la persistencia. Dime qué valor almacenado faltaba y cómo comprobar la corrección». Esto le da a Claude un fallo concreto y limita el cambio. Cuando trabajes en iteraciones de vibe coding, describe lo que observaste en lugar de pedir una mejora general.
Entrega
Ejemplo de entrega: «La lista de tareas permite añadir, completar y eliminar tareas. Ejecuta el proyecto con el comando local documentado y, después, prueba una entrada vacía, una tarea completada tras actualizar la página y la eliminación de una tarea. La persistencia utiliza el almacenamiento del navegador; los datos no estarán disponibles para el usuario en otro navegador». Una buena entrega de vibe coding expone una limitación con la misma claridad que una función.
Claude puede proponer código, pero una explicación comprensible no demuestra que sea seguro ni correcto. No pegues secretos, registros privados de clientes ni código que no tengas permiso para compartir en una petición. Revisa las dependencias y las licencias, examina cómo se gestionan los datos de entrada y prueba el comportamiento real antes de publicar. Si se trata de datos sensibles o de una aplicación pública, solicita una revisión de seguridad a una persona cualificada. Usa Vibe Code para empezar con una petición de alcance limitado y mantén a una persona responsable del resultado.
Pide una pantalla o una función con un criterio de éxito observable, como una lista de tareas que conserve los elementos después de actualizar la página. Indica qué queda fuera del alcance y, después, pide a Claude que explique la implementación y sugiera pruebas manuales. Una primera petición pequeña facilita la evaluación de un resultado de vibe coding.
Puedes empezar describiendo la interfaz y su comportamiento con palabras cotidianas. Aun así, debes ejecutar el resultado, observar los fallos y preguntar por el código que no entiendas. Si otras personas van a depender de él, pide ayuda para revisar la implementación en lugar de dar por hecho que una vista previa funcional es suficiente.
Dile a Claude exactamente qué hiciste, qué ocurrió y qué esperabas que ocurriera. Incluye el mensaje de error o el archivo pertinente si lo tienes, y pide un cambio mínimo que conserve lo que ya funciona. Vuelve a ejecutar tanto la prueba fallida como una prueba de lo que ya funcionaba.
Puede generar un primer borrador considerable, pero una sola instrucción no puede demostrar que funcionen todas las interacciones, dependencias y situaciones límite. Divide la aplicación en partes que puedas probar y revisa cada incorporación. Así tendrás información más clara cuando una iteración de vibe coding salga mal.
Ejecútalo tú mismo, examina los archivos modificados y las dependencias, y prueba cómo gestiona las entradas, el almacenamiento y los estados de error. Elimina los secretos y los datos privados de ejemplo tanto del proyecto como del historial de instrucciones. Si el proyecto maneja información sensible, solicita una revisión de seguridad adecuada antes de publicarlo.