Pregúntale a un modelo de lenguaje cuántas letras tiene la palabra “strawberry”. Es muy probable que se equivoque. Podría decir diez. Podría adivinar once. Sonará completamente seguro de sí mismo y, aun así, será incorrecto. Pídale al mismo modelo que calcule el interés compuesto de un préstamo, que sume dos números grandes o que cuente los días hábiles entre dos fechas, y a menudo obtendrá una respuesta con apariencia plausible pero con dígitos que son ligeramente, y peligrosamente, erróneos.

Esto sucede porque los modelos de lenguaje extensos no razonan sobre los números de la misma manera que los humanos. Predicen tokens. Un token puede ser una palabra completa, parte de una palabra o un solo dígito. Cuando el modelo ve “strawberry”, no ve ocho letras individuales alineadas en una fila. Ve un puñado de fragmentos. Nunca se le ha enseñado a contar caracteres, solo a predecir qué fragmento de texto sigue. La misma limitación se aplica a la aritmética. El modelo no tiene una calculadora interna. Carece de lógica de acarreo. No tiene una comprensión real del valor posicional. Cuando multiplica 148 por 279, no está realizando una multiplicación. Está buscando patrones en expresiones similares que vio durante el entrenamiento, adivinando qué secuencia de dígitos debería seguir. Para sumas pequeñas, el patrón es lo suficientemente fuerte como para funcionar. Para cualquier cosa que requiera precisión real, la suposición eventualmente falla.

Dos tareas, un solo bot

Los métodos de prompting estándar piden a un solo sistema que haga dos cosas muy diferentes a la vez. Primero, comprender la lógica del problema. Segundo, ejecutar la matemática exacta. El modelo es genuinamente impresionante en la primera tarea. Puede leer un problema matemático, extraer variables, mapear relaciones y planificar una ruta de solución. Pero luego tiene que servir como su propia calculadora. Ahí es donde la cadena se rompe. Un solo dígito erróneo en el tercer paso infecta todos los pasos siguientes. La lógica en sí puede ser perfecta, pero la respuesta final es basura porque el modelo sumó mal.

Los Modelos de Lenguaje Asistidos por Programación, o PAL (Program-Aided Language Models), resuelven esto dividiendo el trabajo. En lugar de pedirle al modelo una respuesta, le pides un programa.

Así es como funciona realmente el flujo. Presentas el problema. El modelo deduce la lógica, define las variables y estructura el algoritmo. Luego, en lugar de calcular el resultado por sí mismo, escribe un script corto, generalmente en Python. Ese script se entrega a un intérprete de código real. El intérprete ejecuta la lógica y devuelve el resultado exacto y determinista. El modelo describe la matemática. Python hace la matemática.

Razonamiento ejecutable en la práctica

Piensa en PAL como razonamiento ejecutable. Si un script puede resolver un problema, deja que el modelo escriba el script.

Considera un ejemplo concreto. Necesitas calcular el monto al vencimiento de un depósito fijo de ₹50,000 a una tasa de interés anual del 8.5 por ciento, con capitalización trimestral, mantenido durante siete años. Si le preguntas directamente a un modelo de lenguaje, podría escribir una fórmula, sustituir los valores y calcular el resultado mediante una cadena de pensamiento. Sin embargo, si observas de cerca, podrías descubrir que manejó mal la capitalización trimestral al dividir la tasa incorrectamente, o que redondeó un paso intermedio y arrastró el error. La respuesta parece razonable, pero tiene un error de cientos de rupias.

Con PAL, la interacción cambia. Instruyes al modelo para que genere código Python que defina principal = 50000, rate = 0.085, time = 7 y n = 4, y luego calcule amount = principal * (1 + rate/n) ** (n * time). El modelo emite el código. Un entorno de ejecución de Python lo ejecuta. Obtienes la cifra precisa, hasta el último decimal, cada vez. No hay conjeturas en la multiplicación, ni restos alucinados, ni errores de redondeo confiados.

Este mismo patrón se aplica al cálculo de fechas. Pregúntale a un modelo qué fecha cae exactamente dentro de 120 días hábiles a partir de hoy, excluyendo los fines de semana. Un modelo basado solo en texto podría contar hacia adelante y equivocarse con un sábado. Un enfoque PAL hace que el modelo escriba un script utilizando la lógica de datetime y calendar, y luego deja que el intérprete itere con exactitud. La manipulación de datos funciona de la misma manera. Si necesitas analizar un CSV desordenado, filtrar un JSON anidado o realizar una transformación estadística rápida, el modelo debe redactar la lógica mientras el intérprete se encarga de la iteración.

Por qué esto es realmente importante

El cambio de respuestas en prosa a código ejecutable ofrece tres ventajas prácticas.

Determinismo. Un modelo de lenguaje al que se le haga la misma pregunta dos veces podría variar su redacción o cambiar un dígito. Un intérprete devuelve la misma salida para la misma entrada cada vez. Esa estabilidad es fundamental en contabilidad, logística, planificación y cualquier cálculo de ingeniería donde la consistencia no es opcional.

Verificabilidad. Cuando un modelo te entrega tres párrafos de razonamiento, debes leer cada frase para buscar el único número erróneo. Cuando te entrega un script de diez líneas, puedes revisar el código. Puedes verificar que la fórmula de interés compuesto sea correcta antes de que el intérprete se ejecute. Puedes inspeccionar los nombres de las variables, detectar errores de desfase (off-by-one) e incluso aplicar control de versiones a la solución. El área de exposición a errores ocultos se reduce drásticamente.

Fiabilidad. El modelo se mantiene en su carril. Hace lo que fue diseñado para hacer: razonar sobre la estructura, la semántica y la descomposición de problemas. La máquina hace lo que fue diseñada para hacer: computar con precisión. Esta separación de responsabilidades es exactamente cómo se arquitecta el software fiable. La composición supera al diseño monolítico.

Ejecútelo como código no confiable

Es necesaria una advertencia. El código generado debe tratarse como una entrada no confiable. El modelo podría escribir un script con un bucle infinito, una solicitud de red innecesaria o una operación de sistema de archivos que no solicitaste. Ejecuta siempre estos programas dentro de un entorno aislado (sandbox). Utiliza contenedores con privilegios restringidos, funciones serverless sin acceso a la red o entornos estrictamente controlados con tiempo de CPU limitado y sin almacenamiento persistente. La seguridad no es una nota al pie aquí. Es parte del diseño del sistema.

Dónde brilla PAL y dónde se detiene

PAL funciona de maravilla para matemáticas, fechas y manipulación de datos estructurados. Elimina los errores mecánicos que plagan el razonamiento basado únicamente en texto.

Sin embargo, no corrige la lógica defectuosa. Si el modelo elige la fórmula incorrecta,