Por qué este experimento es tan revelador
Me gustan estas pruebas no por el bombo publicitario, sino por su honestidad incómoda. Tomaron alrededor de 80 tareas de programación y se las dieron a los modelos en dos formatos: Python normal y lenguajes esotéricos Turing-completos. Con Python, el éxito fue de aproximadamente 85-95%, mientras que con los lenguajes esotéricos fue un mísero 0-11%.
Esto no me sorprendió en absoluto. Al contrario, las cifras simplemente resaltaron lo que ya veo en mi trabajo práctico con la generación de código. A menudo, el modelo no "entiende la tarea" de forma abstracta, sino que se mueve con seguridad por las vías conocidas de la sintaxis, los patrones y las soluciones frecuentes.
En resumen, la completitud de Turing por sí sola no es la solución. Formalmente, un lenguaje puede hacer todo lo que hace Python, pero para el modelo, eso no significa que transferirá su habilidad. Esta es la parte desagradable de la historia sobre la transferencia eficiente de muestras (sample-efficient transfer): la transferencia de conocimientos en los transformers sigue siendo bastante frágil.
La fuente aquí no es académica, sino más bien un análisis de investigación en internet en torno a la idea de The Illusion of Thinking (La ilusión de pensar). Es importante decirlo claramente: no presentaría esto como un veredicto final sobre toda la arquitectura. Pero como prueba de estrés para la abstracción, es muy elocuente.
Por qué Python nos engaña más de lo que quisiéramos
He visto muchas veces cómo un equipo mira el alto porcentaje en los benchmarks de Python y saca una conclusión demasiado audaz: "listo, el modelo sabe programar". No, se orienta estadísticamente de maravilla en un ecosistema familiar. Es útil, pero no es sinónimo de pensamiento.
Python es el invernadero ideal para los LLM. Un corpus de código enorme, modismos predecibles, multitud de tareas similares, un mar de documentación y debates. El modelo no solo es fuerte allí, está en casa.
Pero cuando lo saco de su zona de confort y le pido que haga algo en un DSL inusual, un antiguo lenguaje de reglas interno o un formato de configuración enrevesado, la magia se desvanece bruscamente. No porque la tarea sea fundamentalmente más difícil, sino porque desaparece el apoyo de los patrones familiares. Para mí, esto se acerca mucho más a la vida real que otra bonita demostración en Python.
¿Qué cambia esto para los negocios y la automatización?
Para las empresas, la conclusión es muy práctica: no se puede confundir un copiloto exitoso en un stack conocido con un motor de razonamiento universal. Si su implementación de IA depende de procesos no estándar, DSL internos, sistemas heredados o formatos de datos raros, el riesgo de subestimar la fragilidad del modelo es bastante alto.
Yo formularía la regla así: cuanto más se aleje su entorno del internet masivo, menos debería confiar en la "temperatura media de los benchmarks". Necesita sus propios conjuntos de evaluación, sus propias pruebas de transferencia y sus propias limitaciones en la autonomía del agente. De lo contrario, la automatización con IA se verá bien en el piloto y decepcionará en producción.
¿Quién gana? Los equipos que construyen una arquitectura de IA con verificaciones, representaciones intermedias, compilación en pasos controlados y una validación estricta de los resultados. ¿Quién pierde? Aquellos que simplemente intentan acoplar un modelo a un lenguaje de dominio poco común y esperan que "lo resuelva por sí mismo".
En Nahornyi AI Lab nos encontramos con esto regularmente al desarrollar soluciones de IA para procesos internos, no para demostraciones vistosas. Si el dominio es específico, casi siempre incluyo una capa de normalización: primero, traducir la tarea a una representación más estable; luego, generar; y finalmente, verificar automáticamente. No es tan romántico, pero funciona.
Mi conclusión, sin dramas
No voy a gritar que "los modelos no saben pensar en absoluto". Es una fórmula demasiado fácil. Pero definitivamente lo diría de otra manera: su capacidad para transferir conocimientos está muy sobrevalorada, especialmente cuando nos fijamos en lenguajes familiares y benchmarks convenientes.
Si planea implementar inteligencia artificial en su código, operaciones o herramientas internas, tenga en mente una pregunta simple: ¿el modelo está resolviendo mi problema o está reconociendo la forma de un problema familiar? La diferencia entre estos dos escenarios se convierte más tarde en meses de ahorro o en una ilusión muy costosa.
Este análisis fue escrito por mí, Vadim Nahornyi, en Nahornyi AI Lab. Me dedico a construir integraciones de IA, pipelines de agentes y automatización con IA donde hay sistemas heredados, datos no estándar y altas exigencias de calidad. Si lo desea, puedo ayudarle a evaluar su caso con objetividad y a entender juntos dónde reside la fuerza real del modelo y dónde es solo una fachada de confianza.