Guía para crear una app
Cómo crear una app con vibe coding a partir de una idea clara
Si quieres aprender a crear una app con vibe coding, empieza por una tarea que una persona necesite completar, no por una lista de pantallas. Esta guía distingue entre crear una primera versión sencilla y modificar un proyecto existente, y muestra cuándo es importante hacer pruebas por tu cuenta.
elige tu caso (tabla de decisión)
Elige según lo que ya tengas. Una idea nueva necesita una primera versión acotada; un proyecto existente necesita un cambio que conserve el comportamiento actual.
- Caso ASi no tienes código, define una tarea del usuario y crea una primera pantalla funcional antes de añadir funciones.
- Caso BSi tienes un proyecto existente, identifica un archivo o comportamiento que quieras cambiar y anota qué debe seguir funcionando.
- En ambos casosVibe Code puede ayudarte a crear un borrador de la interfaz, pero debes probar por tu cuenta las entradas, los errores y el manejo de datos.
camino A
Sigue este camino si tienes una idea, pero aún no tienes un proyecto. Mantén la primera versión lo bastante pequeña como para revisarla de una vez.
-
1
Describe la tarea y sus límites
Escribe una instrucción que indique quién es el usuario, qué acción debe completar y qué resultado debe ver. Para un registro de hábitos, pide una marca diaria de cumplimiento, un historial breve y un estado vacío. Especifica que se usen datos de muestra para no confundir una pantalla convincente con un servicio de datos funcional.
-
2
Crea una interacción completa
Pide a Vibe Code el flujo funcional más sencillo: abrir la pantalla, añadir una marca de cumplimiento y verla aparecer. Solicita etiquetas legibles, controles fáciles de usar con el teclado y un diseño para móviles. Si el resultado añade pantallas o funciones que no vienen al caso, pide que las elimine en lugar de seguir construyendo sobre ese contenido innecesario.
-
3
Pruébalo y describe qué falla
Prueba el flujo por tu cuenta antes de pedir un rediseño. Informa de un fallo observable, como que una marca de cumplimiento desaparece al actualizar la página, e indica qué comportamiento esperas. Cambia una cosa a la vez, vuelve a probar el flujo y guarda una copia de la última versión que funcionó.
ruta B
Usa esta ruta cuando un proyecto ya funcione. Dale al asistente suficiente contexto para hacer un cambio acotado sin reemplazar inadvertidamente funciones que ya funcionan.
-
Una copia funcional del proyecto y una forma de ejecutarlo localmente — Primero confirma que el proyecto, sin cambios, se inicia y que su interacción principal funciona.
-
Una solicitud de cambio específica con un resultado esperado — Por ejemplo: añadir un mensaje de estado vacío cuando la lista de tareas no tenga elementos.
-
Una lista de funciones que deben permanecer sin cambios — Indica las pantallas afectadas, el formato de datos existente y cualquier interacción que no puedas permitirte romper.
-
Un entorno de pruebas seguro con datos de muestra no confidenciales — No incluyas contraseñas, registros privados ni claves de servicios activos en un prompt.
-
Un punto de control en el sistema de control de versiones antes de editaropcional — Un commit facilita revisar las diferencias y revertir un cambio no deseado.
-
Capturas de pantalla o una breve descripción de la interfaz actualopcional — El contexto visual ayuda cuando la solicitud se refiere al espaciado, al texto o a un diseño que no funciona correctamente.
Rutas relacionadas
Si necesitas una introducción más amplia, una visión general centrada en la creación de aplicaciones o una revisión de seguridad más profunda, elige la ruta que corresponda a tu próxima pregunta.
- tutorial de vibe coding para principiantes Sigue una secuencia de práctica apta para principiantes antes de comprometerte con un proyecto más grande.
- creador de aplicaciones con vibe coding Explora qué puede generar un flujo de trabajo de creación de aplicaciones y qué decisiones siguen requiriendo intervención manual.
- riesgos de seguridad del vibe coding Revisa los riesgos habituales de datos y código antes de conectar un prototipo con usuarios reales.
comprobación final
Que una pantalla parezca terminada no significa que el producto sea fiable. Prueba qué ocurre cuando alguien la usa de una forma distinta a la de tu ejemplo.
Una vista previa no demuestra que los datos persistan
Puede parecer que un elemento se guarda cuando, en realidad, solo existe en la sesión actual del navegador. Actualiza la página, vuelve a abrirla y haz una prueba con un segundo dispositivo si tu diseño promete datos compartidos o persistentes.
Qué hacer en su lugar
Indica si los datos son temporales y comprueba cómo funciona realmente el almacenamiento antes de afirmar que los registros se guardan.
El código generado no equivale a una revisión de seguridad
Un formulario que funciona puede aun así exponer secretos, aceptar entradas inseguras o permitir el acceso a los registros de otra persona. El código producido mediante vibe coding debe revisarse antes de usar datos reales o permitir el acceso público.
Qué hacer en su lugar
Usa datos de ejemplo durante las iteraciones y pide que se revisen y prueben los procesos que manejan información sensible antes del lanzamiento.
Un solo clic exitoso no detecta los casos límite
Los campos vacíos, los textos largos, los toques repetidos, las conexiones lentas y las pantallas estrechas pueden interrumpir un proceso que funcionó en una única demostración.
Qué hacer en su lugar
Prueba cada caso, describe el fallo observado y repite las comprobaciones anteriores después de cada corrección.
Un prompt no puede decidir las reglas de tu producto
El asistente puede proponer opciones predeterminadas, pero no puede saber qué usuarios necesitan acceso, qué registros hay que conservar ni qué errores tienen consecuencias graves.
Qué hacer en su lugar
Escribe esas reglas con palabras sencillas y confirma que el comportamiento resultante se ajusta a ellas.
Cómo tomó forma este flujo de trabajo
La creación guiada por prompts se apoya en varios avances, pero la necesidad de inspeccionar y probar el software no ha desaparecido.
-
Las sugerencias de código llegan al editor
La versión preliminar técnica de GitHub Copilot incorporó sugerencias generadas por IA a un flujo de trabajo de programación conocido. Una sugerencia podía agilizar una pequeña modificación, pero el desarrollador seguía teniendo que decidir si encajaba en el proyecto.
-
Las instrucciones se vuelven conversacionales
El lanzamiento público de ChatGPT hizo posible describir una función, examinar una respuesta y ajustar la solicitud en lenguaje cotidiano. Ese intercambio resulta útil tanto para planificar una interacción como para producir código.
-
Los cambios más grandes se vuelven más fáciles de solicitar
A medida que se desarrollaron las herramientas de IA capaces de programar, la gente empezó a pedir pantallas y comportamientos conectados en lugar de fragmentos aislados. Esto hizo más importante definir claramente el alcance: una solicitud amplia puede producir un resultado de aspecto pulido basado en suposiciones no comprobadas.
-
El vibe coding recibe un nombre
Andrej Karpathy popularizó la expresión vibe coding para referirse a una forma de crear software basada en instrucciones. En un proyecto de aplicación, el hábito útil no es aceptar todos los cambios generados, sino crear, observar y corregir repetidamente un flujo pequeño.
Empieza con una versión pequeña
Dale a Vibe Code una tarea concreta para el usuario, el resultado que debe aparecer en pantalla y un límite, como usar solo datos de ejemplo. Después de la primera versión, prueba la interacción tú mismo y pide una corrección precisa en lugar de una revisión general.
Convierte una tarea en una primera versión que puedas probar
- Empieza con una interacción completa
- Examina el resultado antes de añadir funciones
- No incluyas datos sensibles en las primeras instrucciones
Preguntas frecuentes del tutorial
Indica a quién va dirigida la aplicación, una tarea, la acción que realizará esa persona y el resultado que debería ver. Incluye límites, como un diseño adaptable a dispositivos móviles y el uso exclusivo de datos de ejemplo. Pide un flujo pequeño que funcione, en lugar de todas las funciones que quizá quieras añadir más adelante.
Empieza desde cero si necesitas explorar una idea nueva y no tienes código que valga la pena conservar. Usa el proyecto actual si quieres hacer un cambio concreto en algo que ya funciona. En ese caso, comprueba primero cómo se comporta y explica qué debe permanecer sin cambios.
Completa la tarea principal sin depender del ejemplo que incluiste en tu instrucción. Después, prueba una entrada vacía, acciones repetidas, una recarga de la página y una pantalla estrecha. Si los datos deben conservarse o compartirse, comprueba esas funciones por separado en lugar de suponer que una vista previa correcta las demuestra.
Describe qué hiciste, qué ocurrió y qué esperabas que ocurriera. Pide una sola corrección acotada y luego prueba tanto la corrección como el flujo que ya funcionaba. Si un cambio provoca nuevos fallos, vuelve a la última versión que funcionaba antes de probar una instrucción distinta.
Puedes compartir un prototipo cuando hayas comprobado su funcionamiento y explicado claramente sus limitaciones. Antes de que usuarios reales introduzcan información personal, revisa el almacenamiento de datos, las reglas de acceso, la gestión de errores y los secretos expuestos. Una interfaz que parece funcionar no demuestra por sí sola que existan esas medidas de protección.