Adam Langley afirma que la automatización de pruebas en Lean ya está aquí. La parte difícil simplemente se trasladó

Adam Langley afirma que la automatización de pruebas en Lean superó un umbral práctico después de que varios modelos de lenguaje de gran tamaño completaran una difícil prueba de software en unos 20 minutos. La afirmación incluye una salvedad importante: la IA generó la prueba, pero Lean verificó cada paso frente a una especificación formal.

Esa distinción separa este experimento de otra historia sobre IA produciendo código plausible. Langley construyó un descompresor Zstandard en Lean y luego pidió a los modelos demostrar propiedades universales de su tabla de decodificación de entropía. Según los informes, los modelos terminaron sin huecos de prueba sin resolver, aunque también modificaron partes de su implementación.

El experimento apunta hacia un acuerdo distinto para los equipos de software. Los desarrolladores podrían dedicar menos tiempo a construir pruebas y más a decidir exactamente qué deben garantizar sus sistemas. Los asistentes de programación con IA generan una respuesta y piden a los humanos que encuentren errores. Lean invierte esa relación al rechazar cualquier respuesta que no satisfaga una afirmación verificable por máquina.

Esto no demuestra que la verificación formal se haya vuelto barata, sencilla o apropiada para todas las aplicaciones. Langley describió el descompresor como un juguete, no publicó su código fuente y midió su rendimiento en una décima parte de la velocidad del comando estándar zstd. Investigaciones independientes también muestran que los demostradores basados en IA tienen dificultades cuando las pruebas dependen de repositorios grandes y desconocidos.

La conclusión más defendible sigue siendo significativa. La IA ya puede absorber suficiente trabajo repetitivo de demostración como para que valga la pena probar la verificación fuera de sus nichos tradicionales. Para los trabajadores del conocimiento, la lección más amplia va más allá del software: la automatización se vuelve más fiable cuando los criterios de aceptación son explícitos y se verifican de forma independiente.

Un experimento con Zstandard puso a trabajar la automatización de pruebas en Lean

La noticia no es que una IA haya escrito otro programa. Es que un trabajo generado por IA superó un verificador diseñado para rechazar errores lógicos.

Langley, un ingeniero de seguridad conocido por su trabajo en criptografía e infraestructura de internet, publicó el experimento el 26 de julio de 2026. Su relato sobre automatización de pruebas describe la construcción de un descompresor Zstandard en Lean y la formalización de varias propiedades de sus tablas de decodificación.

Lean es tanto un lenguaje de programación funcional como un asistente de pruebas. Un asistente de pruebas verifica si un argumento formal establece una proposición expresada con precisión. El pequeño núcleo de Lean valida el término de prueba resultante, por lo que los usuarios no necesitan confiar en el modelo que lo produjo.

La prueba se centró en la Entropía de Estados Finitos, o FSE, que Zstandard utiliza para codificar algunos valores de manera eficiente. FSE asigna símbolos a través de una tabla de estados según sus probabilidades. Cada estado identifica un símbolo, el número de bits que se deben leer y una base para calcular el estado siguiente.

Una tabla correcta debe preservar varias relaciones. Necesita el número esperado de entradas, la asignación correcta para cada símbolo y transiciones válidas para todos los estados posibles. Cada símbolo con probabilidad distinta de cero también debe tener exactamente una ruta hacia cada estado objetivo.

Las pruebas unitarias pueden comprobar ejemplos seleccionados de la especificación de Zstandard. No pueden establecer que estas propiedades se cumplan para cada entrada válida. En su lugar, Langley escribió un teorema que cubre la función completa de construcción de tablas.

Según los informes, varios LLM produjeron una prueba en unos 20 minutos. Langley confirmó que Lean aceptó el resultado y que los archivos no contenían declaraciones sorry, que los desarrolladores de Lean utilizan como marcadores de posición para pruebas faltantes.

Los modelos no se limitaron a rellenar un espacio aislado. Modificaron el código de generación de tablas porque Langley había usado demasiada estructura de estilo imperativo. Esa estructura era más difícil de analizar para la maquinaria de pruebas.

