AlphaProof Code vs AesCode 32B: Uno demuestra que el código es correcto, el otro lo dibuja

Si pones AlphaProof Code y AesCode 32B en la misma frase, lo único que comparten es la palabra «code». AlphaProof Code es un marco agéntico de Google DeepMind anunciado el 10 de noviembre de 2026 que produjo aproximadamente 6,5 millones de líneas de Lean verificadas por máquina que demuestran que el binario compilado de libsignal se comporta según lo especificado. AesCode 32B es un checkpoint de visión-lenguaje de 33.000 millones de parámetros que Microsoft subió a Hugging Face a principios de octubre de 2026 sin ningún anuncio, y escribe un prompt en un único documento HTML autocontenido —una diapositiva, un póster, un panel— que después mira una persona. Ninguno de los dos es un servicio al que puedas llamar. Uno de ellos ni siquiera es un modelo. Si has llegado hasta aquí buscando una decisión de reemplazo directo, la respuesta honesta es que no existe tal decisión, y el resto de este artículo explica por qué la comparación sigue mereciendo la pena.

El error de categoría, enunciado correctamente

AesCode 32B es un generador. Le das una descripción; devuelve un artefacto cuya calidad se juzga estéticamente y por si las cifras de la página coinciden con las que pediste. El propio planteamiento de la ficha del modelo es que los generadores de imágenes componen una página atractiva y reproducen mal las cifras que aparecen en ella, mientras que los modelos de código aciertan las cifras y no pueden ver cómo queda la página; AesCode combina tu prompt con una imagen generada a partir de ese mismo prompt y usa la imagen como referencia estética mientras sigue el texto para el contenido.

AlphaProof Code es un verificador. Se le proporciona una especificación —una declaración de lo que debe ser verdad— y devuelve una prueba, verificada por el kernel de Lean, de que un binario compilado concreto cumple esa especificación. No hay ningún juicio estético en ningún punto del bucle. Una prueba o se acepta o no se acepta, y el criterio de aceptación consiste en unos pocos miles de líneas de código del kernel y no en el gusto de un revisor.

Esa distinción decide para qué sirve cada uno. AesCode 32B responde a «hazme algo». AlphaProof Code responde a «¿es esto lo que afirma ser?». Usarías el primero un martes por la tarde para una presentación y el segundo, si fueras Signal, durante cuatro semanas con cinco investigadores y equipos de 40 a 80 agentes.

Lo que cada uno realmente incluye

Parámetros — AesCode 32B: aproximadamente 33,4 mil millones en BF16 distribuidos en catorce fragmentos de safetensors que suman 66,714,912,704 bytes. AlphaProof Code: ninguno. Es un framework junto con un repositorio de artefactos, y no hay pesos que descargar.

• Base — AesCode 32B: un ajuste fino de Qwen3-VL-32B-Instruct, cuya arquitectura se declara como Qwen3VLForConditionalGeneration, por lo que se carga con transformers 4.57 y versiones posteriores. AlphaProof Code: independiente del modelo por construcción; el artículo de DeepMind nombra G​emini 4 Carbon para los agentes de demostración y afirma que Claude Opus 5.5 se utilizó entre los modelos que redactaron y revisaron las especificaciones.

• Licencia — AesCode 32B: Apache 2.0, ya disponible en Hugging Face. AlphaProof Code: el desarrollo en Lean, la semántica de AArch64 y el binding de libsignal están publicados en github.com/google-deepmind/code-verification, y la página principal no indica ninguna licencia, lo cual deberías aclarar antes de construir nada sobre ello.

• Disponibilidad — AesCode 32B: únicamente autoalojado. Aproximadamente 65 GB de memoria de acelerador para los pesos, un comando de vLLM en cuatro rangos de paralelismo tensorial, sin endpoint alojado y sin mapeo de proveedor de inferencia detrás de la página del repositorio. AlphaProof Code: artefacto de investigación, sin endpoint, sin lista de espera, sin precios.

• Salida — AesCode 32B: un documento HTML, comprobable al abrirlo. AlphaProof Code: un término de prueba Lean, comprobable por Lean.

• Qué significa «correcto» — AesCode 32B: la página se ve bien y las cifras coinciden con el prompt, evaluado por una persona. AlphaProof Code: el teorema se cumple para todas las entradas del modelo, evaluado por un kernel.

El único solapamiento realmente interesante: ambas salidas son artefactos.

Aquí está la comparación que vale la pena. Ambos sistemas producen un archivo que sobrevive al modelo que lo creó. El HTML de AesCode 32B es un documento terminado; puedes distribuirlo, editarlo, compararlo con diff y nadie necesita el modelo de nuevo. La prueba Lean de AlphaProof Code es una derivación terminada; puedes volver a comprobarla en un portátil con unos minutos de cómputo y, si la especificación no ha cambiado, el resultado sigue siendo válido dentro de cinco años.

Esa es una propiedad más rara de lo que parece en un mercado lleno de endpoints de chat. La mayor parte de la salida de los modelos es texto desechable cuyo valor depende de que el modelo siga disponible. Ambos producen algo que puedes conservar. La diferencia está en lo que te aporta eso de «conservar»: con AesCode conservas un mazo, con AlphaProof Code conservas una garantía.

