La automatización de pruebas en Lean acaba de superar una prueba de software real, pero la prueba no está lista para producción

La automatización de pruebas en Lean cruzó un umbral importante el 26 de julio, aunque todavía está muy lejos de una versión de software para producción. El ingeniero de seguridad Adam Langley creó un descompresor de Zstandard funcional en Lean y luego utilizó varios modelos de lenguaje de gran tamaño para generar pruebas verificadas por máquina en torno a su lógica más compleja.

El experimento no produjo un descompresor más rápido, una biblioteca publicada ni evidencia de que la IA pueda verificar cualquier aplicación grande. Langley afirma que su versión funciona unas diez veces más lento que el comando estándar zstd. También describe la implementación como un proyecto de aprendizaje y decidió no publicar su código.

El cambio es más acotado, pero más trascendental. Un sistema de IA produjo pruebas para software no trivial mientras Lean comprobaba de forma independiente si esas pruebas eran válidas. Esto lleva la verificación asistida por IA más allá de explicaciones fluidas y código plausible, hacia un flujo de trabajo con una prueba de aceptación excepcionalmente estricta.

La competencia principal ya no es código generado por IA frente a código escrito por humanos. Es generación probabilística frente a verificación determinista. El modelo puede conjeturar, revisar y fallar repetidamente, mientras un pequeño verificador de confianza decide qué entra en el programa terminado.

Para los desarrolladores, este patrón ofrece una posible respuesta a los agentes de programación poco fiables. Para los trabajadores del conocimiento, plantea un modelo más amplio de automatización: dejar que la IA produzca el primer intento desordenado, pero hacer que la aceptación dependa de condiciones explícitas y verificables por máquina.

El experimento con Zstandard hizo concreta la automatización de pruebas

La prueba de Langley importa porque aplicó pruebas generadas por IA a software de sistemas convencional, no a otro benchmark aislado de matemáticas.

Lean es a la vez un lenguaje de programación y un demostrador interactivo de teoremas. Sus tipos dependientes permiten que los tipos de un programa incluyan hechos sobre valores, como la longitud exacta de un array o una relación entre varias salidas.

Esta capacidad cambia lo que puede prometer la firma de una función. Una función normal de lectura de archivos podría devolver un array de bytes. Una función de Lean puede devolver un array junto con una prueba de que su longitud coincide con el número solicitado de bytes.

La referencia oficial de Lean explica por qué esta arquitectura tiene un valor inusual para el trabajo generado por IA. Las tácticas de Lean pueden ser complejas y automatizadas, pero cada término de prueba que producen pasa por un kernel comparativamente pequeño.

Una táctica defectuosa puede desperdiciar tiempo o generar un candidato no válido. No puede convertir una prueba inválida en válida, a menos que la base de confianza también contenga un defecto. El verificador, y no el generador, sigue siendo la autoridad final.

Langley eligió Zstandard porque suponía un reto de implementación significativo. Zstandard, normalmente llamado zstd, es un formato de compresión sin pérdida basado en coincidencias de estilo LZ77 y dos sistemas de codificación entrópica.

Su especificación de formato asigna la codificación Huffman a los datos literales y Finite State Entropy, o FSE, a otros símbolos y cabeceras Huffman. FSE utiliza un estado que se transporta entre símbolos, lo que exige decodificar sus flujos de bits en orden inverso al de escritura.

Ese mecanismo es mucho más exigente que demostrar que dos expresiones aritméticas breves son iguales. Un descompresor debe analizar estructuras binarias compactas, mantener el estado, rechazar entradas no válidas y reconstruir correctamente los bytes originales.

El experimento de Lean de Langley prestó especial atención a la construcción de tablas FSE. La tabla determina cómo los estados comprimidos se asignan de nuevo a símbolos y cuántos bits consume el decodificador.

Según se informa, varios LLM generaron una prueba de una propiedad importante de ese código de construcción de tablas en unos 20 minutos. Langley comprobó que las pruebas resultantes superaban el verificador de tipos de Lean y no contenían declaraciones sorry, el mecanismo de Lean para admitir temporalmente una afirmación no demostrada.

