Checklist de preparación para producción de una app hecha con vibe coding en AWS

Una app construida rápido con ayuda de IA puede funcionar muy bien en una demo y aun así estar lejos de estar lista para clientes que pagan. Este checklist de preparación para producción es para fundadores y CTO que tienen una app hecha con vibe coding corriendo en AWS, o a punto de estarlo, y quieren saber qué tiene que ser cierto antes de que lleguen usuarios y datos reales. Cada punto es concreto y verificable, y cada uno enlaza a la documentación de AWS o de la industria que lo respalda.

Por qué las apps hechas con vibe coding necesitan un checklist

Andrej Karpathy acuñó el término en febrero de 2025 para describir una forma de programar en la que “fully give in to the vibes” (te entregas por completo a las sensaciones) y “forget that the code even exists” (olvidas que el código existe). Es una buena manera de explorar una idea. Se vuelve un problema cuando el resultado pasa a producción sin cambios, porque las partes del software que mantienen seguro a un negocio son justo las que una demo nunca pone a prueba: la falla, el abuso, la recuperación y el costo.

Las herramientas de programación con IA tienden a optimizar para que “corra”. Con gusto pondrán una API key en un archivo de configuración, abrirán una base de datos a internet para resolver un error de conexión o se saltarán las verificaciones de autorización de un endpoint porque el prompt no las mencionaba. Nada de esto se nota cuando navegas la app tú mismo. Todo se nota tarde o temprano. La mayoría de los problemas de seguridad del vibe coding no son ataques exóticos; son valores por defecto comunes que nadie revisó.

El checklist de abajo está agrupado por área y funciona como una plantilla de checklist de preparación para producción que puedes copiar a tu gestor de tareas. No necesitas completar todos los puntos antes del lanzamiento, pero sí debes saber cuáles siguen abiertos y por qué.

1. Secretos

• Ningún secreto en el repositorio, incluidos los commits antiguos. Busca en todo el historial de Git, no solo en los archivos actuales. El secret scanning de GitHub puede detectar formatos de token conocidos.
• Rota toda llave que alguna vez se haya subido en un commit, aunque la hayas borrado después. Borrar un archivo no lo elimina del historial ni de quien haya clonado el repositorio.
• Guarda los secretos en AWS Secrets Manager o en SSM Parameter Store y cárgalos en tiempo de ejecución.
• Ningún secreto en el código del front end. Todo lo que se envía al navegador es público. Las llamadas a APIs de pago, incluidos los proveedores de LLM, pasan por tu back end.

2. IAM y acceso a la cuenta

• No uses el usuario root para el trabajo diario y protégelo con MFA. Las mejores prácticas de seguridad de IAM de AWS cubren esto y los puntos siguientes.
• Mínimo privilegio para la aplicación. El rol de la app debe conceder solo las acciones que usa sobre los recursos que usa. Una política con "Action": "*" que una herramienta de IA sugirió para superar un error de permisos es un hallazgo común.
• Sin llaves de AWS de larga duración en CI. Usa OpenID Connect para que GitHub Actions pueda acceder a AWS sin guardar credenciales como secretos de larga duración.
• Separa producción de todo lo demás, idealmente en su propia cuenta de AWS, para que un error en un ambiente de pruebas no pueda tocar los datos de los clientes.

3. Exposición de datos y seguridad de la aplicación

• La base de datos no es de acceso público. Debe vivir en subredes privadas y ser accesible solo desde la aplicación.
• Los buckets de S3 bloquean el acceso público, salvo que un bucket sea público a propósito. AWS ofrece la configuración S3 Block Public Access a nivel de cuenta y de bucket.
• Cada endpoint verifica la autorización en el servidor. El control de acceso roto encabeza la lista OWASP Top 10 de riesgos de las aplicaciones web. Pruébalo directamente: inicia sesión como el usuario A y pide los registros del usuario B por ID.
• Las entradas se validan y las consultas a la base de datos están parametrizadas.
• Las dependencias se escanean en busca de vulnerabilidades conocidas, con los pull requests automáticos de actualización activados.