Donde la analogía se rompe es en la auditabilidad. Cualquiera puede abrir el HTML y ver si el título está mal. Casi nadie puede abrir 6,5 millones de líneas de Lean y ver si el teorema dice lo que el comunicado de prensa dice que dice — que es precisamente por lo que el artículo de DeepMind dedica páginas a enumerar su base de confianza, sus 37 primitivas con contrato y las propiedades que no demuestra. El artefacto es verificable; su lectura no es gratuita.

Cuánto valen los números de cada lado

El resultado destacado de AesCode 32B es una puntuación global de 85,89 frente a 81,28 de GPT-5.5: la medición que Microsoft hace de un modelo de la competencia, con una rúbrica escrita por Microsoft y un banco de pruebas creado por Microsoft. Boundary se sitúa en 97,27 con un desbordamiento severo en el 4,3 % de las muestras, y estilo en 55,99, una fila en la que ningún modelo de la tabla supera 60. Según los propios contadores del repositorio, nadie fuera de Microsoft había publicado una cifra para el modelo. Todas las cifras anteriores las reporta el proveedor y no han sido reproducidas.

AlphaProof Code no tiene ninguna tabla de benchmarks, y eso no es una laguna en el informe: es un tipo distinto de afirmación. El resultado es que un binario específico satisface diez teoremas simbólicos y una vía computacional con una cota concreta. Se puede discrepar de la especificación, pero no se puede discutir el veredicto del kernel sobre la prueba. Las salvedades comparables son estructurales más que estadísticas: sin garantía poscuántica para la sanación de SPQR, sin privacidad de la carga útil, sin autenticación del respondedor en los primeros mensajes no promovidos, una sesión por promoción, longitudes de mensaje fijas y sin estado multidispositivo. Y una cota de falsificación de MAC que se vuelve vacua alrededor de 25.000 mensajes en una sola sesión.

Hay una cifra que sí resulta útil como punto de comparación. La verificación de AlphaProof Code llevó cuatro semanas, mientras que trabajos comparables han requerido históricamente años de equipos de expertos, frente a las líneas base citadas en el propio artículo de aproximadamente 20 personas-año para seL4 y alrededor de 6 para CompCert. Esa proporción es la afirmación a la que hay que aferrarse, y es una afirmación sobre el flujo de trabajo, no sobre la calidad del modelo.

¿Cuál puedes ejecutar realmente esta semana?

AesCode 32B: sí, si tienes el hardware. Descarga los shards, sirve con vLLM en cuatro ranks, mantén los prompts por debajo del límite de 24,576 tokens de la tarjeta y acepta que tu paso de revisión es una persona entrecerrando los ojos ante HTML renderizado. No te dirá si la página es correcta; te dirá si la página se ve correcta.

AlphaProof Code: no. Los artefactos publicados son un desarrollo en Lean, no un pipeline que se invoque. Ni siquiera los modelos que contiene son el entregable: el framework es un constructo de investigación, y el propio planteamiento de DeepMind es que escalarlo «requiere investigación continua». CodeMender es el proyecto hermano para la reparación automatizada; la verificación y la remediación son dos productos diferentes en la hoja de ruta de ese laboratorio.

Si lo que quieres es un modelo que redacte las especificaciones —el paso en el que expertos humanos tradujeron los objetivos de seguridad de Signal a Lean, revisados uno a uno—, eso es trabajo corriente de un modelo, y Claude Opus 5.5 está en el catálogo de OrcaRouter a 4 $ por millón de tokens de entrada y 20 $ por millón de tokens de salida, con el precio de lista del proveedor repercutido sin margen (0 %). Enrutar un bucle de redacción de especificaciones entre dos o tres modelos y comparar su salida en Lean es una llamada de un DSL de enrutamiento, no un proyecto de investigación. Lo que nada de eso te da es una prueba; el paso de la prueba es de donde salieron los seis millones de líneas.

Por qué la combinación vale la pena publicarla de todos modos

Porque "modelo de código" se ha convertido en una categoría sin límite inferior. Un modelo que escribe diapositivas y un framework que demuestra un protocolo de mensajería acaban ambos clasificados dentro de ella, y los compradores que los comparan en una tabla de clasificación no aprenden nada. La pregunta útil no es cuál es mejor — es qué evidencia obtienes sobre la salida. AesCode 32B te da una página renderizada y una rúbrica del proveedor. AlphaProof Code te da una derivación verificada por kernel y una lista inusualmente explícita de lo que asume. Una de esas opciones escala a código en el que preferirías no equivocarte, y no es la que tiene el mayor número de parámetros.

Si estás evaluando AesCode 32B para un pipeline de diseño, lo que hay que probar no es su puntuación general sino su comportamiento en los límites: la tasa de desbordamiento grave del 4,3 % es donde una presentación se vuelve incorrecta en silencio en lugar de fea. Si estás evaluando AlphaProof Code, lo que hay que leer es el catálogo de desviaciones de especificación del repositorio de artefactos: más de 200 entradas computacionales y unas 35 simbólicas, quince de las cuales son vacíos o errores en el análisis de Double Ratchet. Ese catálogo es el documento más honesto del lanzamiento, porque es una lista de todo lo que las demostraciones no cerraron.