Los modelos sí tuvieron que modificar algunas decisiones de implementación. Langley había utilizado Id.run para expresar partes del algoritmo con un estilo más imperativo, lo que dificultaba el uso de la infraestructura de pruebas.

Ese detalle impide una interpretación simplista del resultado. La IA no se limitó a examinar código fijo y adjuntar un certificado. Ayudó a reformular la implementación en una forma que permitía construir la prueba.

Aun así, el resultado creó un ciclo completo: escribir software significativo, establecer un invariante sólido, generar una prueba y pedir a un kernel independiente que la acepte o la rechace. Ese ciclo es el verdadero acontecimiento.

La automatización de pruebas en Lean aborda el problema del coste de la verificación

La verificación formal ya ha aportado garantías excepcionales, pero el trabajo de demostración la ha mantenido fuera de la mayoría de los proyectos cotidianos de software.

El ejemplo histórico más claro es seL4, un pequeño kernel de sistema operativo respaldado por pruebas verificadas por máquina. Sus propiedades verificadas abarcan mucho más que superar pruebas con una colección seleccionada de entradas.

La verificación original requirió aproximadamente 20 años-persona durante cuatro años y produjo más de 200.000 líneas de script de prueba en Isabelle. Una retrospectiva descrita en la investigación sobre seL4 muestra por qué estas cifras no pueden descartarse como un exceso académico.

Los equipos de verificación deben definir las propiedades correctas, conectar distintas capas de abstracción, construir pruebas y mantenerlas alineadas con código cambiante. Cada tarea exige conocimientos especializados e ingeniería cuidadosa.

La recompensa puede ser considerable. El proyecto seL4 informa de que no ha detectado defectos de corrección funcional en el código verificado desde que completó su prueba principal en 2009. Sin embargo, la mayoría de los equipos de software no pueden invertir años de trabajo especializado antes de lanzar un único componente.

La automatización tradicional de pruebas reduce parte de esta carga. Las tácticas pueden resolver patrones conocidos, mientras que los solucionadores de satisfacibilidad módulo teorías, conocidos como solucionadores SMT, resuelven condiciones lógicas en dominios compatibles.

Estos sistemas también influyen en cómo los programadores escriben código verificado. Los usuarios experimentados aprenden qué formulaciones puede manejar un solucionador y qué estructuras aparentemente inocuas hacen que la búsqueda se expanda sin control.

Langley sostiene que los LLM cambian esta ecuación económica porque son generadores flexibles de pruebas. Pueden leer definiciones circundantes, inspeccionar mensajes de error, reescribir código local, proponer lemas intermedios y probar otra vía tras un rechazo.

La irrelevancia de las pruebas refuerza el argumento. En Lean, las proposiciones viven en un universo irrelevante para las pruebas, lo que significa que el sistema generalmente se preocupa de que exista una prueba válida, no de cuál prueba válida se proporcionó.

Un ingeniero humano de pruebas suele valorar la elegancia porque una prueba clara puede sobrevivir más fácilmente a cambios posteriores. Si un LLM puede regenerar rápidamente una prueba verificada, parte de ese cálculo de mantenimiento cambia.

Eso no elimina la ingeniería de pruebas. Alguien debe seguir enunciando el teorema correcto, definiendo el límite de confianza y decidiendo si la regeneración tras cada cambio sigue siendo asequible.

Sin embargo, debilita una objeción importante. El código generado feo es peligroso cuando los desarrolladores no pueden evaluar con confianza su comportamiento. Una prueba generada poco elegante resulta menos preocupante cuando un kernel de confianza rechaza cada versión inválida.

El flujo de trabajo emergente se parece más a la compilación que al razonamiento colaborativo. Los desarrolladores especifican la propiedad, un agente busca un artefacto aceptable y el verificador determina si la compilación tiene éxito.

Esta diferencia importa a los responsables que deciden dónde encaja la IA. Un asistente de programación que afirma que una función es segura ofrece una opinión. Un asistente capaz de producir pruebas que devuelve un artefacto verificado por kernel aporta evidencia bajo supuestos declarados.

