Vibe coding a producción: lo que le falta al prototipo

Llevar el vibe coding a producción significa añadir lo que la herramienta de IA no hace por sí sola. Login y permisos seguros, contraseñas fuera del código, copias de seguridad, despliegue repetible, tests y monitorización. El prototipo no se pierde. Es el mejor encargo que puede dar a un proveedor.

El vibe coding le construye un prototipo. Nosotros, el software con el que funciona una empresa. A continuación describimos qué le falta a un prototipo, cómo comprobarlo y cuándo compensa empezar de nuevo. Qué es el vibe coding y por qué el software se ha abaratado lo explicamos en Vibe coding: qué es y por qué el software se ha abaratado.

¿Qué es el vibe coding y dónde se queda corto?

Vibe coding significa describir a una herramienta de IA lo que quiere y aceptar el código que genera sin leerlo. En un fin de semana tiene una aplicación por la que se puede hacer clic. Hace unos años eso requería un desarrollador y meses de trabajo.

El vibe coding ha bajado la barrera de entrada, pero no ha subido el techo. Hoy casi cualquiera puede crear un prototipo. Pero la primera avalancha real de usuarios, el primer ataque o la primera base de datos perdida muestran lo que falta. Las herramientas son las mismas. La diferencia la marca la disciplina de ingeniería que las rodea.

¿Qué le falta a un prototipo para la operación real?

Estos son los puntos que revisamos cuando llevamos un prototipo a la operación real. Si falta alguno, no es motivo para reescribirlo. Es una lista de trabajo.

La primera fila es la más traicionera. El código hecho con vibe coding rara vez es malo. Es inconsistente. La IA acierta con el control de acceso una vez y lo olvida en el archivo de al lado. Lo vimos en la auditoría de un producto hecho con vibe coding: un archivo tenía una comprobación de login correcta y los endpoints de al lado servían archivos sin ningún login. La corrección es rápida, pero encontrar el hueco obliga a revisarlo todo.

La lista completa de 25 comprobaciones, con una forma de verificar cada una sin un desarrollador, está en el PDF. Abrir las 25 comprobaciones antes del lanzamiento (online o PDF).

¿Está listo su prototipo? Un test rápido

Marque lo que se cumple en su aplicación. Cada punto sin marcar es una tarea antes del lanzamiento.

¿Por qué está la monitorización en la lista si la aplicación funciona?

Porque lo que funciona sin vigilancia un día se detiene en silencio. Sin una alerta se entera por un cliente o por una caída en un gráfico.

Una alerta debería avisar de una caída el mismo día. Por eso la monitorización es obligatoria, no un extra, cada vez que algo pasa a la operación real.

¿Seguir con el prototipo o empezar de nuevo?

Normalmente, seguir. Lo habitual es que baste con reforzarlo: unas cuantas correcciones de seguridad, un despliegue que funcione y después trabajo normal. Empezar de nuevo solo compensa cuando las correcciones llevarían más tiempo que una versión nueva.

Eso solo se puede decir con honestidad después de mirar el código. Los tres veredictos posibles, y qué pedir si otra persona escribió la aplicación, los explicamos en Cómo hacerse cargo de una aplicación de otro proveedor.

Aunque el código se reescriba, el prototipo se queda. Muestra cómo debe funcionar el producto mejor que cualquier especificación. Usted sabe cómo funciona su empresa. Nuestro trabajo es llevarlo a un software que dure años.

¿Tiene que dejar el vibe coding?

No. Si le gusta probar pantallas nuevas usted mismo, siga haciéndolo. Preparamos el repositorio para que sus experimentos encajen en el resto del sistema. Pasan por los mismos tests y la misma code review que todo lo demás.

Usted sigue descubriendo cómo debe funcionar el producto. Nosotros nos aseguramos de que aguante la operación real. De eso trata nuestro desarrollo de MVP para fundadores. Si una agencia estaba construyendo su aplicación y se atascó, consulte también Cómo hacerse cargo de una aplicación de otro proveedor.

Cuándo no lo recomendamos

• El prototipo solo lo usan usted o unos pocos compañeros internamente. No necesita ir a producción. Basta con hacer copia de seguridad de los datos.
• Está probando una idea y aún no tiene usuarios. Siga con el vibe coding usted mismo. Busque un proveedor cuando alguien quiera el producto.
• Quiere una plataforma terminada con todo en el primer mes. No se lo vamos a prometer. Empezamos por lo que necesitan los primeros usuarios.
• Quiere que alguien lo construya a cambio de participaciones. No lo hacemos. Busque un cofundador técnico.

¿Qué debe preparar antes de la primera conversación?

No necesita una especificación. Bastan tres cosas:

¿Quiere llevar su prototipo a los clientes?

Envíenos esas tres cosas. Le respondemos en dos días hábiles con unas pocas preguntas sobre su trabajo. Después acordamos qué hacemos primero.

Si prefiere hablar antes, reserve una llamada introductoria de 15 minutos.

¿Qué le falta todavía a su prototipo para que lo usen sus primeros clientes?

Preguntas frecuentes

¿Qué es el vibe coding?

Una forma de crear una aplicación: usted describe a una herramienta de IA lo que quiere y acepta el código que genera sin leerlo. Para un prototipo es rápido y barato. Para la operación real le falta control.

¿Puede una aplicación hecha con vibe coding pasar a producción?

Sí, pero no tal como está. Primero hay que revisar el login y los permisos, sacar las contraseñas del código y montar copias de seguridad, despliegue repetible, tests y monitorización.

¿Hay que reescribir desde cero un prototipo hecho con vibe coding?

Normalmente no. Lo habitual es que baste con reforzar la seguridad y la operación y después seguir adelante. Si hace falta reescribirlo, solo se puede decir con honestidad después de mirar el código.

¿Es segura una aplicación hecha con vibe coding?

Sin revisarla no se puede saber. El problema más habitual no es el código malo, sino el código inconsistente: una parte tiene un login correcto y la de al lado entrega los datos a cualquiera. Hay que revisar cada punto de entrada.

¿Puedo seguir editando la aplicación yo mismo después del traspaso?

Sí. El repositorio se puede preparar para que sus experimentos encajen en el resto del sistema y pasen por las mismas comprobaciones que el resto del código.