4. Respaldos y recuperación

• Los respaldos automáticos de la base de datos están activados, con recuperación a un punto en el tiempo y un período de retención que elegiste a propósito. Los respaldos automáticos de RDS permiten restaurar a cualquier punto dentro de ese período.
• Has probado una restauración. Un respaldo que nunca has restaurado es una esperanza, no un respaldo. Restaura en una instancia nueva, verifica los datos y mide cuánto tardó.
• La protección contra eliminación está activada en la base de datos de producción.
• Las cargas de los usuarios en S3 están protegidas con versionado o con un plan de respaldo.

5. Monitoreo y alertas

• La app expone un health check que confirma que puede llegar a sus dependencias, no solo que el proceso está en pie.
• Existen alarmas para lo que sienten los clientes: tasa de errores, latencia y disponibilidad, y no solo CPU.
• Las alarmas llegan a una persona. Una alerta que va a una bandeja de entrada que nadie lee es lo mismo que no tener alerta. Decide a quién se avisa de noche y cómo.
• Cada alarma tiene un runbook corto: qué significa, cómo verificarla y qué hacer primero.

6. Logs y auditoría

• Los logs son estructurados (JSON con IDs de solicitud) para poder seguir una solicitud a través del sistema.
• Sin secretos ni datos personales sensibles en los logs. Revisa qué registra tu framework por defecto cuando hay errores.
• La retención de logs está configurada. Por defecto, CloudWatch Logs almacena los datos de log de forma indefinida, lo que aumenta el costo y puede entrar en conflicto con compromisos de privacidad.
• AWS CloudTrail está activado para ver quién cambió qué en la cuenta.

7. CI/CD

• Todo deploy a producción pasa por un pipeline, nunca desde una laptop y nunca editando recursos en la consola.
• El pipeline ejecuta pruebas y hace fallar el deploy cuando fallan. Incluso una suite pequeña sobre los flujos críticos (registro, inicio de sesión, pago) atrapa muchas regresiones introducidas por la IA.
• La infraestructura está definida como código (Terraform, CloudFormation o CDK) para poder reconstruir y revisar los ambientes.
• Una persona revisa los cambios antes de que lleguen a producción, incluidos los generados por IA.

8. Rollback

• Puedes volver a la versión anterior en minutos. Mantén etiquetadas las imágenes de contenedor anteriores y conoce el comando o el botón.
• Rollback automático ante deploys fallidos donde tu plataforma lo permita. En ECS, el deployment circuit breaker puede revertir un despliegue fallido al último completado.
• Las migraciones de base de datos son retrocompatibles, de modo que el código anterior siga funcionando con el esquema nuevo mientras haces el rollback.

9. Límites de tasa y abuso

• Los endpoints públicos tienen límite de tasa. Las reglas basadas en tasa de AWS WAF cuentan las solicitudes y limitan a los orígenes que las envían demasiado rápido.
• El inicio de sesión, el registro y el restablecimiento de contraseña tienen límites más estrictos para frenar el credential stuffing y la creación de cuentas falsas.
• Los endpoints costosos tienen un tope por usuario, sobre todo los que llaman a una API de LLM, envían correos o SMS, o lanzan trabajos pesados en segundo plano. Son los endpoints donde el abuso se convierte directamente en tu factura.

10. Alarmas de costos

• Hay un AWS Budget con alertas fijado en un nivel que te sorprendería. AWS Budgets puede enviarte un correo o una notificación cuando el gasto real o proyectado cruza un umbral.
• Cost Anomaly Detection está activado, para que un gasto inusual en un servicio se marque aunque el total siga dentro del presupuesto.
• Hay límites de gasto en las APIs de terceros, sobre todo con proveedores de LLM, donde un bucle o un usuario abusivo pueden acumular cargos rápidamente.
• Los recursos están etiquetados por ambiente para ver cuánto cuesta producción frente a todo lo demás.

La versión corta