La distinción también revela el nuevo cuello de botella. Si generar pruebas se vuelve barato, redactar la especificación correcta se convierte en la habilidad escasa.

Los equipos necesitarán personas capaces de traducir requisitos en invariantes precisos. «Este analizador debería ser seguro» no es verificable. «Todo análisis correcto se mantiene dentro del búfer de entrada suministrado» se acerca más a una propiedad que un sistema formal puede evaluar.

Para los trabajadores del conocimiento, la tarea equivalente consiste en definir las condiciones de aceptación antes de que comience la automatización. La IA puede redactar una previsión, conciliar una política o fusionar notas de reuniones, pero una automatización fiable requiere una descripción clara de lo que debe seguir siendo cierto.

El nuevo oponente es la generación sin verificación

La lección más importante no es que los LLM se hayan vuelto fiables, sino que la generación poco fiable puede ser útil dentro de un ciclo de comprobación fiable.

La mayoría de los productos de IA generativa piden a los usuarios que evalúen los resultados directamente. Un modelo redacta un correo electrónico, resume una reunión, edita una hoja de cálculo o propone código. Después, la persona busca errores sutiles con tiempo y atención limitados.

Este patrón hace que la automatización resulte atractiva para trabajos de bajo riesgo, pero difícil de confiar para seguridad, finanzas, cumplimiento normativo, infraestructura y cambios operativos irreversibles. La confianza del modelo ofrece poca protección porque un lenguaje fluido no demuestra corrección.

La automatización de pruebas en Lean separa dos tareas. El LLM explora un amplio espacio de posibles pruebas, mientras el asistente de pruebas realiza una tarea de verificación acotada con reglas exactas.

El generador puede alucinar el nombre de un teorema, aplicar una transformación no válida o malinterpretar una definición. Esos fallos se convierten en candidatos rechazados en lugar de conclusiones aceptadas, siempre que la propiedad declarada y el límite de confianza sean sólidos.

Investigaciones recientes apuntan a sistemas construidos en torno a esta separación. OpenProver, publicado en julio de 2026, combina planificación, agentes trabajadores y verificación en Lean en un sistema de demostración de teoremas de código abierto.

Su arquitectura asigna distintas responsabilidades a agentes especializados y mantiene la comprobación formal automática. También admite orientación humana, reconociendo que la búsqueda de pruebas sigue beneficiándose de la dirección de expertos.

Este es un modelo de producto distinto al de un chatbot con una ventana de código. El resultado valioso no es la explicación del modelo sobre por qué una prueba debería funcionar. Es el objeto de prueba que supera una comprobación independiente.

Un patrón similar puede mejorar el trabajo cotidiano del conocimiento incluso cuando no es necesaria una demostración formal completa. Pensemos en un responsable de producto que prepara una actualización semanal a partir de entrevistas, tickets, métricas y decisiones.

Un LLM puede redactar rápidamente la actualización. Sin embargo, cada afirmación factual debe seguir siendo rastreable hasta una fuente, cada métrica debe conservar su fecha y definición, y las contradicciones no resueltas deben permanecer visibles.

Un sistema personal de conocimiento puede ayudar a preservar esas conexiones. Por ejemplo, knowledge blending puede reunir material local relacionado en un único contexto de trabajo, en lugar de obligar al usuario a reconstruirlo a partir de archivos dispersos.

No es lo mismo que una prueba matemática. El verificador puede consistir en citas de fuentes, validación de esquemas, controles de acceso, pruebas aritméticas o un paso de aprobación humana.

El principio arquitectónico sigue siendo similar. La libertad generativa pertenece antes de la puerta de control. Las reglas deterministas, la evidencia documentada o la revisión responsable deciden qué la atraviesa.

Esto también cambia cómo los equipos deberían evaluar la productividad de la IA. El tiempo ahorrado durante la redacción es solo una métrica. El tiempo de revisión, la frecuencia de correcciones, la tasa de defectos que llegan a producción y la calidad de la evidencia de respaldo importan igual o más.

