Flujo de programación con IA: criterios de aceptación, pruebas automáticas y CI

El problema práctico de programar con IA no es que el modelo escriba demasiado rápido. El problema es que muchos equipos verifican esa velocidad con el método más lento: una persona cansada leyendo un diff grande línea por línea. Parece responsabilidad, pero a menudo es solo una sensación de control. Cinco minutos de criterios de aceptación antes del prompt suelen valer más que media hora de lectura visual después.

La revisión humana sigue siendo necesaria, pero debe colocarse donde aporta más. Una persona define comportamiento, límites, riesgos, permisos y condiciones de éxito. Una persona no es buena simulando mentalmente cada rama, carrera, migración o caso de seguridad dentro de un parche generado por IA. Un código bonito puede seguir estando equivocado.

El flujo sano empieza con una orden de trabajo verificable. Debe incluir objetivo, alcance, cambios prohibidos, criterios de aceptación, casos negativos, comandos de prueba y condiciones para detenerse. “Añade login con JWT” es una petición débil. “Implementa login sin cambiar el esquema salvo esta migración; rechaza usuarios deshabilitados; rota refresh tokens; cubre contraseña inválida, token expirado y replay” es un contrato.

La documentación actual de Claude Code, GitHub Copilot coding agent y Codex apunta en la misma dirección: contexto del repositorio, instrucciones explícitas, trabajo acotado, registros, pruebas y aprobación humana. Ninguna herramienta convierte una intención vaga en software seguro por magia. El rendimiento aparece cuando el entorno define qué significa terminado.

También hay una trampa cultural. Durante años, escribir código y mirar pull requests fue la señal visible de valor profesional. Preparar criterios parecía burocracia. Con IA, esa “burocracia” se convierte en ingeniería: nombrar invariantes, datos prohibidos, permisos mínimos, rollback y pruebas que sobreviven cuando el chat ya terminó.

Los gates ejecutables son la memoria mínima de la conversación. El modelo puede olvidar una instrucción en una sesión larga; una prueba fallida no. Unit tests, integración, tipos, linters, escáneres de seguridad y una lista manual de producto forman una red mejor que el orgullo de haber leído cada línea.

Hay que incluir privacidad y coste. Los asistentes pueden recibir contexto de repositorio, logs o datos sensibles. El equipo debe conocer retención, entrenamiento, permisos y límites del proveedor. También conviene evitar sesiones enormes y dependencias que solo se entienden dentro de una herramienta cerrada. Tickets claros y CI reproducible reducen lock-in.

Este método sirve a equipos que ya delegan cambios reales en Copilot, Claude Code, Codex u otros agentes: autenticación, pagos, APIs, automatización interna y migraciones. Si no existen pruebas, staging ni rollback, el primer trabajo no debería ser una gran feature con IA, sino construir esos controles.

El cambio de identidad es incómodo: el ingeniero deja de demostrar valor leyendo cada línea y empieza a demostrarlo diseñando restricciones. Pero la ingeniería nunca fue solo teclear. Fue convertir intención ambigua en comportamiento fiable. La IA abarata el tecleo; por eso encarece la claridad.

Un hábito útil es pedir al asistente que demuestre primero la afirmación más arriesgada. Si el cambio depende de permisos, primero debe existir la prueba que falla. Si depende de rendimiento, debe existir un comando de benchmark y un presupuesto. Si depende de una API externa, hacen falta mock de fallo, regla de reintento y degradación. Así la revisión deja de buscar confianza en la estética del diff.

La persona sigue leyendo lo importante: arquitectura, mantenimiento, producto y riesgo. Pero ya no intenta ser compilador, tester y analista de seguridad al mismo tiempo. Ese cambio reduce cansancio y mejora la calidad.

La plantilla mínima cabe en una issue: objetivo, alcance, cosas prohibidas, criterios, casos negativos, comandos de verificación, responsable de revisión y rollback. En pocas semanas se vuelve una costumbre común. Los nuevos miembros entienden antes qué puede delegarse al agente y qué necesita una conversación de arquitectura. Los seniors gastan menos energía en cosmética y más en límites reales del sistema.