7 tips de vibe coding para principiantes: de tu primera app a producción

Hacer vibe coding hoy es sencillo. Le pides a un agente —Claude Code, Cursor, Codex, OpenCode, el que uses— que te arme una aplicación, y en minutos tienes algo funcionando en tu navegador. El problema aparece después: esa aplicación tarde o temprano necesita usuarios reales, una base de datos que nadie pueda vaciar, un lugar donde vivir y una forma de saber si sigue funcionando.

Estos son siete puntos que casi toda aplicación termina necesitando, explicados para quien nunca ha desarrollado antes. No es un artículo avanzado, pero sí práctico: si estás creando tu primer proyecto con IA, esto te va a ahorrar más de un dolor de cabeza.

1. Revisa quién puede tocar tu base de datos

Cuando un agente te crea un proyecto con Supabase, Firebase, Convex o cualquier plataforma que genera el backend automáticamente, la aplicación funciona de inmediato. Insertas un dato y ahí está. Justamente por eso conviene detenerse un momento: si funciona sin login, probablemente cualquiera pueda hacer lo mismo desde fuera de tu interfaz.

En Supabase el mecanismo que controla esto se llama Row Level Security (RLS). Entra al panel, ve a la sección de tablas, elige una y abre View policies. Ahí vas a ver las políticas de select, insert, update y delete. Abre cualquiera con Edit policy y mira la condición.

Si la política dice simplemente true, esa tabla está abierta para todo el mundo.

Y esto importa más de lo que parece, porque la clave pública de tu proyecto está diseñada para ser pública. La anon key (que Supabase está migrando al formato publishable key) va dentro del código del navegador a propósito; no es un secreto. Lo único que impide que alguien la use para leer o borrar tus datos son las políticas RLS. Distinto es la service_role (ahora secret key), que se salta RLS por completo y nunca debe aparecer en código de cliente.

La corrección es directa. Pídesela a tu agente:

Revisa los accesos de RLS e implementa políticas correctas en este proyecto de Supabase.

Después vuelve a abrir la política y comprueba que ya no diga true, sino una comparación real entre el usuario de la fila y el usuario autenticado. Verás que casi todas las reglas terminan compartiendo la misma lógica.

Documentación oficial: Row Level Security en Supabase.

Firebase tiene su equivalente en las Security Rules y Convex en sus funciones de autorización. Cambia el nombre, no el problema.

2. Organiza el código y súbelo a GitHub

Hay dos cosas que revisar aquí, y van juntas.

La estructura. Cada cierto tiempo abre el explorador de archivos de tu editor y mira qué se está generando. Dependiendo del modelo que uses, los proyectos se llenan de archivos basura: capturas de pantalla de herramientas de testing, notas internas del agente, código muerto que ya nadie llama. Para un proyecto pequeño con Supabase basta con el frontend (src) y la capa que se comunica con el backend. Pero si tu aplicación va a manejar pagos, o más adelante quieres una app móvil, conviene separar:

Separa el backend y el frontend cada uno en su propia carpeta, pero mantén todo en el mismo repositorio.

El repositorio. Aquí no hay término medio: tu código tiene que estar en GitHub (o GitLab, o Bitbucket), no solo en tu computadora. Por dos razones concretas:

1. En algún momento vas a trabajar desde otra máquina o con otra persona, y necesitas un único lugar del que descargar el proyecto.
2. Las plataformas de despliegue se conectan directamente a GitHub y publican cada cambio de forma automática. Sin repositorio, no hay despliegue automático.

Subirlo es tan simple como pedirlo: "sube el código a GitHub". Si tu agente tiene instalado GitHub CLI, él mismo crea el repositorio, lo nombra y sube todo.

Por debajo, lo que hace posible todo esto es Git, la herramienta de control de versiones que guarda el historial de tu proyecto y te permite volver atrás cuando algo se rompe. Vale la pena entenderla, aunque para empezar te baste con que el agente la use por ti.

3. Nunca subas tu archivo .env

Este es el error más caro y el más fácil de cometer.

El archivo .env guarda las credenciales de tu proyecto: las llaves de tu base de datos, tokens de APIs, claves de pagos. Es el usuario y contraseña de tu aplicación. Ese archivo jamás debe llegar a GitHub.

Lo que sí puede (y debe) subirse es el .env.example: una copia con los mismos nombres de variables pero con valores falsos. Sirve para que cualquiera que descargue el proyecto sepa qué necesita configurar, sin darle acceso a nada.