Este detalle importa porque revela tanto el atractivo como el coste. La IA se encargó de construir la prueba, pero la implementación aún necesitaba una forma que facilitara el razonamiento. La verificación no llegó como un botón final de control de calidad aplicable a código arbitrario.

Langley también evitó presentar el proyecto como evidencia de producción. El código sigue sin publicarse, el decodificador cubría un experimento acotado y su rendimiento quedó por detrás de la implementación consolidada. Su afirmación se refiere a la disponibilidad de automatización de pruebas, no a la preparación de este descompresor concreto.

Un proyecto relacionado ofrece un punto de referencia más amplio. El creador de Lean, Leonardo de Moura, destacó una implementación de zlib asistida por IA que superó pruebas y demostró la corrección de ida y vuelta en todos los niveles de compresión. Juntos, estos ejemplos acercan la demostración con IA al código ordinario de sistemas.

Aun así, dejan una brecha entre un artefacto impresionante y un proceso de ingeniería repetible. Cerrar esa brecha determinará si la automatización de pruebas en Lean se convierte en una herramienta de desarrollo común o sigue siendo una demostración para expertos.

La antigua barrera era el trabajo de demostración, no la verificación de pruebas

La verificación formal ya ofrecía garantías sólidas. Su problema económico era el esfuerzo humano necesario para formularlas y mantenerlas.

Una prueba normal pregunta si el software se comportó correctamente en los ejemplos ejecutados. La verificación formal pregunta si un modelo matemático satisface una propiedad expresada para cada entrada dentro de ese modelo. Esa promesa más amplia crea una carga de trabajo mucho mayor.

El micronúcleo seL4 sigue siendo uno de los ejemplos históricos más claros. Su equipo de verificación produjo una prueba verificada por máquina que conecta la implementación del núcleo con su especificación formal. El proyecto demostró que era posible verificar software de producción de alta garantía y gran escala.

También documentó el coste. Según la retrospectiva del proyecto del equipo, la verificación requirió aproximadamente diez veces el esfuerzo invertido en diseñar e implementar el código C. El material de prueba superó en más de veinte veces las líneas de la implementación.

Estas cifras no significan que todos los proyectos verificados hereden la misma proporción. seL4 persiguió garantías inusualmente amplias en un núcleo de sistema operativo considerable. Sí explican por qué la mayoría de las organizaciones de software eligieron en su lugar pruebas, revisiones, análisis estático y monitorización operativa.

La automatización tradicional redujo parte de esta carga. Herramientas como los solucionadores SMT, que buscan soluciones para restricciones lógicas, pueden resolver obligaciones de prueba rutinarias. Funcionan bien cuando el problema encaja en las teorías admitidas y la estructura esperada por el solucionador.

La experiencia se vuelve menos predecible cuando un objetivo queda fuera de esa zona cómoda. Los desarrolladores pueden esperar sin saber si un solucionador necesita más tiempo o nunca terminará. Los equipos también aprenden patrones de implementación que hacen que el solucionador funcione, lo que crea otra disciplina de ingeniería especializada.

Los LLM abordan la tarea de otra manera. Pueden leer definiciones, mensajes de error, lemas cercanos y explicaciones informales. Pueden proponer resultados intermedios, revisar tácticas fallidas y reorganizar código cuando la representación actual bloquea el avance.

Esa flexibilidad convierte la generación de pruebas en un objetivo natural para los modelos de lenguaje. No es necesario confiar en un modelo como autoridad final. Debe producir un artefacto que el núcleo de pruebas acepte.

Esto encaja mejor que muchas tareas de automatización de oficina. Un memorando estratégico generado no tiene un verificador completo de veracidad, relevancia y criterio. Una prueba en Lean tiene una condición de aceptación acotada que el software puede evaluar de manera determinista.

El resultado cambia la división esperada del trabajo. Los humanos especifican la propiedad, seleccionan las suposiciones y deciden si el modelo representa la realidad. La IA busca una prueba, mientras Lean verifica el resultado propuesto.

Eso no elimina el trabajo humano. Traslada el esfuerzo hacia la especificación, la arquitectura y la revisión. Estas actividades son más difíciles de automatizar porque requieren decidir qué resultados importan.

