Nos come la IA #7 — Ayer éramos tres en la pizarra

Ayer reservamos dos horas de pizarra en Miro con Jaime para poner sobre la mesa algo que llevamos meses dándole vueltas: cómo gestionar la fiabilidad de procesos donde se mezclan trozos deterministas y trozos no deterministas. Éramos tres. El tercero era Claude, que iba leyendo la transcripción por trozos mientras hablábamos y escribía reflexiones directamente en la pizarra.

Un tercero en la conversación

Jaime y yo somos buenos proponiendo ideas. Pero a veces damos vueltas a lo mismo sin darnos cuenta, o nos quedamos enganchados en un detalle perdiendo la foto grande. Lo que queríamos probar era si un tercero que no tuviera nuestros sesgos podía ayudarnos a alinearnos.

La semana pasada conté cómo durante la baja de paternidad de Jaime los dos éramos, de hecho, agentes autónomos sin el contexto del otro. Esta semana, con Jaime de vuelta, decidimos probar lo contrario: darle a un tercero nuestro contexto completo y dejarlo participar.

Lo tratamos como un experimento. Le íbamos pasando a Claude la transcripción de lo que hablábamos, y él iba haciendo cosas: sintetizaba lo que llevábamos, encontraba patrones que no veíamos, comparaba nuestras ideas con conceptos que ya existían en el mundo, y de vez en cuando nos hacía notar cosas obvias que se nos habían escapado.

El mejor ejemplo fue así. Llevábamos un rato hablando de cómo desacoplar distintos módulos del sistema para poder tratarlos por separado. Estábamos metidos en el diseño — cajas, flechas, responsabilidades — cuando Claude, en un párrafo breve metido entre dos diagramas, nos hizo notar que, aunque estábamos diseñando desacoplamientos limpios, todo seguía acoplado a través de la base de datos. Lo habíamos pasado por encima por completo. Lo que a nosotros se nos había escapado durante media hora, a él le bastó un minuto para verlo.

Me gustó. No era la herramienta que ejecuta lo que le pides. Era un tercero que participaba en la conversación. Jaime, en un momento, dijo algo que me quedó: "solo faltaría que estuviera en directo". Y tiene razón — lo que queremos ahora es que no tenga que esperar a que le pasemos la transcripción, sino que esté escuchando en vivo, haciendo búsquedas por internet y mirando el código en paralelo mientras hablamos.

Calcificar decisiones

El tema concreto del brainstorm era uno que Jaime y yo venimos masticando desde hace semanas: la calcificación. El término ya lo teníamos — lo usamos para hablar de cuando una decisión que tomaba un LLM se convierte en código determinista y deja de pasar por el modelo. Lo que salió del brainstorm no es la palabra. Es el marco para aplicarla bien, y una analogía que trajo Claude y que nos ayudó a darle forma.

El problema es este: los LLMs son muy buenos tomando decisiones no deterministas. Les das un caso raro, lo razonan, sacan algo coherente. Pero esas decisiones tienen tres problemas: son difíciles de auditar, son caras y son lentas. Si cada vez que un cliente sube una factura mi sistema tiene que llamar a Claude para decidir qué hacer con ella, el coste se dispara y la velocidad se hunde.

La analogía: tratar al LLM como un intérprete de código. Al principio, cuando estás descubriendo el dominio, todo pasa por él — flexibilidad máxima, velocidad mínima. Pero cuando detectas que toma la misma decisión una y otra vez sobre el mismo patrón, la calcificas: conviertes esa decisión en código determinista. A partir de ahí, ese caso ya no llama al LLM. Es exactamente lo que hace V8, el motor de JavaScript de Chrome, con la compilación JIT: el código que se ejecuta muchas veces se compila a máquina, el que se ejecuta poco se queda interpretado.

Ya lo estamos aplicando. En reconciliaciones bancarias, por ejemplo, el LLM va decidiendo qué apunte del banco casa con qué factura. Cuando detecta un patrón repetido, crea un alias: "cada vez que veas esta descripción del banco, reconcilia con este proveedor". Eso ya es código determinista. El modelo no vuelve a entrar ahí.

Ahora, la parte que nos queda abierta es la que me quita el sueño: si la regla calcificada estaba mal, ¿cómo la corrijo? Una vez que una decisión se convierte en código, ya no pasa por el modelo — puede estar generando errores sistemáticos invisibles durante semanas. Estamos montando un framework para encapsular todo esto. Jaime va a estar metido en ese framework, y yo voy a seguir peleándome con el día a día y los problemas reales de los clientes. Reparto clásico.

Pero Anthropic contrata contables

Esta semana Jaime me pasó un artículo que me hizo una sacudida. Anthropic — 30.000 millones de dólares de ingresos anuales, 380.000 millones de valoración, el laboratorio con los mejores modelos del mundo — acaba de contratar 18 contables humanos.

Y ahí me paré. En el número dos de este newsletter escribí que en Intelia no íbamos a contratar a nadie — que preferíamos ir más rápido con dos personas y una caja llena de agentes que montando equipo. Pero si una empresa con los mejores modelos del mundo tiene que contratar contables humanos para llevar su propia contabilidad, la pregunta se me clava: ¿cuánto de lo que intentamos automatizar se puede automatizar de verdad?

