DEL DESARROLLO DE VIBE A LA PRODUCCIÓN
La IA puede diseñar un producto en un fin de semana. La producción sigue requiriendo responsabilidad, pruebas y una definición implacable de «terminado». Aquí está la división de funciones.
← Todas las guías Todas las guías de este tema
En esta página
Para qué sirve el «vibe coding»
La programación «Vibe» consiste en dirigir a un agente de programación basado en IA más en función de la intención y el gusto que de unas especificaciones formales: Cursor, Claude Code, Copilot, Windsurf y similares. Es ideal para prototipos rápidos, herramientas internas, migraciones con un «antes» y un «después» claros, la creación de estructuras de interfaz de usuario y ese código de enlace aburrido que preferirías no tener que escribir.
Así es también como muchos fundadores lanzan ahora sus productos. No hay ningún problema. El error está en tratar una demo local sin pulir como si fuera un sistema de producción. A los usuarios, los pagos, la autenticación, el SEO, la accesibilidad y la realidad de las guardias no les importa que el agente pareciera rápido.
Conclusión clave: Utiliza la «codificación de vibraciones» para explorar y acelerar el proceso. No confundas la velocidad de generación con la preparación para atender a los clientes.
Dónde se producen los fallos en la producción
Los patrones que observo cuando las aplicaciones creadas con IA se enfrentan al tráfico real:
La arquitectura no es propiedad de nadie
El agente creará encantado un tercer patrón para la obtención de datos, ya que la indicación no lo prohibía. Seis semanas después, nadie sabe cuál es el patrón canónico.
Autenticación y pagos en el escenario ideal
El inicio de sesión funciona en la cuenta de demostración. Los casos extremos, la caducidad de la sesión, los reintentos de los webhooks y las comprobaciones de permisos son meras hipótesis hasta que alguien los describe por escrito y los prueba.
Rendimiento invisible y deuda de SEO
Se publican carcasas generadas por el cliente, imágenes sin límites y metadatos que faltan porque el agente se ha optimizado para que «se vea bien en Chrome».
La expansión de «Secret» y «env»
Claves en los ejemplos de «chats logs.env» que son reales, y implementaciones de prueba que se comunican con bases de datos de producción.
Conclusión clave: Los fallos de producción tras el codificado vibratorio suelen deberse a casos puntuales y a problemas de propiedad, no a la calidad del modelo.
Las medidas de seguridad que permiten su envío
| Barandilla | Por qué es importante | Nivel mínimo |
|---|---|---|
| Definición escrita de «hecho» | Cierra el teatro de demostraciones | Autenticación, pagos, estados vacíos y estados de error enumerados |
| Primero, un corte vertical fino | Demuestra lo arriesgado que es ese camino | Un recorrido real del usuario en el entorno de prueba con una estructura de datos real |
| Revisión manual de las rutas críticas | Los agentes no alcanzan los objetivos de incentivos | Autenticación, facturación, migraciones, rutas públicas de SEO |
| Comprobaciones automáticas | Detecta las regresiones que los agentes vuelven a introducir | Comprobación de tipos, lint, pruebas de humo y CWV en las plantillas clave |
| Observabilidad | No se puede arreglar lo que no se ve | Seguimiento de errores + análisis básico de productos antes del lanzamiento |
| Plan de reversión | Una generación rápida necesita una función de deshacer rápida | Migraciones reversibles, indicadores de funciones para interfaces de usuario que entrañan riesgos |
Dentro de Seahawk tratamos agentes como juniors agresivos con velocidad de tipeo infinita. Redactaban. Los humanos aún poseían arquitectura, seguridad, y la decisión de lanzamiento. Para el flujo de trabajo más largo que uso cuando construyo con Claude a propósito, ve la guía de flujo de trabajo impulsado por especificación de Claude y el pilar de software personalizado.
Conclusión clave: Elabora la lista de tareas completadas antes de abrir el agente. Revisa tú mismo las rutas que te dan miedo.
Un bucle práctico que utilizamos
1. Describe la tarea del usuario en un párrafo. 2. Enumera los requisitos imprescindibles (proveedor de autenticación, CMS, alojamiento, accesibilidad, SEO). 3. Deja que el desarrollador cree una estructura inicial basándose en esa lista. 4. Ejecuta la aplicación en los casos de fallo el mismo día. 5. Elimina las abstracciones ingeniosas que el agente haya inventado y que tú no hayas solicitado. 6. Añade pruebas solo donde los fallos resulten costosos. 7. Lanza una versión reducida. 8. Solo entonces amplía el alcance.
Si el paso 4 falla dos veces seguidas, deja de generar indicaciones y redacta una especificación breve. Programar por intuición sin un ciclo de ajuste acaba convirtiéndose en una sucesión interminable de indicaciones.
Conclusión clave: Alterna la creación con el uso crítico. Si siempre te dejas llevar por la corriente, solo harás demostraciones.
Cuándo no se debe aplicar el código «vibe» al núcleo
No permitas que el agente improvise con el libro mayor de facturación, el modelo de permisos o las migraciones de datos de un sistema que ya cuenta con clientes. No diseñes a ciegas una reestructuración de la arquitectura de la información de producción sin un esquema previo. No externalices la elaboración de modelos de amenazas a una ventana de chat.
Implementa en Vibe-Code las funciones CRUD de la pantalla de administración, el script que renombra una carpeta de recursos, la primera versión de un panel de control interno y la solicitud de incorporación de cambios (PR) de migración una vez que un usuario haya especificado el cambio de esquema.
Conclusión clave: Mantén a los agentes alejados de operaciones financieras irreversibles, permisos y estructuras de datos hasta que una persona haya establecido las reglas.
En resumen
La programación Vibe es una herramienta de apoyo, no una metodología de entrega. Los equipos que triunfan en 2026 utilizan agentes a diario y, aun así, siguen sonando aburridos en las reuniones diarias: definición de «terminado», revisión de las rutas críticas, rendimiento sobre el terreno y un plan de reversión.
Si necesitas ayuda para convertir un prototipo creado a la velocidad de la IA en algo que puedas ofrecer a los clientes, eso ya forma parte del trabajo habitual de una agencia. Trae el repositorio y la lista de tareas completadas. Deja la confianza en la demo a un lado.
Conclusión clave: Lanza la versión que puedas gestionar, no la demo que te impresionó el viernes por la noche.
En qué se diferencia esto del trabajo de Claude basado en especificaciones
El trabajo basado en especificaciones comienza con un contrato por escrito: entidades, rutas, comprobaciones de aceptación; después, el agente completa los detalles que faltan. La programación intuitiva parte del gusto y de una idea inicial, y solo se concreta en un contrato cuando la realidad se interpone. Ambas formas son válidas. El error es utilizar la programación intuitiva en un contexto que ya requería un contrato.
Regla general: si se trata de un proyecto totalmente nuevo o de una herramienta interna, lo primero es la intuición. Si se trata de un producto multitenant, de pagos o de una superficie pública de SEO con tráfico ya existente, lo primero son las especificaciones. Nuestra guía de flujo de trabajo basada en especificaciones de Claude aborda la segunda vía en detalle. Esta guía corresponde a la primera vía, pero con restricciones de producción.
Conclusión clave: Explora el ambiente. Refuerza las especificaciones. No te saltes la entrega.