Tres comprobaciones rápidas antes de tu primer push:

• Que exista un archivo .gitignore y que incluya .env.
• Que en GitHub, dentro de tu repositorio, no aparezca ningún .env.
• Que las claves privadas estén solo en el .env local y en las variables de entorno de tu plataforma de despliegue.

Un detalle que casi nadie menciona: si una clave ya se subió alguna vez, borrarla del repositorio no basta. Queda en el historial de Git. Hay que rotarla —generar una nueva y revocar la vieja— en el panel del servicio correspondiente.

4. Planifica antes de pedir, y guarda esos planes

Este punto no es sobre código sino sobre administración del proyecto, y es el que más diferencia hace a medida que la aplicación crece.

Las interfaces actuales te dejan pedir varias cosas a la vez: "crea proyectos que agrupen tareas", "hazme una landing", "integra pagos". El problema es que todo eso corre sobre la misma base de código, y dos cambios simultáneos terminan tocando los mismos archivos y colisionando.

La solución más sencilla, sin instalar nada, tiene dos partes.

Usa el modo plan. No es solo redactar texto: cuando activas modo plan, el agente primero escanea y lee los archivos del proyecto y recién después propone qué modificar. Vas a notar la diferencia en la calidad del resultado, sobre todo en cambios grandes.

Guarda los planes en el repositorio. Crea una carpeta docs/ (o como prefieras llamarla) y pídele al agente:

Guarda este plan en la carpeta docs.

Cada plan queda como un archivo Markdown. Es un paso extra, sí, pero resuelve un problema real: cuando tengas veinte modificaciones encima, ya no vas a recordar qué seguía. Y como los planes están escritos, no tienes que implementarlos ahora mismo. Puedes ir acumulándolos conforme se te ocurren y ejecutarlos cuando toque.

Esto además te permite trabajar en paralelo con cierta seguridad: mientras un chat construye una funcionalidad ya planificada, otro puede estar en modo plan explorando la siguiente, sin escribir nada todavía. Cuando repitas el flujo lo suficiente, conviértelo en un skill (ver punto 6).

Si el proyecto crece más allá de eso, el siguiente escalón son herramientas como Linear o Notion.

5. Despliega en una plataforma que se encargue del trabajo sucio

Si nunca has trabajado con servidores, no sabes comandos de Linux ni configuraste redes, las plataformas tipo PaaS son el camino. Se conectan a tu cuenta de GitHub, descargan el código y lo ejecutan. Todo automático.

Las opciones habituales:

Dos advertencias sobre los precios, porque circulan mal:

• El plan Hobby de Railway cuesta $5/mes e incluye $5 de crédito de consumo. Es un piso, no un techo: si tu app consume más, pagas la diferencia. Para un proyecto pequeño suele quedarse ahí.
• El Postgres gratuito de Render caduca a los 30 días (con 14 días de gracia para migrarlo a un plan pago antes de que se borre). Sirve para una demo, no para algo con usuarios.

Instalar el CLI y el skill de Railway

El criterio para elegir plataforma, si vas a trabajar con agentes, es simple: que exista un CLI. Con CLI, tu agente puede desplegar solo.

Railway hoy resuelve las dos cosas —CLI y skill— con un único comando:

curl -fsSL agents.railway.com | sh

Eso instala el CLI, el skill use-railway, configura el MCP de Railway para las herramientas que detecte y verifica tu autenticación. Si ya tienes el CLI instalado, basta con railway setup agent, o railway skills install para instalar solo los skills. Después:

railway login

Se abre una pestaña del navegador, autorizas y listo. A partir de ahí, un "sube el proyecto" es suficiente. Los skills se instalan en ~/.agents/skills y en los directorios de las herramientas detectadas (Claude Code, Cursor, Codex, OpenCode, entre otras). Documentación: Railway Agent Skills.

El primer despliegue puede fallar y reintentar varias veces —diez o quince minutos no es raro—, pero el agente detecta el error y corrige. Cuando termine, te va a pedir las variables de entorno de tu backend. Un detalle a revisar después: los correos de confirmación de Supabase suelen quedar apuntando a localhost, así que actualiza la URL de redirección en la configuración de Auth.

6. Aprovecha los skills