Un agente que redacta diez veces más rápido pero duplica el esfuerzo de revisión no ha automatizado la tarea. Ha trasladado el trabajo a una etapa menos visible.

Por el contrario, un agente que produce un primer resultado más lento con procedencia completa y validación automática puede ofrecer una productividad más útil. La evidencia reduce la incertidumbre para cada lector posterior.

Lean hace que este principio sea inusualmente visible porque la condición de aceptación es binaria. La prueba se verifica o no se verifica. La mayoría de la automatización de oficina carece de un límite tan claro, pero los equipos pueden crear controles más pequeños y específicos para cada tarea.

Un resumen financiero puede exigir que cada total se concilie con las celdas de origen. Una comparación de contratos puede exigir que cada diferencia señalada enlace con cláusulas exactas. Un informe de investigación puede impedir que las citas sin respaldo lleguen al documento final.

Esos controles no vuelven honesto ni determinista al modelo subyacente. Hacen que sus debilidades sean más fáciles de contener.

Lo que la prueba de Zstandard no demuestra

El experimento valida un mecanismo prometedor, pero no establece que la IA pueda verificar sistemas de producción grandes de forma barata o completa.

La limitación más evidente es el alcance. Langley describe el descompresor como un juguete, afirma que el código no está publicado y no lo presenta como un modelo para otros programadores de Lean.

Eso impide que revisores independientes reproduzcan el resultado, examinen los enunciados precisos de los teoremas o identifiquen componentes no verificados. Sabemos que pruebas seleccionadas pasaron la comprobación de tipos, según el informe del autor.

No sabemos si esos enunciados cubren todas las propiedades que requiere un descompresor de producción. Una prueba perfectamente válida de una especificación incompleta puede coexistir con defectos graves fuera de esa especificación.

Esto suele denominarse el problema de la especificación. El verificador puede establecer que el código satisface un enunciado formal, pero no puede decidir si los humanos eligieron el enunciado correcto.

Un descompresor podría demostrar que las entradas válidas completan correctamente un ciclo de ida y vuelta, dejando fuera del teorema el agotamiento de memoria, el comportamiento ante denegaciones de servicio, los límites de recursos o el análisis de archivos. Cada límite omitido crea margen para el fallo.

La base de computación confiable también importa. El pequeño kernel de Lean reduce drásticamente el componente que debe ser confiable, pero los programas reales interactúan con compiladores, sistemas operativos, funciones externas, hardware y bibliotecas externas.

Langley exploró la llamada a ensamblador optimizado mediante el mecanismo extern de Lean. Los pequeños ejemplos de equivalencia funcionaron, pero los intentos de escalar el enfoque supuestamente se toparon con requisitos de memoria severos o no lograron avanzar.

Ese resultado pone de relieve una disyuntiva central. El código verificado de alto nivel puede ofrecer sólidas garantías lógicas, mientras que el rendimiento de producción suele depender de implementaciones y herramientas de bajo nivel que quedan fuera de la prueba inmediata.

La propia implementación de Zstandard ilustra esa brecha. Langley informa que su decodificador en Lean funciona aproximadamente diez veces más lento que la implementación estándar de línea de comandos.

El rendimiento no es una preocupación menor para el software de compresión. La descompresión suele situarse en una ruta sensible a la latencia que implica almacenamiento, distribución de paquetes, bases de datos o transferencia por red.

El mantenimiento de las pruebas también sigue siendo incierto. Langley sugiere que una regeneración rápida puede reducir la necesidad de diseñar cuidadosamente las pruebas para cambios futuros.

Eso resulta plausible para un proyecto acotado. Una base de código grande puede crear miles de obligaciones interdependientes, donde un pequeño cambio de tipo se propaga entre módulos y supera el contexto o el presupuesto de búsqueda de un agente.

Los benchmarks de investigación no deberían resolver esta cuestión por sí solos. Las colecciones de teoremas matemáticos suelen proporcionar objetivos explícitos y entornos controlados. El código de producción incluye especificaciones parciales, interfaces heredadas, dependencias cambiantes y supuestos no documentados.

