El trinquete de complejidad de los agentes de IA: por qué se requiere 90% de cobertura de pruebas

El trinquete de complejidad en la era de la programación con IA (Complexity Ratchet) - resumen del ensayo de Garry Tan

Se trata de un largo ensayo que Garry Tan (CEO de Y Combinator) compartió en X, donde organiza su experiencia de los últimos 12 meses creando dos proyectos de código abierto junto con agentes de IA (Claude Code, Codex, etc.). Según cuenta, la IA escribió la mayor parte de unas 970 mil líneas de código y 665 archivos de pruebas, y además operó 15 sesiones de agentes al mismo tiempo. A partir de ese proceso, sostiene que el viejo axioma de la ingeniería de software de que "velocidad y calidad son una disyuntiva" ya se rompió, y presenta como mecanismo central el concepto de "trinquete de complejidad (Complexity Ratchet)".

Conceptos clave

• Qué es un trinquete (Ratchet): una metáfora tomada de un mecanismo dentado que solo avanza en una dirección; aquí se refiere a una estructura que hace que la calidad de la base de código avance sin retroceder.
• Tres acumulaciones: en cada sesión de programación con agentes, se agregan a la base de código tres cosas: pruebas (qué es correcto), documentación (por qué se tomó esa decisión) y resultados de evaluación (la línea base de calidad).
• Uso de la ventana de contexto: como en la siguiente sesión el agente de IA lee esas tres capas antes de trabajar, ya no puede romper las pruebas, ignorar la documentación ni bajar la puntuación de evaluación.

Diferencias frente al enfoque tradicional

• Cambio en el modelo de error: durante los últimos 50 años, la ingeniería de software construyó procesos complejos como code review, QA y staging bajo la premisa de que "los errores son fatales y hay que prevenirlos"; ahora, en cambio, la mayoría de los errores pueden ser diagnosticados y corregidos por un agente en el siguiente turno.
• Expansión del límite de complejidad: el techo de complejidad de un sistema se amplió desde "lo que un equipo puede tener en la cabeza" hasta "una persona y agentes que cargan en contexto toda la base de código".
• Persistencia de la memoria institucional: las personas se van por renuncia o burnout, pero el conocimiento que queda en pruebas y documentación puede recuperarse en cualquier momento y con cualquier modelo.

El significado del 90% de cobertura de pruebas

• Curva de calidad no lineal: según un estudio de Capers Jones sobre más de 10 mil proyectos, con una cobertura menor a 70% la tasa de eliminación de defectos se queda en 65~75%, pero entre 85~95% aparece un "punto de inflexión" donde sube de golpe a 92~97%.
• Precedente en la industria aeronáutica: el estándar de software aeronáutico DO-178C exige cobertura MC/DC para sistemas Level A (críticos), con el objetivo de lograr una eliminación de defectos superior al 99%.
• La IA rompió la barrera de costos: completar el último 20% de cobertura era una tarea aburrida y costosa para humanos, pero los agentes no se cansan, así que pueden escribir pruebas de edge cases sin parar incluso de madrugada.

Casos reales presentados por el autor

• Mejora en la precisión de extracción de GBrain: en más de 100 mil extracciones de creencias, fijó con 17 pruebas un problema que confundía en 35% de los casos "quién hizo esa afirmación", de modo que ninguna versión posterior pueda volver a caer por debajo de ese nivel.
• Pruebas TTY de Superpowers: el agente de IA fue vigilado y bloqueado directamente usando la funcionalidad de pseudoterminal de Bun cuando intentaba saltarse revisiones interactivas, convirtiendo en algo testeable incluso un requisito no tradicional como "¿la IA realmente mantuvo la conversación?".

Ventajas y límites

• Ventajas: incluso si una persona colaboradora externa no entiende todo el sistema, puede hacer merge de un PR de forma segura con solo pasar las pruebas, lo que reduce la barrera de entrada para colaborar.
• Límites: los errores que destruyen estado (migraciones de base de datos incorrectas, brechas de seguridad, filtraciones de privacidad) siguen siendo fatales, y cerca del 10% de los puntos de integración y de la infraestructura son inherentemente difíciles de probar.
• Respuesta a las objeciones: frente a la crítica de que "quien sabe escribir buenas pruebas también sabe diseñar bien la arquitectura", el autor subraya que la esencia del trinquete no es la persona, sino la red de seguridad del siguiente turno.

La idea central que el autor quiere transmitir en este texto es que el verdadero valor de programar con IA no está en "escribir rápido", sino en haber vuelto prácticamente gratis un nivel de verificación que hasta ahora se abandonaba por ser demasiado caro. La observación es que una cobertura de pruebas del 90%, que durante 50 años fue patrimonio de sectores como el aeronáutico o el médico, ahora puede formar parte de la rutina de una sola persona, y que como resultado el techo de complejidad del software que puede construir un único desarrollador se elevó de forma drástica. Aun así, el propio texto también funciona como promoción de sus proyectos de código abierto (Superpowers, GBrain), y algunas citas estadísticas (por ejemplo, GPT-5.5) requieren verificación, por lo que también exige una lectura crítica.