Si solo tienes un día, haz esto primero: rota cualquier secreto que se haya subido en un commit, cierra el acceso público a bases de datos y buckets, verifica la autorización en cada endpoint, activa y prueba los respaldos de la base de datos, configura una alerta de presupuesto y asegúrate de que una alarma de errores llegue a una persona. Esas seis cubren las fallas de las que es más difícil recuperarse: datos filtrados, datos perdidos y una factura desbocada.

Después, trabaja el resto como parte de tu sprint normal. La preparación para producción no es una puerta que se cruza una sola vez. Cada función nueva trae endpoints nuevos, secretos nuevos y costos nuevos, así que vale la pena repetir el checklist cada vez que la app cambia de forma.

Del checklist a la revisión de preparación para producción

Las organizaciones de ingeniería más grandes convierten una lista como esta en un paso formal. En Google, los equipos de SRE hacen una Production Readiness Review, descrita como “a process that identifies the reliability needs of a service based on its specific details” (un proceso que identifica las necesidades de confiabilidad de un servicio según sus detalles específicos), antes de asumir la responsabilidad de un servicio en producción. Un equipo pequeño no necesita la ceremonia, pero el hábito se traslada bien: antes de un lanzamiento importante, recorre el checklist con quien va a cargar con la guardia y acuerden qué puntos abiertos son aceptables.

Preguntas frecuentes

¿Qué es un checklist de preparación para producción?

Un checklist de preparación para producción es una lista de condiciones concretas y verificables que una aplicación debe cumplir antes de atender a usuarios y datos reales. Para una app en AWS suele cubrir secretos, IAM, exposición de datos, respaldos, monitoreo, logs, CI/CD, rollback, límites de tasa y alarmas de costos. Su valor está en que cada punto abierto es conocido y tiene una razón, en lugar de descubrirse durante un incidente.

¿Qué es la preparación para producción?

La preparación para producción significa que una aplicación puede manejar las condiciones que una demo nunca pone a prueba: fallas, abuso, recuperación y costo. Una app lista para producción mantiene sus secretos fuera del código, puede restaurarse desde un respaldo probado, avisa a una persona cuando los usuarios se ven afectados, hace deploy y rollback a través de un pipeline, y no generará una factura sin límite. No es una puerta que se cruza una sola vez, porque cada función nueva cambia el panorama.

¿Qué es una revisión de preparación para producción?

Una revisión de preparación para producción es un recorrido estructurado de un servicio antes del lanzamiento, en el que el equipo que lo va a operar contrasta sus necesidades de confiabilidad con una lista como la de arriba. Los equipos de SRE de Google usan una como requisito antes de hacerse cargo de un servicio. Para una startup, una revisión de una hora con el checklist y la persona de guardia cubre la mayor parte del beneficio.

Ayuda con la preparación para producción

Si quieres que un equipo construya y mantenga la app, eso es lo que hace nuestra marca hermana Avanti Studio.

Si la app ya existe y lo que necesitas es que alguien haga y mantenga la parte de AWS de este checklist, eso es lo que hace Webera. Webera es una suscripción de DevOps para equipos SaaS en AWS: ingenieros senior que trabajan junto a nueve agentes de IA, entre ellos Guardian para seguridad, Sentinel para observabilidad, Conductor para CI/CD, Optimizer para FinOps y Forge para la preparación de aplicaciones. Los agentes se encargan de vigilar, enrutar y hacer el primer análisis las 24 horas; los ingenieros toman las decisiones y entregan los arreglos.

Pro cuesta US$4,999 al mes, con solicitudes ilimitadas (dos en curso a la vez), monitoreo 24/7 y respuesta a incidentes, y un tiempo de entrega promedio de 36 horas. Elite (US$9,999) y Platform (US$14,999) añaden un ingeniero asignado, apoyo en cumplimiento normativo y un equipo dentro de tus sprints. Cada plan tiene un mínimo de tres meses y después continúa mes a mes, y todo el código es tuyo. ¿No sabes dónde estás parado? Primero evalúa a tu equipo, o compara los planes en nuestra página de precios.