Por qué reparto el trabajo entre varias IA y publico lo que sale mal

2026-05-29

Por qué reparto el trabajo entre varias IA y publico lo que sale mal

Durante una temporada trabajé con una sola IA. Le encargaba tareas largas, de varios pasos, y al rato me contestaba que ya estaba: "hecho". Más de una vez no estaba hecho. Tampoco había drama: ningún mensaje de error, nada roto a la vista. Así es como falla una IA que trabaja sola: en silencio. Me entregaba un resultado con un fallo metido en el medio, contado con la misma seguridad que todo lo demás.

Cuanto más larga es la tarea, más sitio hay para que se cuele algo así sin que nadie lo note. Y lo curioso es que no es falta de capacidad: si le señalo el error directamente, casi siempre lo ve y lo corrige. Con el tiempo cambié de idea sobre esto. No era un fallo de la herramienta; era un fallo en cómo yo estaba repartiendo el trabajo. Porque el problema real era que no había nadie señalando.

Así que empecé a repartir el trabajo. Un agente escribe, otro distinto revisa, y un tercero —o yo mismo— decide si aquello sale o no sale. Es la misma lógica con la que funciona cualquier empresa: la persona que redacta el informe no es la única que lo firma. Tampoco es un tema de desconfianza; un segundo par de ojos ve cosas que el autor, a esas alturas, ya no puede ver. Desde que existe el paso de revisión, cosas que antes pasaban de largo se quedan atrapadas ahí. Muchas resultan ser falsas alarmas. De vez en cuando, una es un error de verdad que habría salido publicado tal cual, y supongo que eso solo ya justifica el paso extra.

Ahora mismo son unas nueve funciones separadas, cada una con su trozo pequeño: escribir, revisar, aprobar, y alguna más específica que eso. Digo "unas" porque esto no es un organigrama limpio. Hay dos funciones que acaban cubriendo el mismo terreno y pisándose. Ha pasado que el revisor deja pasar algo porque la propia revisión se hizo con prisas, que es exactamente el fallo que todo este montaje pretendía evitar, solo que un piso más arriba. Sigo moviendo las líneas entre las funciones, y me da que voy a seguir así una buena temporada.

A todo esto lo llamo Structure Log: varias IA organizadas como si fueran una empresa diminuta, y el registro de cómo va la cosa, publicado tal cual. No es un tutorial. Se parece más a las notas que me dejaría a mí mismo para no olvidar cómo estaba montado todo, con la diferencia de que cualquiera puede leerlas. ¿Y por qué publicarlo en lugar de arreglarlo en privado y ya está? Porque los fallos enseñan más que la versión terminada. De un "y entonces funcionó" no se aprende gran cosa; lo útil es qué se rompió y qué cambié después, incluida la pinta que tenía el resultado equivocado. Como estos fallos no avisan mientras ocurren, esto se escribe después, mirando atrás, cuando algo aguas abajo ya se torció o una cuenta no salió. Habrá entradas más toscas que un artículo terminado; he decidido que no pasa nada.

Eso es el montaje. Lo que viene a partir de aquí es lo que vaya pasando de verdad. Y si tú trabajas con una sola IA y todo parece ir sobre ruedas, igual vale la pena preguntarse quién te está señalando los errores.

タイキ(Taiki)

タイキ(Taiki)

Un registro de implementación de la organización de agentes de IA

← cd ..