Métodos formales para reducir bugs críticos

Jane Street volvió a empujar una conversación que en software solemos dejar para cuando ya hubo un incidente: cómo probar que un sistema hace exactamente lo que dices que hace, no solo que “parece” funcionar. En su blog han explicado varias veces por qué usan métodos formales en partes críticas de sus sistemas, y el punto de fondo es simple: si un bug te puede costar dinero real en milisegundos, no basta con tests y revisión manual.

Eso no significa que tengas que convertir todo tu stack en una tesis de lógica matemática. Significa que hay una clase de problemas donde el costo de un error es tan alto que conviene invertir más rigor desde el diseño. Si trabajas en fintech, trading, pagos, infraestructura o sistemas que mueven dinero en LatAm, esta conversación te toca de cerca.

Qué son los métodos formales y por qué importan

Los métodos formales son técnicas para especificar, modelar y verificar software usando matemáticas. En vez de confiar solo en pruebas sobre casos concretos, intentas demostrar propiedades del sistema: que nunca entra en cierto estado inválido, que una transición siempre conserva una regla, o que dos componentes no pueden romper una invariancia crítica.

La idea no es nueva. Lo nuevo es que hoy hay más herramientas, mejores lenguajes y más presión económica para evitar errores que antes se aceptaban como parte del costo de operar. Cuando un sistema procesa miles de eventos por segundo o mueve dinero entre cuentas, un bug de borde no es un detalle académico. Puede convertirse en pérdida directa, reconciliaciones manuales, soporte, multas o incidentes regulatorios.

Jane Street es un caso interesante porque opera en un entorno donde la precisión no es opcional. Si tu sistema de pricing, risk checks o routing toma una decisión incorrecta, el impacto puede aparecer en segundos. Por eso su postura sobre métodos formales no es teórica: responde a una necesidad de negocio.

Métodos formales no son solo “probar más”

Aquí conviene separar conceptos. Las pruebas unitarias verifican ejemplos concretos. Las pruebas de integración validan que varias piezas colaboran. Las pruebas end-to-end recorren flujos completos. Todo eso ayuda, pero sigue siendo muestreo.

Los métodos formales apuntan a propiedades generales. Por ejemplo:

• “Nunca se puede debitar más de lo disponible”
• “Toda orden válida debe terminar en uno de estos tres estados”
• “Si una transacción se confirma, entonces ya pasó por validación de riesgo”
• “No existen dos rutas que puedan duplicar una ejecución”

Ese cambio de enfoque te obliga a pensar mejor el sistema. No solo en cómo se usa, sino en qué reglas debe respetar siempre.

Dónde sí vale la pena aplicar rigor extra

No todo merece verificación formal. Si estás armando una landing, un CMS o una app interna sin impacto financiero directo, probablemente te convenga invertir en tests, observabilidad y buen code review antes que en un modelo formal completo.

Pero hay zonas donde el retorno sube rápido:

1. Lógica de pagos y conciliación.
2. Motor de reglas de riesgo o crédito.
3. Sistemas de autorización y permisos.
4. Infraestructura distribuida con estados delicados.
5. Algoritmos de matching, pricing o liquidación.

En esos casos, una especificación clara puede evitar semanas de debugging. Y si además puedes demostrar propiedades clave, reduces la probabilidad de bugs que pasan todas tus pruebas porque nadie pensó en ese estado raro.

Qué hace Jane Street distinto

Jane Street no vende una narrativa de “IA para programar por ti” ni de automatizar la disciplina. Su enfoque es más sobrio: usar herramientas que ayuden a razonar mejor sobre sistemas complejos. En su blog han mostrado interés sostenido por técnicas como model checking, especificaciones más precisas y verificación de propiedades relevantes para su dominio.

Ese tipo de empresa entiende algo que muchas organizaciones descubren tarde: el costo de un bug no se mide solo en horas de ingeniería. También se mide en operaciones manuales, pérdida de confianza, riesgo legal y ruido para el negocio. Cuando el sistema toca dinero, cada error se multiplica.

En la práctica, Jane Street trabaja con un ecosistema donde la precisión y la performance conviven. No puedes permitirte un enfoque lento, pero tampoco puedes vivir a base de “ya lo arreglaremos en producción”. Ahí es donde los métodos formales encajan bien: ayudan a encontrar fallos antes de desplegar.

El valor real está en acotar el problema

Un error común al hablar de métodos formales es pensar que necesitas verificar todo el programa. No. Lo normal es elegir una parte pequeña pero crítica y ponerle una especificación fuerte.

Por ejemplo, en vez de intentar demostrar todo un sistema de trading, puedes enfocarte en:

• el validador de órdenes,
• el cálculo de límites de riesgo,
• la máquina de estados de una transacción,
• o la lógica de compensación ante fallos.

Ese recorte hace la técnica viable. También mejora la conversación entre ingeniería y negocio, porque la pregunta deja de ser “¿podemos probar el sistema entero?” y pasa a ser “¿qué propiedad nos costaría más romper?”.

Un costo menor que un incidente repetido

Supón que una falla de conciliación te genera 0.5% de operaciones con revisión manual. Si procesas 200,000 operaciones al mes, son 1,000 casos extra para revisar. Si cada caso toma 6 minutos entre soporte y back office, estás hablando de 100 horas mensuales. Eso sin contar el costo reputacional.

