El trinquete de la complejidad en la era de la programación con IA: por qué se necesita 90% de cobertura de pruebas

Un extenso ensayo que Garry Tan (CEO de Y Combinator) compartió en X, donde resume su experiencia de haber creado durante el último año 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 al mismo tiempo operó 15 sesiones de agentes. A partir de este proceso, sostiene que se ha roto el viejo axioma de la ingeniería de software de que "velocidad y calidad son una disyuntiva", y presenta como mecanismo central el concepto de "trinquete de la complejidad (Complexity Ratchet)".

Conceptos clave

• Qué es un trinquete (Ratchet): una metáfora tomada del mecanismo de rueda dentada que solo avanza en una dirección; aquí se refiere a una estructura que hace que la calidad de la base de código solo pueda avanzar, sin retrocesos.
• Tres acumulaciones: en cada sesión de programación con agentes se van acumulando en la base de código tres elementos: pruebas (qué es correcto), documentación (por qué se decidió así) 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 esos tres elementos 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 revisión de código, QA y staging bajo la premisa de que "los errores son fatales, así que hay que prevenirlos". Ahora, en cambio, la mayoría de los errores pueden ser diagnosticados y corregidos por el agente en el siguiente turno.
• Expansión del límite de complejidad: el techo de complejidad de un sistema se amplió de "lo que un equipo puede mantener en la cabeza" a "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 volver a recuperarse con cualquier modelo y en cualquier momento.

El significado de 90% de cobertura de pruebas

• Curva de calidad no lineal: según un estudio de más de 10 mil proyectos de Capers Jones, con una cobertura menor a 70% la tasa de eliminación de defectos se queda en 65~75%, pero entre 85~95% sube bruscamente a 92~97%; existe un "punto de inflexión".
• 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 fin de alcanzar una tasa de eliminación de defectos superior a 99%.
• La IA rompió la barrera de costo: completar el 20% final de cobertura era una tarea aburrida y costosa para humanos, pero los agentes no se cansan, así que pueden escribir sin parar pruebas de casos límite incluso de madrugada.

Casos reales que presenta el autor

• Mejora en la precisión de extracción de GBrain: en más de 100 mil extracciones de creencias, había un problema en el que se confundía en 35% de los casos "quién hizo esa afirmación". Con 17 pruebas, fijaron esa condición para que ninguna versión posterior pueda volver a caer por debajo de ese nivel.
• Pruebas TTY en Superpowers: el agente de IA tendía a saltarse la revisión interactiva, así que lo supervisaron y bloquearon directamente con la función de pseudoterminal de Bun, convirtiendo en algo testeable incluso un requisito no tradicional como "¿la IA realmente tuvo la conversación?".

Ventajas y límites

• Ventajas: aunque un contribuidor externo no entienda todo el sistema, si logra pasar las pruebas puede hacerse merge de su PR de forma segura, lo que baja la barrera de entrada para colaborar.
• Límites: los errores que destruyen estado (migraciones erróneas de BD, brechas de seguridad, filtraciones de privacidad) siguen siendo críticos, y alrededor de 10% de los puntos de integración y la infraestructura son intrínsecamente difíciles de probar.
• Respuesta a la crítica: frente a la objeción de que "quien escribe buenas pruebas normalmente también diseña buena arquitectura", el autor enfatiza 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 es que el verdadero valor de programar con IA no está en "escribir más rápido", sino en haber vuelto casi gratuito un nivel de verificación que hasta ahora se abandonaba por demasiado costoso. Su observación es que una cobertura de pruebas de 90%, antes reservada durante 50 años a industrias como la aeronáutica o la medicina, ahora puede formar parte de la rutina de una sola persona, y que como resultado el techo de complejidad del software que un solo desarrollador puede construir aumentó de forma dramática. Aun así, el texto también funciona como promoción de sus propios 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.

[skymer]

https://www.youtube.com/watch?v=mJ2GZRV63TE
La persona que hizo un blog en RoR con 4 veces más LOC que sqlite...