Vibe coding sin perder el control
Una guía práctica para creadores no técnicos que usan herramientas de AI coding: desglosa requisitos, controla permisos y datos, acepta el trabajo contra criterios claros y planifica el deploy con rollback.
El vibe coding te puede dar una demo rápida. Perder el control suele pasar después: requisitos poco claros, permisos demasiado amplios, datos desordenados, «en mi pantalla funciona» y ningún plan de rollback.
Esta guía es para creadores no técnicos y equipos mixtos que usan builders o agentes de IA. El objetivo no es convertirte en ingeniero de tiempo completo de la noche a la mañana. El objetivo es mantener la propiedad de lo que publicas.
Respuesta directa
- Escribe criterios de aceptación antes de escribir el prompt.
- Mantén los permisos y los secretos bien acotados.
- Trata la salida de la IA como un borrador hasta verificar el comportamiento.
- Haz deploy solo con un camino de rollback.
- Usa una checklist de ship antes de que lleguen usuarios públicos.
Empieza por el hub de AI Coding para orientarte sobre herramientas y modelos, y luego usa la checklist de ship local antes del lanzamiento.
Cuándo ayuda esta guía
- Describes ideas de producto en lenguaje natural y dejas que la IA genere apps o parches grandes.
- Puedes navegar una demo pero no estás seguro de qué es seguro publicar.
- Trabajas con un desarrollador que revisa la salida de la IA y necesitas un vocabulario compartido.
- Ya publicaste algo frágil y quieres un próximo lanzamiento más tranquilo.
Si primero estás eligiendo herramientas, lee cómo elegir una herramienta de AI coding. Si mantienes instrucciones de proyecto para agentes, continúa con reglas de proyecto para AI coding.
Desglosa la idea en piezas controlables
Antes de abrir un builder o un agente, escribe cuatro listas breves:
| Lista | Ejemplos |
|---|---|
| Debe funcionar | Login, crear ítem, pagar una vez, enviar recibo por email |
| Fuera de alcance | Multi-idioma, analítica de admin, modo oscuro |
| Zonas de riesgo | Pagos, contraseñas, datos personales, subida de archivos |
| Terminado significa | Pantallas concretas + un camino feliz + un camino de fallo |
Escribe el prompt una porción a la vez. «Construye todo el marketplace» crea demos que esconden bordes rotos. «Agrega login con email/contraseña, logout y una página de ajustes bloqueada» es más fácil de verificar.
Permisos y acceso
Pregunta quién puede hacer qué:
- Invitado vs usuario con sesión vs admin
- Qué pasa cuando la sesión expira
- Si las páginas de admin creadas por la IA quedan expuestas públicamente
- Si las API keys viven solo en el servidor
Si no entiendes una pantalla de permisos, pausa. Los valores por defecto demasiado amplios son un fallo habitual del vibe coding.
Datos que no deberías pegar en un prompt sin pensarlo
Mantén fuera de los prompts casuales:
- Listas reales de clientes
- Contraseñas y API keys de producción
- Documentos médicos, financieros o de identidad privados
- Secretos de archivos
.env
Usa datos de ejemplo falsos para las demos. Rota cualquier clave que pudiste haber pegado. Prefiere herramientas que procesen el código de forma local cuando puedas —consulta el enfoque privacy-first de DevCove para herramientas en el navegador.
Aceptación: demuéstralo, no lo admires
Para cada ítem que debe funcionar:
- Recorre tú mismo el camino feliz.
- Provoca un fallo (contraseña incorrecta, formulario vacío, tarjeta rechazada en sandbox).
- Revisa el ancho móvil si los usuarios usarán teléfonos.
- Anota qué se rompió en lenguaje simple.
Cuando algo falle, usa un handoff estructurado como el bug report packet builder en lugar de «está roto».
Deploy y rollback
Antes del lanzamiento público, responde:
- ¿Dónde corre la app?
- ¿Cómo publicas una nueva versión?
- ¿Cómo revertís a la última versión buena?
- ¿Quién es responsable del DNS, la facturación y la base de datos?
Si no puedes hacer rollback, no estás listo para usuarios reales, aunque la demo se vea pulida.
Un ciclo de vibe coding tranquilo
- Escribe la porción y los criterios de aceptación.
- Escribe el prompt con restricciones y datos falsos.
- Recorre los caminos felices y de fallo.
- Ejecuta o solicita un build/check cuando esté disponible.
- Completa la checklist de ship.
- Haz deploy con un responsable de rollback conocido.
- Solo entonces amplía el alcance.
Límites
- Esta guía no te convierte en ingeniero de seguridad.
- Los builders y agentes cambian rápido; verifica la configuración actual del producto.
- Algunos productos necesitan revisión profesional antes de manejar pagos o datos sensibles.
Preguntas frecuentes
¿El vibe coding es ingeniería «real»?
Puede producir software real. Publicar sigue requiriendo verificación, propiedad y rollback: las mismas responsabilidades que ya cargan los ingenieros.
¿Puedo saltarme los archivos de reglas de proyecto?
Para demos personales muy pequeñas, quizá. Para cualquier cosa compartida o de largo plazo, unas reglas breves reducen el comportamiento aleatorio del agente. Consulta reglas de proyecto para AI coding.