Lo que Dijkstra documentó en 1970 y la IA acaba de confirmar

01

Lo que Dijkstra documentó en 1970 y la IA acaba de confirmar

En 1970, Edsger W. Dijkstra escribió una frase que la industria del software tardó cinco décadas en tomar en serio: el testing de un programa puede demostrar la presencia de errores, pero nunca su ausencia. No era una opinión. Era una afirmación de naturaleza matemática, documentada en Notes on Structured Programming (EWD249) y reafirmada dos años después en su conferencia Turing de 1972, "The Humble Programmer" (EWD340).

El argumento de Dijkstra era de escala cognitiva, no de capacidad técnica. Un programador competente, escribió, debe ser plenamente consciente del tamaño estrictamente limitado de su propio cráneo. El software no tiene contraparte física: no hay tabla que medir ni nudo que anticipar. Cambiar un operador, invertir el orden de dos instrucciones, corregir un valor de retorno: cualquiera de esos cambios puede propagarse en cascada por millones de rutas de ejecución posibles, muchas de las cuales ningún conjunto de pruebas recorrerá jamás. La complejidad del software no crece con su tamaño de forma lineal. Crece de forma combinatoria. Y el cráneo humano tiene capacidad finita y estrictamente limitada para contener esa combinatoria.

Dijkstra llamó a esto la "crisis del software": a medida que las máquinas se volvían más potentes, la ambición de las organizaciones por usarlas crecía en la misma proporción, y el programador quedaba atrapado entre esas dos fuerzas. Más poder de cómputo no resolvió el problema, lo amplificó. Los sistemas reales acumularon décadas de decisiones, parches y capas de integración que nadie documentó del todo. Auditarlos en profundidad, buscando los bugs que el testing nunca detectó porque nunca buscó en esa dirección, llevaría décadas de trabajo humano. Dijkstra lo sabía, y no tenía solución para ofrecer. La única salida que vislumbraba era disciplina estructural: escribir programas cuya corrección pudiera demostrarse formalmente, como se demuestra un teorema. Una aspiración matemáticamente sólida que el mundo real ignoró casi por completo.

Lo que cambió

Los LLM entrenados sobre código no tienen cráneo. No se cansan en la línea 50.000. No pierden el hilo de una función definida 300 archivos más arriba. Dos papers recientes miden con precisión lo que esto implica en la práctica.

IRIS (arXiv:2405.17238, MIT/Penn, ICLR 2025) combina LLMs con análisis estático para auditar repositorios completos en Java. Evaluado sobre 120 vulnerabilidades reales validadas manualmente, la herramienta de referencia industrial CodeQL detectó 27. IRIS con GPT-4 detectó 55, más del doble, e identificó además 4 vulnerabilidades previamente desconocidas que ninguna herramienta existente podía encontrar.

RepoAudit (arXiv:2501.18160, Purdue, ICML 2025) es un agente autónomo que recorre repositorios completos analizando rutas de flujo de datos, sin requerir compilación previa. Sobre 15 proyectos reales de producción detectó 40 bugs verdaderos con una precisión del 78,4%, superando en sensibilidad a los detectores industriales de Meta y Amazon. El costo promedio por proyecto: 0,44 horas y 2,54 dólares. Además identificó 185 bugs nuevos en proyectos de alto perfil, de los cuales 174 fueron confirmados y corregidos por sus mantenedores.

Estos resultados no refutan a Dijkstra en el plano teórico. El problema de la ausencia de bugs sigue siendo irresoluble en términos formales: ningún sistema de auditoría, incluyendo uno basado en IA, puede garantizar que no existan errores en las rutas que no exploró. Pero lo que sí cambia es la escala de lo explorable. El espacio que antes quedaba fuera del alcance cognitivo humano, ese donde los bugs duermen desde hace décadas sin que ningún equipo los haya buscado, tiene ahora un explorador que no se fatiga y que puede recorrerlo a un costo antes impensable.

Dijkstra describió el problema con precisión quirúrgica en 1970. En 2025, por primera vez, hay herramientas que operan a la escala que él consideraba irrealizable para el ser humano.