También existe un riesgo humano. La generación fácil de pruebas puede crear presión para tratar cualquier marca verde como una garantía integral.

Un teorema comprobado afirma exactamente lo que afirma su enunciado formal. No ofrece ninguna garantía sobre seguridad, privacidad, fiabilidad o corrección empresarial, a menos que esas propiedades aparezcan en el modelo.

Por lo tanto, los equipos deben revisar las especificaciones con la misma seriedad que hoy reservan para la revisión de código. De lo contrario, la IA acelerará la producción de respuestas convincentes a preguntas incompletas.

La automatización de pruebas con IA desplaza el cuello de botella hacia las especificaciones

Si los modelos se vuelven generadores competentes de pruebas, el trabajo del conocimiento valioso se desplaza de construir artefactos a definir afirmaciones y límites.

Los equipos de software ya han experimentado una versión de esta transición. Los agentes de programación reducen el coste de producir funciones, pruebas, migraciones y documentación.

A medida que el resultado se abarata, decidir qué debe construirse cobra mayor importancia. Los requisitos, las interfaces, las restricciones, los modelos de amenazas y las pruebas de aceptación determinan si la generación rápida crea valor o simplemente genera más material que inspeccionar.

Lean extiende ese cambio a las afirmaciones de corrección. Un programador puede codificar un invariante en un tipo, pedir a un LLM que construya la prueba y dejar que el kernel verifique el resultado.

La contribución humana de mayor impacto suele estar antes. Alguien debe reconocer qué invariante importa, expresarlo sin lagunas y vincularlo con el entorno operativo real.

Los trabajadores del conocimiento afrontan la misma estructura con herramientas menos formales. Un analista debe decidir qué evidencia es válida para una afirmación sobre el mercado. Un reclutador debe definir qué criterios para candidatos son legales y pertinentes.

Un responsable de soporte debe especificar cuándo puede enviarse una respuesta automatizada y cuándo un caso requiere escalamiento. Un investigador debe distinguir entre una fuente directa, un resumen secundario y una inferencia sin respaldo.

Son tareas de especificación, incluso cuando nadie las escribe en Lean. Transforman expectativas vagas en condiciones observables.

Las organizaciones pueden prepararse registrando reglas de decisión junto a los documentos que rigen. Una nota que diga «usar el recuento más reciente de clientes» es ambigua. Una regla que nombre el panel de control autorizado, la hora de actualización, la región y el período de reporte es comprobable.

La procedencia se vuelve igual de importante. Un modelo no puede conciliar de forma fiable el conocimiento de un equipo si el material de origen ha perdido su fecha, propietario, versión o relación con decisiones anteriores.

Por eso el paso de las interfaces de chat hacia los sistemas de agentes exige una mejor arquitectura de la información. Los agentes necesitan contexto estructurado, permisos, reglas de validación y registros duraderos de lo que modificaron.

La revisión humana también debería orientarse hacia las excepciones. Si cada afirmación generada por IA requiere una inspección línea por línea, el sistema sigue siendo un asistente y no una capa de automatización.

Los controles útiles pueden aprobar automáticamente casos rutinarios que cumplen condiciones explícitas. Los humanos se concentran entonces en evidencia faltante, fuentes contradictorias, valores inusuales, acciones sensibles para la seguridad y cambios fuera de patrones conocidos.

Los asistentes de pruebas formales proporcionan la versión más sólida de ese flujo de trabajo, pero no son adecuados para todas las tareas. Muchas decisiones dependen del juicio, de definiciones discutidas o de información incompleta.

El objetivo no es formalizar cada correo electrónico. Es identificar las afirmaciones cuyo fallo tiene un coste real y construir controles proporcionales a su alrededor.

En software, eso podría significar demostrar la seguridad de los límites en un analizador mientras se prueba la interfaz de usuario de manera convencional. Para un equipo de operaciones, podría significar conciliar automáticamente los totales de pagos mientras se exige aprobación humana para las transferencias.

Para los investigadores, podría significar validar cada cita y pasaje citado, dejando la interpretación abierta al debate. La verificación debe proteger el límite que más importa.