Ahora imagina que una especificación formal detecta un caso de doble conteo en una transición de estados antes de producción. El costo de modelar y verificar una parte del flujo puede ser alto al principio, pero el ahorro se acumula cada mes que no repites el error.

Qué problemas resuelven mejor que los tests

Los métodos formales brillan cuando el espacio de estados es grande y los errores aparecen en combinaciones raras. Los tests ayudan mucho, pero siempre cubren una muestra finita. Si el bug depende de una secuencia específica de eventos, de una condición de carrera o de una transición poco frecuente, es fácil que se escape.

Eso pasa en sistemas financieros, pero también en cualquier software con estado compartido. El patrón se repite: el caso feliz funciona, el borde raro no.

Casos donde una especificación ayuda más que 100 tests

• Estados imposibles: evitar que una orden sea “ejecutada” y “cancelada” al mismo tiempo.
• Invariantes contables: asegurar que los saldos no se vuelvan negativos si la regla de negocio lo prohíbe.
• Secuencias válidas: impedir que un reembolso ocurra antes de la captura del pago.
• Concurrencia: evitar carreras entre dos workers que procesan el mismo evento.
• Reglas de acceso: garantizar que un usuario sin permiso no pueda saltarse una validación por una ruta secundaria.

En estos casos, el valor no está solo en encontrar bugs. También está en documentar el comportamiento esperado de una manera que no dependa de interpretación humana.

Tabla comparativa rápida

La tabla no dice que uno reemplaza al otro. Dice que cada técnica ataca una clase distinta de riesgo. Si haces productos para LatAm, donde a veces conviven integraciones viejas, proveedores externos inestables y reglas locales cambiantes, esa combinación importa mucho.

Cómo empezar sin volver tu proyecto inmanejable

La forma más sensata de entrar a métodos formales es pequeña y concreta. No empieces por reescribir toda tu arquitectura. Empieza por un dominio donde el bug sea caro y la lógica sea relativamente acotada.

Si tu equipo trabaja en Ecuador, México, Colombia, Perú o Chile, probablemente ya conoces sistemas donde una validación mal hecha termina en tickets, reversos o conciliaciones manuales. Allí hay una oportunidad clara para aplicar más rigor.

Un plan de adopción razonable

1. Identifica una regla de negocio que nunca deba romperse.
2. Escríbela en lenguaje natural con precisión, sin ambigüedades.
3. Convierte esa regla en una especificación formal o semiforma verificable.
4. Modela solo el subsistema mínimo que afecta esa regla.
5. Usa tests para cubrir ejemplos y la especificación para cubrir propiedades.
6. Revisa el resultado con alguien de producto o riesgo, no solo con ingeniería.

Ese flujo evita el error típico de hacer una demostración elegante que no responde a una necesidad real.

Herramientas y enfoques que sí puedes mirar

No necesitas casarte con una sola herramienta. Según el problema, puedes explorar:

• TLA+ para sistemas distribuidos y estados concurrentes.
• Coq o Lean para pruebas más profundas sobre propiedades matemáticas.
• Alloy para modelar relaciones y encontrar contraejemplos.
• Type systems avanzados y tipos dependientes en casos muy concretos.

La documentación oficial de TLA+ es un buen punto de partida si te interesa modelar sistemas concurrentes: https://lamport.azurewebsites.net/tla/tla.html

Si tu equipo trabaja con especificaciones de protocolos o consistencia, también vale leer material oficial de Alloy: https://alloytools.org/

Y si quieres entender el enfoque de Jane Street desde su propia voz, su índice de artículos sobre métodos formales está aquí: https://blog.janestreet.com/formal-methods-at-jane-street-index/

Qué medir para saber si valió la pena

No midas solo “cuántos bugs encontramos”. Eso puede sesgar la conversación. Mejor mira señales más útiles:

• menos incidentes en producción,
• menos tickets de soporte por casos límite,
• menos tiempo de investigación cuando algo falla,
• menos trabajo manual en reconciliación,
• más confianza para cambiar código crítico.

Si después de tres meses sigues teniendo el mismo volumen de errores en el mismo módulo, quizá el problema no era falta de rigor sino falta de claridad en la especificación.

Qué te llevas si construyes software para dinero real

Si tu producto toca pagos, crédito, compliance o trading, los métodos formales no son un lujo académico. Son una forma de reducir incertidumbre donde el error cuesta. Eso no elimina la necesidad de tests, observabilidad o buenas prácticas de ingeniería. Las complementa.

La lección de Jane Street no es que debas formalizar todo. Es que hay equipos que ya entendieron que ciertas partes del sistema merecen una inversión distinta. Cuando el dominio es sensible, un poco más de rigor puede evitar mucho trabajo posterior.

También hay una lección cultural. En muchos equipos de software, el código se trata como algo que se corrige después. Los métodos formales invierten esa lógica: primero defines con precisión qué debe pasar, luego implementas. Ese orden reduce ambigüedad entre ingeniería, producto y negocio.

Si trabajas en LatAm, donde además conviven restricciones de infraestructura, integraciones de terceros y cambios regulatorios frecuentes, esa precisión te puede ahorrar más de un susto. No porque sea elegante, sino porque funciona mejor cuando el costo del fallo es alto.

Tabla resumen