Los agent skills son instrucciones adicionales que le das a tu agente para que sea mejor en algo concreto. Es una de las funciones más infravaloradas por quienes recién empiezan.

En diseño es donde más se nota la diferencia, porque es justo donde la IA produce resultados más genéricos. Algunos puntos de partida:

• UI Skills — un directorio de skills de ingeniería de diseño mantenido por ibelick, con decenas de opciones para accesibilidad, animación y pulido visual.
• frontend-design — el skill de diseño frontend de Anthropic.
• impeccable — probablemente el más popular del rubro. Está pensado justamente para que el resultado no parezca "diseño de IA", con reglas explícitas contra los patrones más gastados (bordes laterales de color, texto con degradado, glassmorphism por defecto).

Instalación de este último:

npx skills add https://github.com/pbakaus/impeccable --skill impeccable

Te va a preguntar para qué herramientas instalarlo y a qué nivel (proyecto o global). Si tu agente aparece en la lista, das enter; si no, lo buscas y lo marcas con espacio.

Y después, con el modo plan activado para que lea todas las páginas:

Mejora los diseños de todas las páginas de esta aplicación, cambiándolos por completo y haciéndolos consistentes entre sí.

Puedes pasarle imágenes de referencia si tienes una dirección clara. Si no le das ninguna, el agente elige por su cuenta y suele apoyarse en lo que ya existía.

7. Testea el proyecto ya desplegado

Último paso, y el que casi todos se saltan: comprobar que la aplicación funciona en producción, no solo en tu máquina.

Hay varias formas de hacerlo: Playwright, Chrome DevTools MCP, Browser Use. Una opción cómoda para empezar es TestSprite, porque además de ejecutar los tests te entrega reportes con grabaciones de cada uno.

Instalación:

npx @testsprite/testsprite-mcp@latest
testsprite setup

Te va a pedir una API key. La generas desde tu cuenta, en la sección de API Keys del panel. El plan gratuito da 150 créditos al mes, suficiente para probar; los planes pagos empiezan en $19/mes.

A partir de ahí puedes pedir directamente:

Actualiza el código en Railway y luego testea con TestSprite.

Los primeros tests suelen ser básicos (que cargue el formulario de login, poco más). Pide más:

Analiza el proyecto y crea los tests faltantes en TestSprite.

En el dashboard vas a ver cada test ejecutándose sobre tu dominio real: entra al sitio, escribe credenciales, llena formularios, y captura tanto los que pasan como los que fallan.

Sobre el entorno de staging

Testear en producción funciona, pero lo correcto es tener una copia donde probar antes. En Supabase eso se hace con Create branch, con dos condiciones que conviene saber de antemano: requiere plan Pro ($25/mes) y cada rama se factura por hora ($0,01344/hora, unos $9,70 al mes si la dejas encendida). Está pensado para ramas efímeras de prueba, no para un staging permanente; para eso sale casi igual crear un segundo proyecto.

La idea aplica a cualquier stack, no solo a Supabase: si vas a hacer cambios sobre algo que ya tiene usuarios, prueba primero en otro lado.

Preguntas frecuentes

¿Necesito saber programar para hacer vibe coding? Para generar una aplicación, no. Para llevarla a producción sin exponer los datos de tus usuarios, necesitas entender al menos los siete puntos de este artículo. La IA escribe el código; las consecuencias siguen siendo tuyas.

¿Es seguro que mi clave de Supabase esté en el código del frontend? La clave pública (anon / publishable) sí: está diseñada para eso. Lo que la hace segura son tus políticas RLS. La clave service_role / secret nunca debe salir del servidor.

¿Cuánto cuesta tener mi primera app en línea? Con Supabase en plan gratuito y Railway en Hobby, alrededor de $5 al mes. Con Cloudflare Workers puedes empezar en $0 si te mantienes bajo las 100.000 peticiones diarias.

¿Qué herramienta de agente conviene más? Los siete puntos aplican igual a Claude Code, Cursor, Codex u OpenCode. Lo que sí cambia el resultado es que la plataforma que elijas tenga CLI y skills disponibles.

Para cerrar

Usar estas herramientas es relativamente simple, pero en algún punto exige que conozcas lo que está pasando debajo. Estos siete puntos son un piso, no un techo: hay muchas más opciones de testing, más plataformas de despliegue y más skills para mejorar el código.

Si tienes una duda concreta sobre tu proyecto, puedes reservar una asesoría personalizada en fazt.dev.