Módulo 01Trimestre 1 · Fundamentos

El flujo de trabajo de ingeniería asistida por IA

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

Por qué importa

La investigación de DORA de 2025 describe la IA como un amplificador del sistema en el que aterriza. Los equipos con lotes pequeños, pruebas y feedback rápido van más rápido. Los equipos sin eso publican bugs más rápido. Este módulo instala el sistema antes de que instales más IA.

Resultados de aprendizaje

  1. Escribir una especificación y pruebas de aceptación contra las que una IA pueda construir.
  2. Diseñar el contexto: archivos de reglas, notas de arquitectura, ejemplos, restricciones.
  3. Trabajar en lotes pequeños y revisables, con git como red de seguridad.
  4. Revisar la salida de la IA de forma sistemática y obligarla a demostrar lo que afirma.
  5. Medir la entrega con las cinco métricas de DORA.

Lecciones

1.1 Primero la especificación, después el prompt

Una buena tarea para la IA contiene: objetivo, contexto, restricciones, interfaces, criterios de aceptación, fuera de alcance.

GOAL: Users can reset their password by email.
CONTEXT: Next.js app router, Supabase auth, Resend for email. See /docs/architecture.md.
CONSTRAINTS: Token single-use, expires in 30 min, stored hashed. Rate limit 5 requests/hour per email and per IP. Same response whether or not the email exists.
ACCEPTANCE: tests in /tests/reset.spec.ts must pass (write them first).
OUT OF SCOPE: SMS reset, UI redesign.

1.2 Ingeniería de contexto

  • Un archivo de reglas a nivel de repo (Plantilla de AGENTS.md) con los estándares que la IA debe seguir siempre.
  • /docs/architecture.md: componentes, flujo de datos, fronteras de confianza.
  • /docs/decisions/: ADRs para que la IA no vuelva a discutir decisiones ya tomadas.
  • Señálale a la IA un buen ejemplo existente en el código; copiará los patrones fielmente, sean buenos o malos.

1.3 Lotes pequeños y disciplina con git

  • Una funcionalidad por rama; un tema por commit.
  • Haz commit antes de cada sesión con la IA para poder ver con git diff todo lo que cambió y deshacer con git restore lo que no te guste.
  • Nunca dejes que un agente ejecute git push --force, migraciones contra producción ni comandos de borrado sin aprobación.
  • Los cambios pequeños son, según DORA, la palanca más eficaz tanto para la velocidad como para la estabilidad.

1.4 Las pruebas como especificación

La pirámide de pruebas, adaptada a la IA:

  • Pruebas unitarias: lógica pura (precios, elegibilidad, validación).
  • Pruebas de integración: base de datos real en Docker, consultas reales, políticas de RLS reales.
  • Pruebas end-to-end: Playwright en los recorridos críticos (registro, pago, acción principal).
  • Pruebas de seguridad: pruebas de autorización del tipo "el usuario A no puede leer los datos del usuario B". La prueba más valiosa que vas a escribir.
  • Evals: para funcionalidades con LLM (ver 06 · Seguridad de IA y agentes).

Regla: escribe o revisa tú las pruebas; deja que la IA escriba la implementación. Si la IA escribe ambas, puede equivocarse en las dos de la misma manera.

1.5 Revisar la salida de la IA

El checklist de revisión (pégalo en tu plantilla de PR):

  1. ¿Cada endpoint verifica quién llama y si es dueño del recurso?
  2. ¿Hay algún secreto, clave o token fuera de las variables de entorno del servidor?
  3. ¿Hay alguna llamada externa sin timeout?
  4. ¿Hay alguna consulta a la base de datos dentro de un bucle?
  5. ¿Hay alguna dependencia nueva? ¿Existe, se mantiene, está fijada (pinned)?
  6. ¿Los errores se manejan, se registran y se exponen, o se los traga?
  7. ¿El cambio es reversible? ¿Hay una migración? ¿Es compatible hacia atrás?
  8. ¿Tocó archivos fuera del alcance de la tarea?

Obliga a la IA a demostrar lo que afirma: "Ejecuta las pruebas y pega la salida." "Muéstrame el plan de EXPLAIN." "Muéstrame el curl que demuestra que el usuario A recibe un 403 sobre el registro del usuario B."

1.6 Medir la entrega: las cinco métricas de DORA

Grupo Métrica
Throughput Lead time de cambios; frecuencia de despliegue; tiempo de recuperación de despliegues fallidos
Inestabilidad Tasa de fallo de cambios; tasa de retrabajo de despliegues

DORA advierte contra convertirlas en objetivos (ley de Goodhart). Úsalas para encontrar cuellos de botella.

1.7 Calidad básica que la IA se salta

Linting y formateo en la CI, modo strict de TypeScript, accesibilidad (HTML semántico, etiquetas, navegación con teclado, contraste según WCAG 2.2 AA) y validación de entradas con una librería de esquemas (Zod, Valibot) en cada frontera.

Lab 1: Construye una funcionalidad como un profesional

Construye "restablecer contraseña" o "invitar a un compañero de equipo" usando la plantilla de especificación.

  1. Escribe primero la especificación y las pruebas (la IA puede ayudar con el borrador; tú apruebas).
  2. Haz que la IA lo implemente en una rama.
  3. Revisa con el checklist; registra cada problema encontrado.
  4. Abre un PR; la CI debe ejecutar lint, verificación de tipos y pruebas.

Definition of Done

Pack de prompts para la IA

  • "Antes de escribir código, enumera los casos límite y los modos de fallo de esta especificación. No implementes todavía."
  • "Escribe pruebas que fallarían si faltara la autorización."
  • "Revisa este diff como un ingeniero senior hostil. Enumera solo los problemas, ordenados por gravedad."