Para los trabajadores del conocimiento, esta es la historia más profunda de productividad. La automatización más sólida no solo produce más material. Conecta el material generado con condiciones explícitas que determinan si el resultado es aceptable.

Este principio también se aplica al trabajo de investigación y operaciones. Un equipo que utiliza una base de conocimiento personal puede recuperar evidencia antes de generar una respuesta. El resultado aún necesita criterios que cubran la calidad de las fuentes, el alcance y la actualidad.

Lean hace que esos criterios sean inusualmente estrictos. Su lección no es que todas las tareas necesiten un demostrador de teoremas. Es que la automatización se vuelve más fiable cuando la organización puede definir un contrato verificable.

La IA cambia el coste de demostrar, no el significado de la corrección

La automatización de pruebas en Lean puede verificar que el código cumple una especificación, pero no puede decidir si la especificación representa el problema correcto.

Esta es la inversión central del experimento de Langley. El razonamiento incierto de los modelos no socava automáticamente la prueba porque Lean verifica su resultado final. Sin embargo, ese mismo verificador no puede rescatar un teorema que formaliza el requisito equivocado.

Supongamos que un teorema sobre un descompresor demuestra que cada transición de estado generada permanece dentro de la tabla. Eso es valioso, pero no establece compatibilidad con todos los archivos Zstandard. Tampoco dice nada sobre el comportamiento ante denegación de servicio, los límites de memoria, los canales laterales o el rendimiento de la implementación.

Cada garantía adicional necesita una afirmación correspondiente y una conexión con el programa real. Si esa conexión omite una suposición, Lean puede demostrar la afirmación formal mientras el sistema desplegado sigue siendo vulnerable.

El problema se parece a un contrato bien redactado que regula la transacción equivocada. Una consistencia interna perfecta no puede reparar una obligación ausente. La verificación aumenta la confianza dentro del límite que las personas definieron.

El teorema FSE de Langley ilustra el mejor caso. Las propiedades se corresponden directamente con las suposiciones necesarias para el bucle de decodificación optimizado. El tamaño de la tabla, la asignación de símbolos, las transiciones válidas y la alcanzabilidad única son invariantes concretos, no afirmaciones generales sobre la calidad.

Una vez que existen esos invariantes, el compilador y el núcleo pueden imponerlos en todo el programa. Una futura edición que viole alguno de ellos no pasará la comprobación de tipos hasta que cambie la implementación o la prueba.

Esto crea una superficie de revisión distinta. Los ingenieros no necesitan examinar miles de pasos de prueba generados con la misma atención. Necesitan auditar el teorema, sus suposiciones y la conexión entre el código y el modelo.

Ahí es donde se desplaza la experiencia escasa. Un ingeniero sénior que antes dedicaba días a guiar tácticas podría dedicar esos días a refinar el contrato formal. La IA se encarga de gran parte de la búsqueda mecánica, mientras los revisores humanos evalúan si el contrato merece confianza.

El enfoque también puede hacer que los desacuerdos sean más productivos. Los equipos de producto, seguridad e ingeniería suelen usar la misma palabra, como «válido», con definiciones distintas. Una especificación formal obliga a convertir esas definiciones en condiciones visibles.

El trabajo del conocimiento sufre el mismo problema de invariantes ocultos. Un análisis de mercado podría necesitar fuentes actuales, una región definida y un periodo de reporte fijo. Los equipos suelen dejar esas restricciones en comentarios, notas de reuniones o en la memoria de un empleado.

La IA puede generar un informe pulido mientras incumple silenciosamente cualquiera de ellas. Un flujo de trabajo mejor representa las restricciones importantes antes de que comience la generación. Algunas condiciones pueden convertirse en comprobaciones automatizadas, mientras que otras siguen siendo preguntas explícitas de revisión.

Por eso la combinación de conocimiento importa en el trabajo asistido por IA. El resultado generado es más fácil de evaluar cuando permanece conectado con los registros, decisiones y evidencias pertinentes. La comprobación es menos absoluta que el kernel de Lean, pero el principio operativo es similar.

Por lo tanto, las organizaciones deberían resistirse a la interpretación más fácil de la automatización de pruebas. El beneficio no es tener permiso para dejar de revisar los resultados de IA. Es una oportunidad para revisar en una capa de mayor valor.

