Nos come la IA #5 — Paré la máquina y leí el código

Esta semana vi que iba al 96% de mi límite de tokens en Claude y decidí hacer algo que llevaba meses sin hacer: parar la máquina, dosificar cada token como si fuera oro, y dedicar dos días a mirar las cosas con calma. A leer el código yo mismo. A pensar.

Justo esta semana Jensen Huang declaró en el podcast de Lex Fridman que "hemos alcanzado el AGI". Karpathy le contradijo al instante. Silicon Valley se partió en dos. Y yo, mientras tanto, con el capó abierto, mirando espagueti.

Lo que encontré debajo del capó

Llevo semanas atascado con un problema de sincronización entre nuestra plataforma de contabilidad y Holded. El patrón era siempre el mismo: encuentro un fallo, le pido a Claude que lo diagnostique, lo arregla, ejecuto, funciona... y se rompe otra cosa. Parche, test, parche, test. Ciclo infinito.

Nunca me había metido a mirar cómo estaba montado por debajo. Confiaba en que la IA iba resolviendo. Pero esta semana, con los tokens contados, en vez de seguir lanzando agentes a resolver síntomas, abrí el código y lo leí.

Lo que encontré fue un desastre. Código largo, espagueti, lleno de parches ad hoc para problemas específicos. Nada generalizable. Cada arreglo resolvía el síntoma pero no tocaba la estructura.

Es como ir al fisio por el tobillo — que casualmente también me pasa. Te quita el dolor, pero tu problema real no está ahí. Está en cómo caminas, en tensiones de otro lado que compensas sin darte cuenta. Con la IA pasa igual: le pides que arregle un bug y te arregla el bug. Pero no se pregunta si la estructura tiene sentido. Si no le pides que arquitecte, te pone un parche. Y parche sobre parche se convierte en basura al cuadrado.

La misma semana, el mismo patrón, otro proyecto

Estoy montando una plataforma de cuentos infantiles — todavía en beta cerrada — donde la IA genera y narra audiocuentos para niños. Para el proceso de creación, diseñé un pipeline sofisticado: primero el modelo crea los personajes con su contexto, luego genera un guión narrativo, después aplica técnicas literarias de un catálogo enorme que compilé, y finalmente un revisor pasa coherencia y ortografía. Cuatro capas, todo muy estructurado.

El problema: demasiada información en cada capa. El LLM intentaba cumplir todos los checks que le pedía y sacrificaba lo más importante — que el cuento fuera interesante. Tras ocho rondas de iteración, descubrí que un prompt sencillo de quince líneas generaba mejores cuentos que toda mi estructura con 230 referencias narrativas, 62 técnicas literarias y 184 líneas de reglas.

Dos proyectos, dos contextos distintos, mismo error. En el código, el agente parcheaba sin entender la arquitectura. En los cuentos, yo le daba tanta información que el modelo no sabía qué era importante y qué no. En ambos casos, el exceso producía peores resultados que la simplicidad.

No soy el único

Mi socio Jaime me pasó un artículo de Mario Zechner — "Slowing the fuck down" — que nombra exactamente lo que me estaba pasando. Tres ideas que me resonaron: los agentes como merchants of complexity, tomando decisiones locales sin ver el contexto global. Los errores acumulándose sin que nadie los detecte porque no hay humano revisando. Y cuanto más código genera el agente, peor busca dentro de él, y más duplica. Un ciclo que se retroalimenta.

Su tesis: la fricción de leer código y entender la arquitectura no es un obstáculo — es la única defensa contra la deuda técnica invisible.

Me sentí identificado al cien por cien. A veces tengo la sensación de estar en una carrera por gastarme los tokens. Produzco trabajo con un montón de pestañas en paralelo y no dedico tiempo suficiente a pensar en la arquitectura. Jaime me contó que una startup que seguimos dedica la mitad del tiempo a crear funcionalidades y la otra mitad a mejorar el proceso — definir el contexto, la arquitectura, los prompts, la memoria. Creo que es un ratio que deberíamos aplicar más.

El AGI, el cañón y el contexto

Volviendo a lo de Jensen Huang y el AGI: para mí es marketing puro. Lo que tengo claro es que hay un puto cañón ahora mismo que puedes utilizar para prácticamente lo que quieras. Un cañón que da un poco de miedo y requiere inversión de tiempo para controlarlo, pero es brutal. ¿Autonomía total? No lo sé. ¿Inteligencia bruta? Máxima.

¿Es una trampa la autonomía total de agentes? No creo. El problema no es la autonomía, es el contexto. Si el agente tuviera todo mi contexto — cómo quiero que se estructure el código, dónde está todo organizado, qué planes tengo — podría ser autónomo. Me encantaría enchufar un chip a mi cerebro para que piense como yo. Mientras tanto, toca parar de vez en cuando, revisar qué hay debajo, y asegurarte de que le has dado la información correcta.

Esta semana Anthropic lanzó la capacidad de que Claude controle tu Mac de forma autónoma — abrir archivos, navegar, clicar, usar aplicaciones. Más herramientas para el agente. Pero para mí hay tres líneas de trabajo en IA ahora mismo: darles herramientas, darles contexto, y organizar la memoria para que ese contexto se ubique correctamente. De herramientas se habla mucho. Pero la memoria y las estructuras de información son la clave real. Son lo que marca la diferencia entre un agente que parchea y uno que arquitecta.

La otra cara de la velocidad

Y hablando de cosas que van demasiado rápido: esta semana descubrieron que LiteLLM, un paquete Python con 97 millones de descargas mensuales que sirve de proxy para modelos de IA, había sido comprometido con malware. El código robaba SSH keys, credenciales de cloud, y si encontraba Kubernetes, creaba pods con backdoors en todos los nodos del cluster.

Nosotros lo usamos en Intelia. Por suerte, no estamos en la versión comprometida.

Pero es la misma historia de fondo. En este mundo donde es tan fácil desarrollar — le pides a Claude que te instale un paquete y en segundos lo tienes funcionando — también es muy fácil que cualquiera se convierta en un bad actor. Contribuir a proyectos open source es fácil. Meter mierda, también. Irónicamente, las propias IAs podrían ser las que identifiquen código malicioso antes de que llegue a producción. Pero hasta entonces, conviene mirar lo que instalas. Otra razón para ir más despacio.

La lección de esta semana es simple: de vez en cuando, para la máquina y lee lo que hay debajo. La velocidad es adictiva, pero la fricción de entender lo que estás construyendo no es un bug — es un feature.

Nos come la IA es un newsletter semanal de Pablo Muniz, cofundador de Intelia. Si te ha gustado, compártelo con alguien que hable de IA pero no la haya tocado.