⏱️ Lectura: 12 min
Bend 2 necesita 442 líneas de código para demostrar que un jugador nunca puede tocar una bandera en un tablero de 12 por 8: SPARK, un lenguaje de verificación formal con décadas de historia, prueba la misma propiedad con un paquete de menos de 40 líneas y doce checks automáticos verificados por GNATprove. El desarrollador Liam Powell documentó la comparación el 18 de septiembre de 2026 en su blog, después de revisar el demo oficial que Bend 2 publica como ejemplo de vibe-coding en su repositorio de GitHub.
📑 En este artículo
El caso expone algo más específico que un simple exceso de código: Bend 2 se presenta como el lenguaje pensado para programar junto a la inteligencia artificial, pero el campo que resuelve exactamente ese problema, la verificación formal, no aparece mencionado ni una sola vez en su sitio web ni en su código fuente.
TL;DR
- Bend 2 se vende como lenguaje para la era de la IA: humanos escriben ‘leyes’, la IA escribe implementación y pruebas.
- El demo oficial de Bend 2 usa 58 líneas de LAWS.bend y 442 líneas de PROOF.bend para probar dos propiedades simples.
- Las palabras ‘formal verification’ no aparecen en la web ni en el código de Bend, según el desarrollador Liam Powell.
- SPARK, lenguaje de verificación formal basado en Ada, existe desde décadas antes que Bend 2.
- Powell recreó el mismo demo en SPARK con una IA sin guía adicional y GNATprove reportó: ‘Success: all checks proved (12 checks)’.
- SPARK usa contratos, invariantes ghost y postcondiciones en vez de generar cientos de líneas de pruebas desde cero.
- El artículo de Powell se publicó el 18 de septiembre de 2026 en su blog personal.
- El caso ilustra la trampa del vibe-coding: construir una solución completa sin investigar el campo antes de empezar.
Introducción
El vibe-coding describe la práctica de dejar que un modelo de lenguaje escriba la mayor parte del código mientras el humano guía con instrucciones de alto nivel. Bend 2 lleva esa idea a un extremo particular: el desarrollador escribe unas reglas llamadas leyes en un archivo LAWS.bend, y una IA debe producir tanto la implementación del programa como un archivo de prueba, PROOF.bend, que demuestre matemáticamente que esas leyes se cumplen.
El planteamiento suena atractivo: un compilador que rechaza el código si la IA no logra probar que su programa es correcto. Pero Liam Powell, en un análisis publicado en su blog el 18 de septiembre de 2026, sostiene que Bend 2 cayó en una trampa clásica del vibe-coding: construir una solución completa antes de investigar si el problema ya tenía una respuesta mejor.
flowchart TD
A["Humano escribe las leyes en LAWS.bend"] --> B["IA genera la implementación"]
B --> C["IA genera el archivo PROOF.bend"]
C --> D["El compilador de Bend verifica las pruebas"]
D -->|"pruebas válidas"| E["El programa se acepta"]
D -->|"pruebas inválidas"| BQué pasó
El repositorio oficial de Bend incluye un demo llamado app_win_is_bug_2d: un juego simple donde, por diseño, el jugador nunca debería poder tocar la bandera ni ganar. Para declarar esa regla, el desarrollador tuvo que escribir 58 líneas en LAWS.bend.
El archivo de prueba que una IA generó para demostrar esas dos propiedades, PROOF.bend, llegó a 442 líneas. Powell señala además que los subprogramas Game pueden ser redefinidos libremente por el modelo, lo que abre otro problema de diseño que su artículo deja para otro momento.
Contexto e historia
La palabra clave que falta en Bend 2, según Powell, es verificación formal: un campo de la informática dedicado a demostrar matemáticamente que un programa cumple una especificación, en vez de confiar en pruebas por ensayo y error. Ese campo no es nuevo ni experimental. SPARK es un subconjunto de Ada diseñado específicamente para escribir software verificable, con un historial de décadas en sistemas donde un error de software puede costar vidas, como aviónica y trenes.
Powell no afirma que el autor de Bend ignorara la verificación formal a propósito. Su argumento es más incómodo: el vibe-coding permite construir un lenguaje entero, con compilador propio, sin pasar por la etapa de revisar bibliografía que cualquier curso introductorio de ese campo habría puesto en frente.
Detalles técnicos y rendimiento
Para demostrar su punto, Powell recreó el mismo juego en SPARK. Aclara que también vibe-codeó esta versión: le pidió a una IA que reprodujera el demo de Bend, sin darle ninguna guía adicional sobre cómo estructurar las pruebas.
La especificación completa cabe en un paquete corto, porque SPARK ya incorpora en el lenguaje los mecanismos que Bend 2 le pide a la IA reinventar en cada proyecto: contratos de precondición y postcondición, y funciones ghost que existen solo para razonar sobre el programa, no para ejecutarse.
package Game with SPARK_Mode is
subtype Column is Integer range 0 .. 11;
subtype Row is Integer range 0 .. 7;
type State is record
X : Column;
Y : Row;
Won : Boolean;
end record;
function Safe (G : State) return Boolean is
((G.X > 2 or G.Y > 2) and not Wall (G.X, G.Y) and not G.Won)
with Ghost;
function Replay (Keys : String) return State
with Post => not Replay'Result.Won
and Cell (Replay'Result.X, Replay'Result.Y) /= 'F';
end Game;La función Safe es un ghost: no compila a código ejecutable, solo le sirve a GNATprove para razonar sobre el invariante del programa. La postcondición de Replay es literalmente la ley que Bend 2 necesita 58 líneas para declarar: el jugador nunca gana y nunca pisa la celda con la bandera.
El cuerpo del paquete implementa el movimiento del jugador y usa un invariante de bucle para que el probador pueda seguir el razonamiento paso a paso:
function Replay (Keys : String) return State is
G : State := Start;
begin
for Key of Keys loop
pragma Loop_Invariant (Safe (G));
Step (G, Key);
end loop;
return G;
end Replay;Para confirmar que las pruebas están completas, el flujo de trabajo de SPARK no depende de leer 442 líneas de justificación: corre un único comando y lee el resultado.
gnatprove -P game.gpr --mode=prove --report=allLa salida que reporta Powell es directa: Success: all checks proved (12 checks). Doce verificaciones, generadas automáticamente a partir de los contratos, contra las 442 líneas que Bend 2 le pidió escribir a la IA para las mismas dos propiedades.
💭 Clave: la diferencia no es que SPARK sea más corto por casualidad: los contratos, las funciones ghost y los invariantes de bucle son parte del lenguaje desde hace décadas, así que la IA no tiene que reinventar la teoría de la prueba en cada archivo PROOF.bend.
| Opción | Cuándo usarla | Ventaja | Limitación |
|---|---|---|---|
| Bend 2 | Proyectos donde una IA debe generar implementación y prueba desde cero | El humano solo declara las leyes de alto nivel | 442 líneas de prueba generadas para dos propiedades simples, sin aprovechar teoría previa |
| SPARK (Ada) | Sistemas donde ya existen contratos, invariantes y funciones ghost reutilizables | GNATprove resuelve las pruebas automáticamente a partir de contratos declarados una sola vez | Requiere aprender el subconjunto verificable de Ada y su sintaxis de contratos |
Cómo empezar a probarlo
Para reproducir el experimento de Powell hace falta instalar el toolchain de SPARK, que se distribuye a través de Alire, el gestor de paquetes de Ada. Los pasos son los mismos en Windows, macOS y Linux, salvo el instalador inicial:
- Windows: descargar el instalador de Alire desde su release oficial y ejecutar
alr toolchain --selectdesde PowerShell para elegir GNAT y gnatprove. - macOS: instalar Alire con
brew install alirey luego correralr toolchain --select. - Linux: descargar el binario de Alire para la arquitectura correspondiente, agregarlo al
PATHy ejecutar el mismo comando de selección de toolchain.
Con el toolchain instalado, un proyecto nuevo se inicializa y se prueba así:
alr init --bin game_win_is_bug
cd game_win_is_bug
alr with gnatprove
alr exec -- gnatprove -P game_win_is_bug.gpr --mode=provePara revisar el caso original de Bend 2, el repositorio está público y el demo se puede clonar directamente:
git clone https://github.com/bendlang/bend
cd bend/demos/app_win_is_bug_2d
cat LAWS.bend PROOF.bend | wc -lEse último comando es, literalmente, la manera más rápida de confirmar el dato central del artículo de Powell: contar las líneas que hoy exige cada enfoque para la misma propiedad.
⚠️ Ojo: SPARK no resuelve automáticamente cualquier propiedad: hay que escribir contratos correctos a mano, y demostrar propiedades complejas puede requerir lemas auxiliares. La ventaja frente a Bend 2 no es que no haga falta pensar, es que no hace falta reinventar la teoría de pruebas en cada proyecto.
Impacto y análisis: la trampa del vibe-coding
El argumento de Powell no ataca a Bend 2 por ser lento o por generar demasiado código: ataca la premisa de diseño. Si el objetivo es que una IA escriba pruebas junto con el código, la pregunta relevante no es cómo hacer que el modelo genere más líneas de PROOF.bend, sino por qué el lenguaje no le da a la IA las mismas herramientas que ya existen en un campo con décadas de investigación.
Esto conecta con un problema más amplio del vibe-coding: es posible producir un artefacto grande y funcional (un lenguaje, un compilador, una demo que corre) sin que en el camino aparezca la necesidad de buscar bibliografía previa. Un desarrollador que investigara verificación formal antes de diseñar Bend 2 probablemente habría encontrado SPARK, Dafny o Coq en la primera búsqueda.
La comparación también tiene un costo práctico medible: cada línea de PROOF.bend que una IA genera consume tokens, y con modelos que cobran por token de salida, 442 líneas de prueba redundante no son solo un problema estético.
Qué sigue
Powell no propone que el equipo de Bend abandone el proyecto, sino que reconozca el campo en el que está compitiendo y compare su enfoque contra las herramientas existentes de verificación formal. Queda abierto si Bend 2 incorporará ideas de SPARK, Dafny o Lean, o si mantendrá su apuesta por generar pruebas desde cero con cada modelo.
El caso también deja una pregunta para cualquier equipo que hoy diseñe un lenguaje o una herramienta apoyada en IA: si el resultado se parece sospechosamente a un problema ya resuelto, vale la pena frenar y buscar antes de seguir construyendo.
📖 Resumen en Telegram: Ver resumen
Probalo vos: cloná el repositorio de Bend en github.com/bendlang/bend y compará el conteo de líneas de LAWS.bend y PROOF.bend contra un contrato equivalente en SPARK antes de decidir qué enfoque usar en tu próximo proyecto verificado.
Preguntas frecuentes
¿Qué es Bend 2?
Es un lenguaje presentado como pensado para la era de la IA: el humano escribe reglas llamadas leyes en un archivo LAWS.bend, y una IA debe generar tanto la implementación como una prueba, en PROOF.bend, de que el programa cumple esas leyes.
¿Qué es la verificación formal?
Es el campo de la informática que demuestra matemáticamente que un programa cumple una especificación, en lugar de confiar solo en pruebas de ejecución. SPARK, Dafny y Coq son herramientas de ese campo.
¿Qué es SPARK?
Un subconjunto de Ada diseñado para escribir código verificable con contratos, precondiciones, postcondiciones y funciones ghost, usado en sistemas críticos desde hace décadas.
¿Por qué SPARK necesita menos código que Bend 2 para la misma prueba?
Porque los mecanismos de prueba (contratos, invariantes, funciones ghost) ya forman parte del lenguaje. Bend 2 le pide a la IA reconstruir ese razonamiento desde cero en cada proyecto.
¿Quién hizo esta comparación?
El desarrollador Liam Powell, en un artículo publicado el 18 de septiembre de 2026 en su blog personal.
¿Bend 2 es inútil entonces?
Powell no lo plantea así. Su punto es que el diseño de Bend 2 ignora un campo existente, no que la idea de combinar IA con pruebas verificables carezca de valor.
Referencias
- Bend 2 and the Vibe-Coding Trap: el artículo original de Liam Powell con la comparación completa contra SPARK.
- github.com/bendlang/bend: repositorio oficial de Bend, incluye el demo analizado.
- LAWS.bend: las 58 líneas que declaran las propiedades del demo.
- PROOF.bend: las 442 líneas de prueba generadas para el mismo demo.
- SPARK (programming language), Wikipedia: contexto e historia del lenguaje de verificación formal usado en la comparación.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de Markus Spiske en Unsplash
0 Comentarios