El experimento de Langley hace que esta estrategia de diseño sea más fácil de imaginar. El LLM no necesitaba convertirse en un matemático impecable. Necesitaba generar un artefacto que un sistema más estricto pudiera evaluar.

Ese es un camino más realista para la IA empresarial que esperar a que los modelos dejen de cometer errores.

Tres señales mostrarán si el cambio es real

La próxima etapa depende de la reproducibilidad, la escala y un coste de mantenimiento medible, más que de otra prueba aislada impresionante.

La primera señal es un corpus publicado y reproducible de software verificado común. El descompresor de Langley no puede desempeñar ese papel porque el código fuente y las pruebas no están disponibles.

Proyectos como lean-zip ofrecen una referencia más examinable. Leonardo de Moura, coautor de Lean, lo destacó recientemente como un proyecto de compresión verificado que implementa tanto compresión como descompresión.

Los proyectos futuros necesitan enunciados precisos de los teoremas, supuestos documentados, mediciones de rendimiento y pruebas frente a implementaciones consolidadas. Equipos independientes deberían poder reconstruir cada prueba e identificar qué módulos permanecen fuera del límite verificado.

Si varios proyectos repiten el patrón en analizadores, código de redes, formatos de almacenamiento y soporte criptográfico, el argumento a favor de la automatización de pruebas con Lean se fortalece. Si los resultados siguen concentrados en pequeñas demostraciones, la afirmación más amplia se debilita.

La segunda señal es cómo se comporta la generación de pruebas tras cambios reales en el código. La construcción inicial de pruebas atrae atención, pero el mantenimiento determina si la economía funciona.

Los equipos deberían medir el tiempo de regeneración tras refactorizaciones, actualizaciones de dependencias, cambios de especificación y optimización del rendimiento. También deberían registrar con qué frecuencia un experto humano debe reestructurar código o inventar lemas intermedios.

El éxito rápido con un teorema estable ofrece evidencia limitada sobre una aplicación viva. Un sistema útil debe sobrevivir meses de desarrollo ordinario sin convertir cada pull request en un proyecto impredecible de búsqueda de pruebas.

Si los costes de las pruebas se mantienen acotados y los fallos producen diagnósticos accionables, la verificación generada por IA puede incorporarse a la integración continua. Si cambios pequeños desencadenan horas de búsquedas opacas, la adopción seguirá siendo limitada.

La tercera señal es la integración en agentes de programación convencionales. Actualmente, la generación de pruebas se encuentra cerca de los flujos de trabajo de investigación y los entornos especializados de Lean.

El punto de inflexión práctico llegará cuando un agente pueda proponer un invariante, explicar su alcance, generar la prueba, ejecutar el verificador y mostrar exactamente qué supuestos siguen sin verificarse.

Esa interfaz debe resistir la falsa confianza. Debe distinguir el comportamiento probado mediante tests del comportamiento demostrado formalmente, y los módulos verificados de los envoltorios no verificados.

También debe hacer muy visibles los cambios en los teoremas. Un agente nunca debe «arreglar» una prueba fallida debilitando silenciosamente la propiedad que los usuarios esperaban que preservara.

Para los trabajadores del conocimiento, estas señales se traducen en una prueba de compra sencilla. Pregunte si un producto de IA genera respuestas o produce respuestas con condiciones de aceptación exigibles.

Busque procedencia a nivel de fuente, comprobaciones de permisos, validación estructurada, transformaciones reproducibles y rutas claras de escalamiento. Una respuesta pulida sin esos controles sigue siendo un borrador, por muy segura que parezca.

La automatización de pruebas con Lean no demuestra que ahora pueda confiarse en la IA por sí sola. Es evidencia de que la confianza puede diseñarse alrededor de la IA cuando las afirmaciones son explícitas y la verificación sigue siendo independiente.

La pregunta para el próximo proyecto es práctica: ¿qué decisión recurrente genera suficiente riesgo como para justificar un verdadero control de aceptación? Empiece por ahí, defina qué debe seguir siendo cierto y haga que la automatización se gane cada marca verde.