Cuanto más avanzo con Intelia, más cuenta me doy de lo complicado que es todo. La contabilidad no es una cadena lineal — es una maquinaria de relojería donde cada pieza engrana con las demás. ¿Este documento está duplicado o no? ¿Este cobro se puede reconciliar con esta factura? ¿Cómo se contabiliza una factura en moneda extranjera cuando el banco aplica una comisión oculta? Cada decisión depende de cinco decisiones previas, y un error pequeño en el paso uno se convierte en un nudo imposible en el paso siete.

Mi duda es honesta: ¿esto es algo que vamos a resolver picando piedra — caso por caso, calcificando lo que funciona — o hay un techo al que no vamos a llegar nunca? Hasta hoy, ni Jaime ni yo tenemos una respuesta clara.

EY tampoco la tiene. Esta semana anunció que ha desplegado agentes de IA a los 130.000 auditores de su división de assurance, con un modelo que llama "supervised autonomy": los agentes ejecutan, los humanos firman. Es, a escala industrial, la arquitectura de confianza por capas de la que hablé en el número cuatro, estirada a 160.000 engagements anuales en 150 países. El problema real es quién asume la responsabilidad cuando el agente se equivoca y el humano firma sin mirar. Esa pregunta no aparece en el press release.

La ventaja son los meses que llevas de adelanto

La otra noticia grande de la semana es que Anthropic ha lanzado Claude Managed Agents — una plataforma para que cualquier empresa despliegue agentes en producción sin tener que construir la infraestructura. Precio: tokens normales más ocho céntimos por hora de sesión activa. Notion, Rakuten y Asana ya están usándolo.

Y aquí voy a decir algo que probablemente no sea popular: esto me preocupa.

No me preocupa porque vaya en contra de mi arbitraje — el arbitraje no es cosa mía, es una ventana temporal que está abierta y que se va consumiendo. Lo sé desde el principio. Lo que me preocupa es la velocidad con la que esa ventana se está cerrando. Cuanto más fácil pone Anthropic el desplegar agentes en producción, menos meses quedan entre lo que yo sé hacer hoy y lo que la empresa normal sabrá hacer mañana. La ventana no se cierra de golpe — se acorta un poco cada vez que sale un producto así.

Mi conclusión es que la única ventaja estable es la velocidad. Los modelos chinos van entre seis y doce meses por detrás de Claude y GPT en los casos donde los uso a diario. La gente que todavía usa ChatGPT casual en vez de Claude Code o Cursor probablemente va un año por detrás. Mi trabajo es mantener ese delta tan grande como pueda durante el mayor tiempo posible.

Lo mismo con Cursor 3, que esta semana lanzó una interfaz orientada a "flotas de agentes": ya no es un IDE, es un orquestador. Y así con todo. Cuando sale algo revolucionario, el resto del ecosistema converge hacia ahí en meses. Tu ventaja no está en qué herramienta usas — está en cuánto tiempo llevas apretándole las tuercas.

Por eso tampoco me creo el titular que salió esta semana — "solo el 7% de los CFOs ve ROI real en sus inversiones en IA". Es demasiado pronto. Casi todas las implementaciones que he visto por ahí son superficiales — un chatbot pegado con celo encima de un proceso que nadie ha rediseñado. El retorno va a llegar, y cuando llega, llega en serio.

Un ejemplo concreto. Esta semana escuché un podcast con la gente de Tuio, una aseguradora española. Conozco a algunos de ellos. Lo que contaron es que han conseguido márgenes el doble de altos que la media de la industria — y no por magia, sino por meter IA con cabeza en operaciones y en marketing. No es un chatbot pegado con celo: es un rediseño real de cómo hacen las cosas. Ese es el tipo de ROI que el estudio de los CFOs no está capturando, porque todavía no ha llegado a la mayoría. Pero llega.

Una recomendación práctica

Y para terminar, una cosa que me viene siendo útil y que probablemente recomendaría a cualquiera que esté trabajando en serio con agentes: memoria episódica.

Claude — y cualquier LLM — por defecto no recuerda nada de una conversación a la siguiente. Cada vez que empiezas, es tabula rasa. Eso está bien para preguntas rápidas, pero si estás trabajando en un proyecto durante meses, cada arranque en frío es tiempo y tokens que gastas solo para ponerlo al día. Y a veces olvida cosas importantes que decidiste hace quince días y que no están en el código.

Llevo unos tres meses usando un plugin de episodic memory — parte del paquete de superpowers para Claude Code — que me deja buscar en mis conversaciones pasadas cuando se lo pido. En este tiempo me ha ido salvando de repetir errores que ya había cometido, recuperando decisiones que habíamos tomado hace semanas, y rescatando reflexiones sueltas que de otra forma se habrían perdido. No es un experimento de esta semana: ya es parte del flujo.

Relacionado con esto, algo que también llevo meses intentando hacer más es guardar los brainstorms dentro del codebase, en un markdown, para que el agente los tenga delante la próxima vez que arranque. Esto es, en cierto modo, otra forma de calcificar — pasar decisiones y razonamientos humanos a texto estructurado que el agente puede leer en frío. Lo mismo que convertir una decisión repetida en código determinista, pero con razonamientos en vez de con lógica.

Donde sí me falta trabajo es en el siguiente paso: reflexionar y limpiar esos brainstorms acumulados. Si solo guardas sin podar, al final tienes un basurero útil donde todo pesa lo mismo. Ese es probablemente el trabajo de la semana que viene.

Si la semana que viene hay que hacer otro brainstorm, volveremos a ser tres. Y con un poco de suerte, la próxima vez estará en directo.

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.