Del prototipo a producción: qué necesita aún un borrador de vibe coding

Un prototipo no está listo para producción por el mero hecho de funcionar. Lo está cuando se ha aclarado qué ocurre ante entradas incorrectas, accesos simultáneos, permisos ausentes y fallos, y cuando alguien puede operarlo, modificarlo y, en caso de emergencia, revertirlo. Son doce puntos verificables, no solo una cuestión de calidad del código.

¿Por qué fracasa tan a menudo el salto del prototipo a la operación?

Porque un prototipo responde a una pregunta distinta que un producto. El prototipo responde: ¿es esto posible siquiera? El producto responde: ¿aguanta esto cuando cien personas lo usan mal a la vez, se cae la red y dentro de dieciocho meses otra persona tiene que incorporar un cambio?

El prototipo no tiene respuesta a ninguna de estas preguntas, no porque esté mal construido, sino porque nunca se plantearon. El peligro surge del poder de convicción del resultado: algo que se presentó sin fallos en la reunión parece más terminado de lo que está.

¿Qué doce puntos debo aclarar antes de salir en vivo?

Capa de datos

• Completar el modelo de datos. Los prototipos suelen guardarlo todo de forma plana y sin relaciones. Lo que funciona en una demo impide después cualquier análisis y cualquier cambio.
• Hacer reversibles las migraciones. Todo cambio de esquema necesita una vía de retorno. Un paso de migración generado sin contrapartida es una calle de sentido único.
• Comprobar la concurrencia. ¿Qué ocurre cuando dos usuarios modifican a la vez el mismo registro? En el prototipo nunca ocurrió; en operación, el primer día.

Corrección

• Implementar los casos de error. El OWASP Top 10:2025 incluye por primera vez las excepciones mal tratadas como categoría propia (A10). El código generado implementa de forma fiable el caso normal y se traga el resto.
• Validar las entradas. En el servidor, no solo en el formulario. Los prototipos validan en el navegador porque eso basta para la demostración.
• Escribir pruebas para el comportamiento que debe protegerse. Véase Cobertura de pruebas en código de IA.

Acceso

• Hacer explícitos los permisos. Para cada punto de acceso, una pregunta respondida: ¿quién puede invocarlo y qué ocurre si otra persona lo intenta? El control de acceso defectuoso sigue ocupando el primer puesto del OWASP Top 10:2025.
• Sacar los secretos del código fuente. Los prototipos llevan credenciales en el código porque era más rápido.

Operación

• Inventariar las dependencias. ¿Qué paquetes hay, quién los mantiene, qué licencia tienen? Los fallos de la cadena de suministro son desde 2025 una categoría propia de OWASP (A03).
• Registro y alertas. Si nadie nota que está roto, está roto durante más tiempo.
• Vía de reversión. Un despliegue sin vía de retorno es la promesa de no cometer ningún error.
• Aclarar la protección de datos. ¿Qué datos personales se generan, con qué base jurídica, durante cuánto tiempo se conservan, quién los trata por encargo?

¿Merece la pena reescribir el prototipo?

Con más frecuencia de lo que parece, pero la decisión debería depender de un criterio, no de una intuición. El criterio es: ¿entiende alguien del equipo la estructura lo bastante bien como para modificarla de forma selectiva?

• Sí: entonces completarlo es la vía más económica. Trabaje los doce puntos anteriores, en este orden.
• No: entonces pagará la reconstrucción de todos modos, bien ahora de forma consciente, bien más tarde repartida en cada cambio. El prototipo sigue siendo valioso como especificación: muestra exactamente lo que debe hacer el producto.

Este segundo caso lo subestima con regularidad el debate sobre las herramientas de IA. Los datos de GitClear muestran que la reestructuración real del código está en fuerte retroceso: la proporción de código desplazado cayó del 21 % en 2022 al 3,8 % en 2026. Donde ya no se reestructura, crece en su lugar un acervo que en algún momento nadie querrá tocar.

¿Cómo planifico la transición de forma realista?

Calcule la transición como un proyecto propio, no como trabajo residual. Un prototipo que surgió en dos días necesita para los doce puntos, por lo general, un múltiplo de ese tiempo, y eso no es un fracaso, sino la distribución normal: la demo es la parte pequeña.

Más fiable que cualquier estimación global es otro procedimiento: repasar los doce puntos, valorar cada uno por separado (hecho, pendiente, poco claro) y estimar solo los pendientes. Eso lleva una hora y sustituye a una discusión que, de lo contrario, recorre todo el proyecto. Si desea que se le acompañe en este camino como servicio, nuestro desarrollo de SaaS está pensado precisamente para eso.

Preguntas frecuentes sobre la puesta en producción

¿Puedo poner en vivo directamente un prototipo construido con Lovable o Bolt?

Técnicamente sí; de forma responsable, solo tras los mismos doce puntos. El origen del código no cambia los requisitos: en cuanto intervienen usuarios reales y datos reales, rigen con independencia de quién o qué haya escrito el código.

¿Basta con que las pruebas estén en verde?

No. Las pruebas comprueban lo que alguien sabía que debía comprobar. En un prototipo esa es precisamente la laguna: los casos de error en los que nadie pensó tampoco están probados.

¿Cuál es el punto que más se pasa por alto?

Los permisos. La lógica de negocio se implementa de forma fiable porque figura en el encargo. La pregunta «¿puede este usuario hacer esto?» rara vez figura en el encargo y, por tanto, falta con frecuencia.

¿Debería hacer revisar antes el prototipo a alguien?

Una auditoría de código externa antes de la puesta en producción es claramente más barata que después de un incidente. Lo que revisa una auditoría así figura en nuestra lista de comprobación para auditorías de código.

Los doce puntos se marcan rápido y se trabajan de verdad con dificultad. Code Guardian vincula los más arriesgados (migración, despliegue, nueva dependencia) a gates que se sitúan delante del paso correspondiente y exigen una aprobación, en lugar de confiar en que la lista se recuerde en el momento oportuno.

Fuentes

• OWASP Top 10:2025 (categorías A01 Broken Access Control, A03 Software Supply Chain Failures, A10 Mishandling of Exceptional Conditions), versión final de enero de 2026.
• GitClear, The Maintainability Gap: 2026 AI Code Quality Research.

Fecha: 27 de julio de 2026. Valoración técnica de carácter general; el alcance concreto depende del caso particular y no sustituye a una revisión individual.