Orientación: la mentalidad del Vibe Engineer

Inicia sesión para guardar tu progreso en todos tus dispositivos. Mientras tanto, se guarda en este navegador.

Por qué importa

Una demo tiene un solo usuario, que eres tú, con buena conexión, datos limpios y recorriendo el camino feliz una vez. Producción tiene miles de usuarios, redes malas, entradas hostiles, clics concurrentes, dependencias inestables, una factura de la nube y un regulador. Las herramientas de IA son excelentes haciendo demos. La distancia entre la demo y producción son exactamente los 111 elementos del póster.

Resultados de aprendizaje

1. Explicar la diferencia entre un prototipo, un MVP y un sistema en producción, y qué le debe cada uno a sus usuarios.
2. Clasificar cualquier funcionalidad según su radio de impacto (¿qué es lo peor que puede pasar si está mal?).
3. Adoptar la postura de tech lead: la IA es un ingeniero junior rápido y seguro de sí mismo que nunca dice "no lo sé".

Lecciones

0.1 Los cinco lentes de fallo

Para cualquier funcionalidad, hazte las cinco preguntas. Este es el hábito que construye toda la escuela.

0.2 Clasificación por radio de impacto

• Clase A, reversible y privada: un ajuste de UI. Publica sin miedo.
• Clase B, con datos: guarda o lee datos de usuarios. Necesita control de acceso + copias de seguridad.
• Clase C, dinero o identidad: pagos, autenticación, decisiones de crédito. Necesita idempotencia, registro de auditoría, pruebas y revisión.
• Clase D, acción irreversible o externa: enviar mensajes, mover dinero, borrar datos, acciones de agentes. Necesita aprobación humana y un kill switch (interruptor de emergencia).

0.3 Por qué el código de IA falla de formas concretas y predecibles

Los modelos de IA optimizan para "parece correcto y funciona". De forma sistemática:

• se saltan las verificaciones de autorización (el código funciona para el usuario honesto),
• ponen los secretos donde resulta cómodo (variables de entorno del frontend),
• escriben el camino feliz y se tragan los errores,
• hacen consultas dentro de bucles (N+1),
• inventan paquetes que no existen (riesgo de slopsquatting),
• dicen "listo" y "todas las pruebas pasan" sin haber ejecutado nada.

Conocer el patrón es la mitad de la defensa.

0.4 Casos de estudio (léelos antes de la semana 1)

• CVE-2025-48757, Lovable: la falta de Row-Level Security expuso acceso de lectura y escritura en más de 170 apps generadas. Lección: un cliente que habla directamente con la base de datos es tan seguro como las políticas de esa base de datos.
• Replit / SaaStr, julio de 2025: un agente con credenciales de producción borró una base de datos en vivo durante un congelamiento de código. Lección: entornos separados, mínimo privilegio, aprobación humana en operaciones destructivas y copias de seguridad probadas.
• Veracode 2026: alrededor del 44% de las tareas de generación de código con IA introdujeron una vulnerabilidad conocida; la tasa de aprobación en seguridad se ha mantenido cerca del 56% durante cuatro años. Lección: las mejoras de modelo no te van a salvar; el proceso sí.

Lab 0: Audita tu propia app

Toma una app que ya hayas construido con IA.

1. Enumera todas las funcionalidades y asigna a cada una una clase de radio de impacto.
2. Aplica los cinco lentes a las dos funcionalidades de clase más alta.
3. Ejecuta gitleaks detect sobre el historial del repo.
4. Abre las herramientas de desarrollo del navegador en la app en vivo; busca en el bundle de JS cargado key, secret, sk_, service_role.

Definition of Done

• Inventario de funcionalidades con su clase de radio de impactoEvidencia
• Notas de los cinco lentes para las dos funcionalidades más riesgosasEvidencia
• Informe de gitleaks adjunto (y cualquier clave filtrada rotada, no solo borrada)Evidencia
• Nota personal de "registro de riesgos" iniciada; te acompaña durante todo el cursoEvidencia

Pregunta de reflexión

¿Cuáles de los 111 elementos diste por hecho que tu herramienta de IA o tu plataforma de hosting "resuelve por ti"? Escribe cómo lo verificarías.