La generación de pruebas se vuelve más barata. Definir la corrección pasa a ser más central. Los equipos que no pueden acordar los requisitos no obtendrán garantías sólidas simplemente añadiendo Lean o un demostrador de IA.

La verificación formal con Lean ahora presiona a los flujos de trabajo basados solo en pruebas

La presión inmediata recae sobre los equipos que desarrollan código sensible para la seguridad y que todavía consideran las pruebas como la máxima garantía disponible.

Las pruebas siguen siendo esenciales porque evalúan ejecuciones reales, integraciones, rendimiento y comportamiento del entorno. La verificación formal responde a una pregunta distinta. Comprueba si un modelo satisface una propiedad en todos los casos cubiertos por la prueba.

Ningún método sustituye al otro. Langley utilizó vectores de prueba de Zstandard como pruebas unitarias normales mientras demostraba propiedades más amplias del generador de tablas. Las pruebas verificaban ejemplos de compatibilidad, mientras que el teorema cubría invariantes estructurales universales.

El cambio es económico. La verificación formal exigía antes tanto trabajo especializado que muchos equipos podían descartarla antes de evaluar sus beneficios. Si la IA reduce el tiempo de construcción de pruebas, resulta más difícil defender ese descarte automático.

El software criptográfico ofrece un campo de prueba temprano. Pequeños errores aritméticos pueden invalidar sistemas de seguridad mayores, y muchas funciones importantes ya cuentan con especificaciones matemáticas. El valor de las garantías universales es excepcionalmente claro.

Un informe de experiencia de mayo de 2026 describió una canalización de verificación para Rust que traduce código criptográfico de producción a Lean. Combina herramientas de extracción de Rust, bibliotecas de especificaciones formales y demostradores de IA como Aristotle y Aleph.

Los investigadores aplicaron la canalización a componentes de Plonky3 y RISC Zero. Los objetivos incluían aritmética de campos, verificación de inclusión de Merkle, evaluación de polinomios y operaciones FRI utilizadas por sistemas de conocimiento cero. Cada prueba enviada seguía pasando por el kernel de Lean.

El artículo también documenta fricciones de ingeniería. Las versiones de la cadena de herramientas cambiaban, las herramientas de traducción solo admitían partes de Rust y la falta de lemas bloqueaba la automatización. Los demostradores de IA resolvieron algunas obligaciones, mientras que otras siguieron requiriendo trabajo manual.

Esta evidencia respalda una previsión mesurada. La verificación probablemente entrará en producción a través de componentes acotados y de alto valor, en lugar de aplicaciones empresariales completas. Los equipos pueden comenzar con analizadores sintácticos, reglas de autorización, operaciones criptográficas y lógica de transición de estados.

Estos componentes tienen tres propiedades útiles. Su comportamiento suele poder especificarse con precisión, los fallos tienen costes elevados y sus límites son lo bastante pequeños para que las herramientas actuales los comprendan.

La presión también alcanzará a los proveedores que venden sistemas de programación con IA. Generar más código se está volviendo menos distintivo. Producir código con propiedades verificables de forma independiente constituye una afirmación más sólida.

Con el tiempo, un agente de programación podría devolver tres artefactos conectados: una implementación, una declaración formal del comportamiento requerido y una prueba comprobada por el kernel. Los revisores podrían centrarse en si la declaración coincide con el requisito del producto.

Las plataformas centradas en pruebas responderán en lugar de desaparecer. Cabe esperar combinaciones más potentes de fuzzing, pruebas basadas en propiedades, ejecución simbólica y pruebas formales. Las pruebas generadas seguirán encontrando discrepancias entre los modelos formales y los entornos de despliegue desordenados.

Los proveedores de verificación formal también afrontan presión. Su ventaja tradicional incluye la escasa experiencia disponible en construcción de pruebas. La IA reduce el valor del trabajo repetitivo con tácticas, al tiempo que aumenta la demanda de diseño de especificaciones, integración y arquitectura de garantías.

Los responsables no deberían interpretar este cambio como una reducción inmediata de contrataciones. La adopción temprana suele crear trabajo de integración antes de eliminar trabajo de mantenimiento. Los equipos necesitarán personas que comprendan tanto el dominio de la aplicación como el límite de la prueba.

