La checklist de production-readiness para vibe-code

Si construiste algo con Lovable, Cursor, Claude Code, Bolt, v0, Replit o herramientas convencionales y está por llegar a usuarios reales, úsalo como primera revisión. No es un estándar completo de production-readiness o seguridad. Adapta las comprobaciones a arquitectura, datos, amenazas, regulación y daño potencial. Una regla: un control visual no es un límite de autorización; la aplicación confiable debe ocurrir donde se controlan la acción protegida o los datos.

Esto no es un golpe al vibe-coding. El código asistido por IA y el escrito por personas necesitan los mismos controles de ingeniería basados en evidencia. La checklist se revisó el 2 de septiembre de 2026 frente a OWASP ASVS, OWASP API Security Top 10 y NIST SSDF.

¿Cómo sé si mi app vibe-coded está lista para producción?

Usa las diez comprobaciones como triaje y añade requisitos específicos de la arquitectura. Aprobar requiere evidencia, pero superar las diez no demuestra preparación. Riesgo, explotabilidad, exposición e impacto determinan prioridad; el orden numérico no clasifica la frecuencia de incidentes.

La checklist

1. Autorización en el servidor. Para cada endpoint y cada lectura de datos, ¿confirma el servidor quién pregunta y si tiene permiso? Una comprobación en el frontend no cuenta. Aprobado: cambia un ID de usuario en una petición y confirma que recibes una denegación, no los datos de otro.
2. Aislamiento por tenant y por fila. Si la app es multi-tenant, ¿puede una cuenta alcanzar físicamente los registros de otra? Aprobado: el aislamiento se impone en la capa de base de datos o de consulta, no en lógica de app que tienes que acordarte de añadir en cada endpoint.
3. Sin secretos confidenciales en el cliente. ¿Hay claves API privilegiadas, credenciales o bearer tokens en el bundle, logs, artefactos de build o historial? Algunos identificadores públicos y claves publicables están diseñados para clientes, pero aún necesitan mínimo privilegio y autorización en servidor o datos. Rota credenciales confidenciales expuestas y verifica la revocación.
4. Validación de entrada y salida en límites de confianza. ¿APIs, colas, webhooks, parsers e integraciones aplican esquema, tamaño, tipo, codificación y reglas de negocio? La validación cliente mejora la usabilidad, no es un límite de seguridad. Prueba entradas malformadas, enormes y hostiles y respuestas upstream inesperadas.
5. Rutas de fallo cubiertas. Cuando una llamada externa expira, falla o devuelve vacío, ¿degrada la app con gracia? Aprobado: fuerza el fallo de cada llamada externa y confirma que la pantalla no queda en blanco con una excepción no manejada.
6. Consultas que escalan. ¿Hay llamadas a base de datos dentro de un render, o tablas enteras cargadas para contar filas? Aprobado: perfilado con volúmenes de datos realistas, con consultas N+1 y lecturas sin límite eliminadas.
7. Concurrencia, repetición e idempotencia. Identifica operaciones donde una ejecución doble o paralela dañaría, como cobros, inventario, permisos, trabajos o efectos externos. Aplica claves de idempotencia, unicidad, bloqueos, transacciones, orden o deduplicación según el flujo. No todo cambio de estado debe ser repetible a ciegas.
8. Datos y configuración recuperables. Define objetivos de recuperación para bases, objetos, identidad, secretos y estado de infraestructura. Versiona migraciones cuando corresponda, automatiza backups, protégelos del mismo dominio de fallo y prueba restauración y reconciliación.
9. Dependencias y licencias gobernadas. Inventaría componentes directos y transitivos, versiones, procedencia, soporte, vulnerabilidades y obligaciones de licencia. Un hallazgo de escáner alimenta la evaluación de explotabilidad y negocio, no decide automáticamente.
10. Existe evidencia de regresión proporcional. Ejecuta tests automáticos y otras verificaciones en cada cambio relevante, cubriendo comportamiento crítico, autorización, fallos, migraciones e integraciones. Ninguna suite garantiza que el próximo cambio no rompa nada. El desarrollo guiado por tests es una práctica útil.

"El código generado por IA no cambia la evidencia de producción que necesitas. Empieza por autorización, aislamiento, secretos, validación, recuperación y verificación, y amplía la revisión a amenazas y obligaciones reales."

¿Qué puntos bloquean un lanzamiento?

No los diez son iguales. Ordena tus fallos en tres cubos para arreglar lo correcto primero en vez de congelarte ante la lista entera.

• Bloqueante. Una vía creíble a daño inaceptable sin control o recuperación eficaz, como acceso no autorizado a datos sensibles, acciones privilegiadas inseguras, cobros dobles o corrupción irrecuperable.
• Alto. Una debilidad material cuya probabilidad o impacto exige tratamiento antes de la exposición prevista, incluidos componentes vulnerables explotables o fallos críticos sin probar.
• Tratamiento programado. Riesgos residuales menores con responsable, fecha, monitorización y aceptación explícita por quien decide. La falta de pruebas o recuperación aún puede bloquear si la función es crítica.

El objetivo del reparto es ser honesto sobre la urgencia. No disfraces una tarea de mantenimiento programable como bloqueante ni dejes que un bloqueante real se esconda en una lista larga.

¿No puedo pedirle a la IA que lo arregle?

La IA puede inspeccionar código, generar tests, trazar flujos y proponer arreglos, pero sus hallazgos dependen del acceso, herramientas, prompts, comportamiento del modelo y calidad de especificaciones. Puede omitir supuestos entre sistemas y producir falsos positivos o parches inseguros. Úsala como un revisor junto con modelado de amenazas, análisis automático, inventario de dependencias, pruebas dinámicas y revisión humana cualificada. Así hacemos desarrollo de software a medida.

¿Cuánto cuesta despejar la lista entera?

Eso depende de qué falle y cuánto dinero o datos sensibles toque el producto. Desglosamos los rangos de esfuerzo típicos y a dónde va el tiempo en cuánto cuesta dejar lista para producción una app vibe-coded. La versión corta: la auditoría que recorre esta checklist es la parte barata, y te dice el tamaño del hardening antes de comprometerte. Esta es la puerta de entrada de nuestro servicio de aseguramiento de calidad de software.