Cuando la IA falla por razones que no tienen nada que ver con la inteligencia

Hay un tipo muy particular de frustración que sientes cuando ves que un sistema inteligente falla por razones estúpidas. Lo experimenté hace poco mientras experimentaba con agentes de codificación locales con IA, una tendencia que está ganando tracción a medida que los modelos de código abierto se vuelven más capaces y el desarrollo respetuoso con la privacidad cobra importancia.

La prueba era sencilla: ¿puede un agente de codificación funcionando enteramente en hardware local construir un juego funcional? No un demo trivial, sino algo con gestión de estado real, lógica de renderizado, manejo de inputs y una interfaz jugable. La respuesta, después de rascarte la cabeza bastante, fue sí, pero llegar ahí reveló una clase de problemas que el ecosistema de herramientas de IA no está manejando con elegancia.

La configuración que debería haber funcionado

El stack tenía tres componentes que representan lo último en desarrollo de IA local: un CLI de agente de codificación agnóstico de proveedor, Ollama sirviendo una API compatible con OpenAI desde localhost, y Qwen3.8 27B ejecutándose en la máquina local. Para contextualizar, esto no es una configuración mediocre: el modelo 27B a 17GB cabe holgadamente en 32GB de memoria unificada y soporta tool calling con capacidades de razonamiento respetables.

Los resultados iniciales fueron prometedores. En quince minutos, el agente había producido una estructura HTML completa y casi 200 líneas de CSS con estilo NES, con bordes biselados y una paleta de colores apropiada. Más impresionante aún, el agente detectó su propio error a mitad de camino: escribió un archivo, lo reléyo, notó una discrepancia entre lo que pretendía y lo que quedó en disco, y lo reparó sin que nadie se lo pidiera. Ese es comportamiento genuinamente agentivo, y sugería que el modelo estaba a la altura de la tarea.

Entonces el agente intentó escribir el archivo de lógica del juego, y todo se detuvo.

La espiral de muerte

Lo que siguió fue una secuencia que cualquiera que haya lidiado con herramientas de IA reconocerá. Trece intentos consecutivos para escribir el archivo del motor del juego, cada uno terminado a mitad de generación. El stream simplemente moría, sin producir error, sin explicación, sin salida útil.

Lo más enloquecedor no fue el fallo en sí, sino observar el proceso de razonamiento del agente. Como cada intento comenzaba desde cero, el modelo derivaba las mismas decisiones de diseño desde el principio, llegando a tablas de puntuación y enfoques de implementación diferentes cada vez. Tres reintentos significaban tres respuestas distintas a la misma pregunta arquitectónica. El agente estaba pensando durante una hora y no estaba entregando nada.

La causa obvia parecía ser presión de memoria. Cerrar pestañas del navegador liberó varios gigabytes de RAM y las cosas mejoraron marginalmente, lo cual parecía confirmar el diagnóstico. Pero esta era la lección equivocada.

Lo que los logs revelaron realmente

Volver a revisar los logs del servidor contaba una historia diferente. No había ni un solo error de memoria en ninguno de ellos. La memoria libre del sistema se mantenía cómodamente entre 21 y 27 gigabytes durante todo el proceso, contra una huella del modelo de 17 gigabytes. La memoria nunca fue el problema.

El verdadero problema era un desacuerdo en la configuración que no producía ningún error visible. La configuración del agente anunciaba una ventana de contexto de 32,768 tokens. Pero el servidor de Ollama se había reiniciado con un límite de 8,192 tokens, y esta discrepancia pasó desapercibida. El agente planificaba felizmente un archivo de 800 líneas para escribir de un tirón, porque según él, tenía 32k de margen. Cuando la generación real chocaba contra el muro de 8k a mitad del tool-call, la conexión se cortaba sin ningún mensaje de error que el agente pudiera razonar.

Había una complicación secundaria escondida en los logs de inicio: Ollama había arrancado con context shifting habilitado, lo cual habría permitido que la ventana se deslizara cuando se quedara sin espacio, sacrificando tokens antiguos para hacer lugar a los nuevos. Pero la arquitectura del modelo no soportaba esta característica, así que se deshabilitaba silenciosamente. Lo que debería haber sido un límite flexible se convirtió en una pared dura.

La disciplina DevOps que exige el desarrollo con IA

Esta experiencia cristaliza algo importante sobre el desarrollo de IA local que el entusiasmo alrededor de los modelos de código abierto tiende a oscurecer. Cuando ejecutas modelos en tu propio hardware, no estás solo escribiendo código: estás operando infraestructura. Y la infraestructura requiere la misma disciplina de diagnóstico, gestión de configuración y atención a los parámetros operativos que demandan los sistemas en producción.

Las ventanas de contexto no son propiedades abstractas del modelo para configurar y olvidar. Son parámetros operativos que interactúan con tu cadena de herramientas de formas no obvias. Cuando el contexto configurado en el agente no coincide con el límite real del servidor, no recibes una advertencia: recibes fallos silenciosos que parecen incompetencia del modelo cuando en realidad son desconfiguración operativa.

El mensaje práctico para desarrolladores que exploran agentes de codificación locales con IA es directo: valida tu entorno tan exhaustivamente como validarías un despliegue en producción. Verifica que la configuración de tu agente coincida con tus parámetros de ejecución. Lee los logs del servidor, no solo la salida del agente. Entiende qué características soporta realmente la arquitectura de tu modelo versus lo que la herramienta intenta habilitar.

Los modelos están mejorando. Las herramientas están madurando. Pero la brecha entre "funciona en demos" y "funciona de forma confiable en uso diario" todavía requiere juicio humano para cerrarla, y ese juicio se parece mucho a la disciplina tradicional de DevOps aplicada a una nueva clase de infraestructura.

La construcción del Tetris eventualmente tuvo éxito. Tomó cuatro horas y media a lo largo de dos días, produjo código limpio en tres archivos, y funciona correctamente. Pero las lecciones no vinieron del éxito, sino de entender por qué ocurrieron los fallos, y reconocer que a veces los problemas más caros no tienen nada que ver con la inteligencia.