Por tanto, la pregunta útil no es si Lean sustituye a la programación convencional. Es qué supuestos costosos pueden pasar ahora de los comentarios y las listas de revisión a contratos impuestos por la máquina.

Lo que el resultado de Zstandard no demuestra

Un único decodificador de juguete no publicado no puede demostrar que los demostradores de IA actuales escalen a repositorios de producción, cambios frecuentes o sistemas mal especificados.

Langley expuso directamente estas limitaciones. Su decodificador funcionaba aproximadamente diez veces más lento que el comando zstd en su equipo. También advirtió que los tipos fuertes pueden amplificar los cambios porque los supuestos revisados se propagan a través de los tipos derivados.

Esa propagación puede ser un beneficio. Expone cada componente dependiente que requiere atención. También puede convertir un pequeño cambio de producto en un gran proyecto de mantenimiento de pruebas.

El rendimiento crea otra compensación. Lean puede realizar actualizaciones in situ cuando un objeto tiene una única referencia. Por lo tanto, un pequeño cambio de código que conserve otra referencia puede perjudicar el rendimiento sin modificar la corrección funcional.

La automatización de pruebas no detecta automáticamente esa regresión. El teorema debe incluir un modelo de rendimiento adecuado, o bien otra prueba comparativa debe detectarla. La corrección y la eficiencia siguen siendo afirmaciones de ingeniería separadas.

La escala del repositorio plantea el desafío más importante. El ejemplo de Langley tenía una implementación enfocada y un teorema conectado con definiciones cercanas. Los sistemas de producción distribuyen el significado entre paquetes, código generado, configuraciones de compilación, bases de datos y servicios externos.

El estudio VeriSoftBench de 2026 probó este problema utilizando 500 obligaciones de prueba de 23 repositorios Lean de código abierto. Su benchmark de repositorios preservó definiciones específicas de cada proyecto y dependencias entre archivos.

Los investigadores descubrieron que los demostradores entrenados con tareas de Lean orientadas a las matemáticas se transferían mal a la verificación de software centrada en repositorios. El rendimiento disminuía a medida que las pruebas dependían de cadenas más grandes y de varios pasos de definiciones locales.

Proporcionar contexto cuidadosamente seleccionado mejoró los resultados frente a exponer un repositorio completo. Aun así, dejó un margen considerable de mejora. La recuperación de contexto ayudó, pero no resolvió el problema de razonamiento.

Ese hallazgo limita directamente la interpretación más fuerte de la afirmación de Langley. Los LLM pueden producir hoy pruebas de software significativas. Todavía no pueden manejar todas las obligaciones de prueba simplemente porque un proyecto use Lean.

También existe una brecha de verificación en torno al experimento publicado. Los lectores pueden examinar la explicación, la declaración del teorema y las salvedades de Langley. No pueden reproducir el resultado completo porque no publicó el decodificador ni los archivos de prueba.

Su confirmación de que no quedaban declaraciones sorry es una evidencia útil de primera mano. No equivale a una compilación independiente desde un repositorio fijado. El resultado debe tratarse como un informe de ingeniería creíble, no como un benchmark.

Los equipos de seguridad también deben examinar la base de computación confiable. El kernel de Lean es intencionalmente pequeño, y las implementaciones independientes del kernel pueden comparar resultados. Sin embargo, los despliegues siguen dependiendo de compiladores, comportamiento en tiempo de ejecución, hardware y la precisión de cualquier modelo externo.

El sistema puede demostrar que una función de Lean cumple una especificación de Lean. Se necesita trabajo adicional para demostrar que el código nativo optimizado preserva esas semánticas. Langley sugirió el ensamblador verificado como una posible dirección.

Estos límites no eliminan el resultado. Lo sitúan en contexto. La automatización de pruebas de Lean parece útil para componentes acotados cuyas propiedades pueden expresarse con precisión y cuyas dependencias encajan dentro del contexto disponible.

Eso ya es más práctico que la antigua suposición de que la prueba formal siempre exige que un especialista elabore manualmente cada paso. Sigue estando muy lejos de un botón universal de «verificar» para software generado.

