La IA puede escribir miles de líneas de código en minutos. El problema es que también puede escribir miles de líneas de código con errores en minutos.
Eso es, en buena parte, el reto del vibecoding.
Si estás creando aplicaciones con Cursor, Claude, GPT, OpenCode o cualquier otra herramienta de IA, probablemente ya descubriste lo fácil que es pasar de una idea a una aplicación funcionando. Puedes describir lo que quieres, dejar que el agente analice el proyecto y comenzar a ver resultados en cuestión de minutos.
Pero que una aplicación funcione no significa necesariamente que esté bien construida.
Seguridad, control de versiones, variables de entorno, estructura del proyecto, despliegue y testing siguen siendo responsabilidades tuyas. La IA puede ayudarte con todas ellas, pero necesitas saber qué estás pidiendo y, sobre todo, qué está haciendo realmente tu aplicación.
Estos son siete consejos que considero especialmente importantes si estás construyendo tu primera aplicación con vibecoding.
1. Protege tu base de datos desde el primer día
Antes de preocuparte por el diseño de tu aplicación, pregúntate quién puede acceder realmente a tus datos.
Cuando haces vibecoding es muy fácil concentrarte en la interfaz: crear botones, formularios, dashboards y animaciones. Pero una aplicación puede tener una interfaz perfectamente diseñada y, al mismo tiempo, dejar su base de datos prácticamente abierta.
Un ejemplo sencillo es una aplicación creada con React y Supabase para crear y eliminar tareas. La aplicación funciona correctamente: el usuario utiliza la interfaz, crea una tarea y esta aparece inmediatamente en la base de datos.
El problema aparece cuando revisas cómo están protegidos esos datos.
Supabase utiliza Row Level Security (RLS) para definir qué operaciones puede realizar cada usuario sobre las filas de una tabla. Las policies pueden controlar operaciones como “SELECT”, “INSERT”, “UPDATE” y “DELETE”.
Si una policy permite una operación utilizando una condición equivalente a “true”, esa operación puede quedar abierta a cualquier cliente que tenga acceso al recurso correspondiente. Es decir, la seguridad no debería depender de que el usuario utilice tu interfaz.
Y esta es una idea fundamental cuando haces vibecoding:
La interfaz no es una barrera de seguridad.
Un usuario puede intentar comunicarse directamente con tu API o backend sin utilizar los botones que tú diseñaste.
Por eso, cuando crees un proyecto con Supabase, Firebase, Convex, Appwrite u otra plataforma que exponga servicios de backend, no te limites a comprobar que la aplicación funciona. Revisa también quién puede leer, crear, modificar o eliminar los datos.
Incluso puedes pedirle a tu agente algo como:
«“Revisa las reglas de acceso de mi backend y dime qué operaciones puede realizar un usuario no autenticado.”»
Después revisa tú mismo el resultado.
La IA puede ayudarte a encontrar una configuración insegura. Pero la responsabilidad de decidir qué usuarios deben tener acceso sigue siendo tuya.
2. Revisa la estructura de tu proyecto con frecuencia
El código generado por IA también necesita mantenimiento.
Una de las ventajas del vibecoding es que puedes crear funcionalidades muy rápido. La desventaja es que también puedes acumular archivos, componentes y código innecesario con la misma velocidad.
Dependiendo del agente y de las tareas que hayas realizado, puedes terminar con archivos temporales, pruebas, capturas, componentes duplicados, documentación que ya no corresponde al proyecto o diferentes implementaciones de la misma funcionalidad.
Al principio quizá no importa demasiado.
Tu proyecto puede verse así:
src/ components/ pages/ services/Pero después de varias sesiones de vibecoding puede convertirse en algo mucho más difícil de entender.
Por eso conviene detenerse periódicamente y preguntarle al agente:
«“Analiza la estructura actual del proyecto. Identifica archivos que parezcan obsoletos, duplicados o innecesarios y explícame qué podría limpiarse sin modificar el comportamiento.”»
La palabra importante aquí es analiza.
No necesitas darle permiso para borrar todo automáticamente.
Primero puedes pedir un diagnóstico, revisar sus conclusiones y después decidir qué cambios aplicar.
Si tu aplicación tiene frontend y backend, también conviene pensar desde temprano dónde vive cada responsabilidad.
Por ejemplo:
mi-app/├── frontend/├── backend/├── docs/└── README.mdNo existe una única estructura correcta para todos los proyectos. Una aplicación pequeña puede funcionar perfectamente con una estructura mucho más sencilla.
La idea es evitar que el proyecto se convierta en una colección de archivos que solo la IA entiende.
Si tú no puedes explicar dónde está cada cosa, tarde o temprano vas a tener problemas para mantenerla.
3. Usa Git y una copia remota desde el principio
No guardes tu aplicación únicamente en tu computadora.
Aquí GitHub es una de las opciones más sencillas para empezar.
GitHub no es la única plataforma que puedes utilizar, pero combinar Git + un repositorio remoto debería ser una de tus primeras decisiones cuando comienzas un proyecto que realmente quieres conservar.
Git permite registrar cambios en tu código y volver a versiones anteriores cuando algo sale mal.
Esto es especialmente importante cuando trabajas con agentes de IA.
Imagina que tienes una aplicación funcionando perfectamente y le pides:
«“Refactoriza toda la arquitectura y mejora el sistema de autenticación.”»
El agente modifica veinte archivos y ahora algo deja de funcionar.
Sin Git, descubrir exactamente qué cambió puede convertirse en un dolor de cabeza.
Con Git, puedes revisar el historial y regresar a un estado anterior si es necesario.
Además, un repositorio remoto te permite tener una copia del proyecto fuera de tu computadora y facilita conectar el código con plataformas de despliegue.
Una vez que tu proyecto esté bajo control de versiones, intenta adquirir otro hábito:
haz commits después de cambios importantes y antes de pedir modificaciones grandes al agente.
Así, si una modificación generada por IA rompe algo, tienes un punto claro al que regresar.
El objetivo no es utilizar Git porque “los programadores lo hacen”.
El objetivo es que puedas experimentar con IA sin tener miedo de romper tu aplicación.
4. Las variables de entorno y los secretos no van a GitHub
Que una variable esté en un archivo “.env” no significa automáticamente que sea secreta, pero debes tratar ese archivo con mucho cuidado.
Los archivos de variables de entorno suelen contener información sensible como:
DATABASE_URL=...API_KEY=...JWT_SECRET=...Si esos valores terminan en un repositorio público, alguien podría utilizarlos para acceder a servicios, consumir APIs o interactuar con infraestructura asociada a tu aplicación.
Por eso, una configuración habitual es mantener el archivo real fuera del repositorio:
.env
y utilizar un archivo de ejemplo:
.env.example
El segundo puede documentar qué variables necesita el proyecto:
DATABASE_URL=API_KEY=JWT_SECRET=sin incluir los valores reales.
También debes revisar que “.env” esté incluido en tu “.gitignore” cuando corresponda.
Y hay otro detalle importante: no todas las variables de entorno son secretas. Algunos frameworks utilizan variables que deliberadamente terminan expuestas al navegador.
Por eso no basta con decir:
«“Todo lo que esté en “.env” es secreto.”»
La regla más útil es:
Antes de subir una variable a un repositorio, entiende si contiene un secreto y dónde terminará expuesto su valor.
Y si accidentalmente publicas una credencial real, no basta con eliminarla del archivo y hacer otro commit. Debes revocar o rotar la credencial comprometida.
5. Trabaja con planes antes de hacer cambios grandes
Una de las mejores formas de evitar que un agente destruya el contexto de tu proyecto es hacer que piense antes de modificarlo.
Los agentes modernos pueden cambiar muchos archivos en una sola petición.
Puedes pedirles:
«“Agrega autenticación, crea un dashboard, integra pagos y cambia todo el diseño.”»
El problema no es que la IA no pueda hacerlo.
El problema es que acabas de introducir varias modificaciones que pueden afectar las mismas partes del código.
Cuando utilizas un modo de planificación, el agente puede primero analizar el proyecto, identificar los archivos relevantes y proponer una estrategia antes de escribir código.
Eso te permite revisar preguntas como:
- ¿Qué archivos va a modificar?
- ¿Qué componentes nuevos necesita?
- ¿Qué partes del backend serán afectadas?
- ¿Qué riesgos existen?
- ¿Qué dependencias necesita?
- ¿Cómo se probará el cambio?
Y hay otro hábito que puede ayudarte mucho cuando el proyecto empieza a crecer:
Guarda tus decisiones importantes
Puedes crear una carpeta como:
docs/
y guardar allí planes, decisiones de arquitectura, notas técnicas o documentación que quieras conservar.
Por ejemplo:
docs/├── auth-plan.md├── payments-plan.md├── architecture.md└── deployment.mdEsto también sirve para trabajar con agentes en diferentes sesiones.
En lugar de depender completamente de que la IA “recuerde” todo lo que se hizo anteriormente, puedes darle documentación real del proyecto.
El contexto deja de estar solamente en la conversación y empieza a formar parte del propio repositorio.
La IA puede ayudarte a escribir el software. La documentación ayuda a que el proyecto tenga memoria.
6. Despliega con una plataforma que reduzca la complejidad
Si estás empezando, no necesitas administrar un servidor Linux para poner tu primera aplicación en Internet.
Plataformas como Vercel, Railway, Render, Netlify o Cloudflare pueden encargarse de buena parte de la infraestructura necesaria para desplegar una aplicación.
La elección depende del proyecto.
Por ejemplo, algunas plataformas son especialmente cómodas para aplicaciones frontend, otras para backends y bases de datos, y otras ofrecen una integración muy profunda con servicios serverless.
La idea no es encontrar “la plataforma perfecta”.
La idea es reducir la cantidad de infraestructura que tienes que administrar mientras aprendes.
En el caso de Railway, por ejemplo, puedes conectar tu proyecto con GitHub y utilizar su CLI para gestionar el despliegue. También puedes proporcionar instrucciones especializadas a tu agente para que conozca el flujo de trabajo de la plataforma.
Esto permite algo muy interesante con vibecoding:
«Puedes explicarle al agente qué quieres desplegar y dejar que te ayude con los pasos técnicos.»
Pero hay una diferencia importante entre automatizar y delegar la responsabilidad.
Si un despliegue falla, no deberías aceptar ciegamente cualquier cambio que proponga el agente solo porque finalmente aparece “deployed”.
Revisa qué cambió, por qué fallaba y si la solución realmente tiene sentido.
También presta atención a los detalles que solo aparecen cuando abandonas “localhost”.
Por ejemplo, una aplicación con autenticación puede funcionar perfectamente durante el desarrollo y fallar en producción porque las URLs de redirección siguen apuntando a:
En producción tendrás que configurar correctamente dominios, variables de entorno, callbacks, URLs de autenticación y cualquier otra configuración específica del entorno.
“Funciona en mi computadora” y “funciona en producción” son dos cosas diferentes.
7. Aprovecha los skills y automatiza tus pruebas
Los agentes pueden hacer mucho más cuando reciben instrucciones especializadas, pero eso no significa que debas confiar ciegamente en lo que generan.
Puedes pensar en los skills como instrucciones o capacidades especializadas que ayudan a un agente a trabajar mejor en determinadas tareas.
Por ejemplo, existen skills orientados al desarrollo, despliegue, diseño o revisión de proyectos.
En lugar de explicarle cada vez al agente cómo realizar una tarea específica, un skill puede proporcionarle un conjunto de instrucciones y buenas prácticas para ese contexto.
Esto puede ser especialmente útil en proyectos de vibecoding porque reduce parte del trabajo repetitivo.
También puedes utilizar herramientas de testing automatizado, como TestSprite, para comprobar una aplicación desplegada.
Por ejemplo, puedes pedir que se prueben flujos como:
Abrir aplicación ↓ Registrarse ↓ Iniciar sesión ↓ Crear tarea ↓ Editar tarea ↓ Eliminar tarea
Una herramienta de testing puede ejecutar estos flujos y generar información sobre lo que funciona y lo que falla.
Pero aquí hay una distinción importante:
No confundas testing con producción
Que una herramienta pueda probar tu dominio real no significa que debas probar directamente sobre la aplicación que están utilizando tus usuarios.
Lo recomendable es tener, cuando el proyecto lo necesite, diferentes entornos:
Development ↓ Staging ↓ Production
Puedes experimentar en desarrollo, validar cambios en staging y después llevarlos a producción.
Por ejemplo, si utilizas una plataforma como Supabase que permite crear entornos o branches para determinados flujos de trabajo, puedes disponer de una base de datos separada para probar cambios antes de afectar los datos reales.
Esto es especialmente importante cuando empiezas a trabajar con:
- autenticación
- pagos
- información de clientes
- migraciones de base de datos
- cambios importantes de arquitectura
Y recuerda algo fundamental:
Un test que pasa no demuestra que tu aplicación sea perfecta. Solo demuestra que pasó las pruebas que ejecutaste.
El vibecoding no elimina las buenas prácticas
El atractivo del vibecoding está precisamente en que reduce la barrera entre tener una idea y convertirla en software.
Puedes describir una aplicación, generar componentes, crear un backend, conectar una base de datos y desplegar todo sin conocer cada detalle de las tecnologías utilizadas.
Eso es increíblemente útil.
Pero también introduce un riesgo:
puedes construir algo que no entiendes a una velocidad que antes no era posible.
Por eso, si estás creando tu primera aplicación con IA, intenta desarrollar estos siete hábitos:
- Protege tu base de datos.
- Revisa periódicamente la estructura de tu proyecto.
- Usa Git y un repositorio remoto.
- Protege tus variables de entorno y secretos.
- Planifica los cambios grandes antes de ejecutarlos.
- Utiliza plataformas de despliegue que reduzcan la complejidad.
- Automatiza las pruebas y utiliza staging antes de producción cuando el proyecto lo requiera.
No necesitas convertirte en un experto en infraestructura antes de crear tu primera aplicación.
Pero sí necesitas entender algo fundamental:
La IA es una herramienta de desarrollo, no un sustituto de tu criterio.
Puedes pedirle que escriba código, revise una arquitectura, configure un despliegue o genere pruebas. Lo que no deberías hacer es asumir que porque el agente dice “listo”, el problema está resuelto.
En mi trabajo como desarrollador y asesor tecnológico, una de las cosas que más veo es que los proyectos no necesariamente fallan por falta de código. Muchas veces fallan porque nadie se detuvo a pensar en quién puede acceder a los datos, cómo recuperar una versión anterior, dónde están los secretos, cómo se despliega el proyecto o qué sucede cuando el código llega a producción.
El vibecoding hace que construir software sea más accesible.
Ahora nos toca aprender a construirlo de forma responsable.
Si estás creando tu primera aplicación con vibecoding y quieres revisar su estructura, seguridad o despliegue antes de llevarla a producción, puedes escribirme por “WhatsApp” (https://wa.me/526634660998) o visitar “mi sitio” (https://miguelramos.net/#contacto).
¿Cuál de estos siete puntos crees que suele pasarse más por alto cuando alguien empieza a crear aplicaciones con IA?