Boris Cherny, el hombre detrás de Claude Code, hizo un anuncio discreto la semana pasada. Dijo que Opus había usado TLA+ para encontrar condiciones de carrera en el código. Desde entonces, todo el mundo en internet ha estado hablando sobre la verificación formal. Esa es la historia, y es una buena — pero tiene una advertencia. TLA+ es excelente para diseñar sistemas concurrentes complejos y asegurarse de que estén libres de errores. No es una varita mágica para todo.
Cómo TLA+ Descompone un Sistema
TLA+ funciona dividiendo un sistema en un conjunto de comportamientos. Cada comportamiento es una secuencia de estados, como «la luz uno está en verde, luego en amarillo, luego en rojo». Dentro de cada estado, puede escribir expresiones booleanas simples: «La luz cuatro está en verde» o «Todas las luces están en rojo». Luego agrega tres operadores temporales:
[]P(«always P») is true if P holds in the current state and every future state.P'(«P prime») is true if P holds in the next state.<>P(«eventually P») is true if P holds in the current state or at least one future state.
These operators let you build invariants, which are properties that hold across every state of every behavior. For example, []P means P is true in every initial state, and then by definition it stays true in every future state. That’s a safety property — something bad never happens. Liveness is the opposite: «something good always happens.» It’s built around <>P, but <>P alone is usually too weak. Combinations like []<>P and <>[]P make the logic richer.
There are also other operators like ENABLED and <<A>>_v. Most of what TLA+ checks falls into invariants, action properties, and liveness. Refinement combines safety and liveness and is a whole topic unto itself.
Las Propiedades que TLA+ No Puede Verificar
El problema es que TLA+ no puede verificar propiedades que ni siquiera puede expresar. Si no sabe cómo representar su propiedad como una fórmula lógica, TLA+ no puede ayudarlo. Eso no es un defecto de TLA+ — es un límite de los métodos formales en general. Si no puede formalizar la noción humana de un pájaro, no puede probar que su aplicación reconoce pájaros.
Algunas propiedades entran en esta categoría. Las propiedades de alcanzabilidad son un ejemplo. No puede probar que un juego es ganable, o que P es alcanzable desde todo estado inicial, o que P es alcanzable desde cualquier estado donde Q es verdadero. Estos se conocen como propiedades de alcanzabilidad.
Otro límite es especificidad. Las propiedades de seguridad de TLA+ funcionan en estados individuales o pasos únicos. No puede definir una propiedad sobre dos o más pasos, como «presionar eliminar y luego deshacer le devuelve el estado original». No puede definir propiedades sobre operaciones de punto flotante o sobre tiempo real — solo tiempo lógico. Las hiperpropiedades son otro punto ciego. No puede definir propiedades sobre un conjunto de comportamientos. Por ejemplo, no puede modelar el hardware de un teléfono donde desea decir algo sobre cómo interactúan múltiples comportamientos.
La Limitación Central
The most interesting limit, according to the author, is implicit quantification. TLA+ properties are implicitly quantified over all behaviors. Checking []P means «for all behaviors, []P is true of that behavior’s initial state.» Any property TLA+ can check must be true for every individual behavior. That means you can’t say «there exists a behavior where P is true.»
Eso deja fuera mucho. No puede probar que P es posible, incluso si no lo alcanza realmente. No puede definir propiedades sobre un conjunto de comportamientos. El autor llama a estas hiperpropiedades.
Por Qué Esto Importa Ahora
El entusiasmo en torno a TLA+ es comprensible. El anuncio de Cherny demostró que una herramienta real puede encontrar errores reales. Pero la máquina de la publicidad tiene la costumbre de tragarse las salvedades. El autor se preocupa de que la gente esté diciendo que los métodos formales resolverán el problema del desarrollo de software autónomo de una vez por todas. Eso es absurdo.
Las debilidades de TLA+ están bien documentadas. Los diseños correctos no se traducen automáticamente en código correcto. Pero este boletín se centra en una limitación diferente: para verificar una propiedad, debe tener una propiedad que verificar. Si no puede expresar la propiedad, ninguna herramienta puede comprobarla.
El autor es un educador y defensor de TLA+ de larga trayectoria. También es un defensor de larga trayectoria de la sensatez. La nueva euforia les preocupa.
¿Qué Llevar de Esto
La conclusión no es que TLA+ sea inútil. Es que es preciso. Sus límites son conocidos. Las propiedades que no puede verificar son las propiedades que no puede verificar — y eso es una fortaleza, no un fracaso.
La propia posición del autor es lúdica y honesta. Cumple con ambas promesas del título: lo que TLA+ puede verificar y lo que no puede.
TLA+ es excelente para diseñar sistemas concurrentes complejos y asegurarse de que estén libres de errores. No es una varita mágica para todo. La mejor manera de usarlo es saber qué hace bien y qué no toca.
Una nota final: el autor es un educador y defensor de TLA+ de larga trayectoria. También es un defensor de larga trayectoria de la sensatez. Su preocupación es que la nueva euforia en torno a la herramienta esté ahogando las salvedades. Eso vale la pena tenerlo en cuenta a medida que continúa la conversación.
Material fuente: “Lo que TLA+ puede y no puede verificar”, buttondown.com.
Recibe El Cuaderno.
Las mejores historias del día y cada veredicto nuevo, en español claro, en tu correo a las siete. Un correo al día, nada más.