Tres señales mostrarán si la automatización de pruebas realmente ha llegado

La siguiente fase depende de la reproducibilidad, el mantenimiento a escala de repositorio y la adopción dentro de los flujos de trabajo ordinarios de ingeniería.

La primera señal es una implementación pública y reproducible que siga el patrón de Langley. Debe incluir código fuente, declaraciones de teoremas, pruebas generadas, dependencias fijadas y una compilación automatizada que rechace huecos sin resolver.

Un artefacto publicado permitiría a equipos independientes medir el tiempo de prueba, la dependencia del modelo y los costes de mantenimiento. También revelaría cuánta intervención humana ocurrió entre la implementación inicial y la prueba aceptada.

Si varios equipos reproducen el flujo de trabajo en analizadores sintácticos o bibliotecas de compresión, la conclusión de Langley cobrará más fuerza. Si los resultados dependen de instrucciones ocultas extensas o de una reestructuración manual, la actual afirmación de productividad se debilita.

La segunda señal es el rendimiento en repositorios cambiantes. Un sistema útil debe reparar pruebas después de refactorizaciones normales, actualizaciones de dependencias y requisitos modificados. Resolver un teorema una vez es menos valioso que mantenerlo resuelto a lo largo de las versiones.

Por lo tanto, los benchmarks a escala de repositorio deberían añadir tareas longitudinales. Un demostrador de IA podría recibir commits consecutivos y reparar las pruebas afectadas mientras preserva la especificación original. Los equipos deberían seguir las reparaciones aceptadas, el tiempo transcurrido, el uso de cómputo y las ediciones humanas.

La mejora en dependencias locales densas abordaría la debilidad identificada por VeriSoftBench. El fracaso continuado limitaría la demostración con IA a módulos pequeños con contexto cuidadosamente seleccionado.

La tercera señal es la integración en agentes de programación convencionales y sistemas de integración continua. La automatización de pruebas se vuelve operativa cuando una solicitud de extracción puede declarar un invariante requerido, generar una prueba y hacer que Lean la verifique automáticamente.

Este proceso también necesita modos de fallo transparentes. Un modelo que no puede encontrar una prueba debe distinguir entre contexto faltante, un teorema difícil, código incompatible y una afirmación falsa. De lo contrario, los equipos reciben otra compilación fallida opaca.

La adopción probablemente comenzará allí donde las organizaciones ya redactan requisitos precisos. La criptografía, las implementaciones de protocolos, los compiladores, los controles financieros y los sistemas de control de acceso encajan en esa descripción. El software empresarial más amplio avanzará más lentamente.

Los trabajadores del conocimiento deberían observar el mismo patrón en sus propias herramientas. La automatización fiable necesita entradas explícitas, reglas de aceptación, evidencia trazable y un comprobador con autoridad para rechazar el resultado.

La mayoría de las tareas de oficina no pueden alcanzar certeza matemática. Aun así, pueden adoptar controles más acotados. Un informe de investigación puede exigir fuentes fechadas. Un análisis de ventas puede requerir que cada afirmación sobre una cuenta se corresponda con un registro de cliente. Una actualización de proyecto puede señalar declaraciones que no estén respaldadas por trabajo reciente.

Ese cambio convierte a la IA de autor sin supervisión en generador de candidatos que opera dentro de un proceso controlado. Las personas conservan la responsabilidad de definir el límite y revisar aquello que las comprobaciones no pueden cubrir.

La automatización de pruebas con Lean ofrece la versión más clara de ese futuro porque su comprobador es exacto. El modelo puede ser inconsistente, verboso o equivocado repetidamente durante la búsqueda. Solo una prueba válida llega al programa.

La pregunta para los próximos meses no es si los LLM pueden generar alguna prueba formal. Ya pueden. La cuestión es si los equipos pueden convertir repetidamente requisitos reales en software mantenido y comprobado por máquina sin recrear la antigua carga de trabajo diez veces mayor.

Elige una suposición costosa en tu flujo de trabajo y anota qué la haría verificablemente cierta. Si la condición puede comprobarse, automatiza esa verificación antes de automatizar más resultados. Esa es la lección práctica detrás del experimento de Langley y el estándar de prueba que la automatización debe cumplir ahora.