Qué no esperar de este blog
En el capítulo anterior escribí sobre lo que sí puedes encontrar aquí: registros del proceso sin pulir, fallos que no se ocultan, ideas que puedes tomar en parte y llevar a tu propio contexto. Lo puse por escrito con honestidad.
Este capítulo es el lado opuesto.
Qué no obtendrás y dónde están los límites. Podría parecer que, si lo digo desde el principio, no habrá razón para seguir leyendo. Por eso lo coloqué después del capítulo anterior, no antes. Pero no incluirlo me parecía injusto. Decidí que es más fácil recibir esta información una vez que ya tienes una idea de lo que sí ofrece el blog.
No encontrarás recetas de aplicación inmediata
Esto es lo que más quiero dejar claro.
No aparecerá aquí algo del estilo «5 pasos para empezar a usar esto desde mañana». Puedo documentar el proceso de diseñar un sistema con múltiples agentes de IA trabajando juntos, pero ese sistema aún no está en un estado en el que pueda decir «haz esto y lo reproducirás».
Por ejemplo: cuando probé un mecanismo para que un agente de IA verificara el trabajo de otro agente de IA, pensé en la fase de diseño que la consistencia estaba garantizada. Pero al ponerlo en marcha, el agente que debía verificar empezó a interpretar las instrucciones de forma distinta a lo previsto, y el sistema no funcionó como se esperaba. Eso lo documentaré tal cual. Por qué ocurrió, cómo lo corregí después, qué problemas siguen sin resolverse tras la corrección. Estoy en la fase de acumular ese tipo de registros.
Puedes leer estos registros en curso y llevarte la parte que te sirva para tu situación. Pero si lo que buscas es una receta terminada que funcione directamente en tu entorno, este blog probablemente no se ajusta a lo que esperas.
No repartiré plantillas listas para copiar y pegar
Es una idea que ya apareció en la sección anterior, pero voy un paso más allá: la política es no publicar nada del estilo «copia este archivo, configúralo y funciona».
Hay dos razones. La primera es que el funcionamiento varía mucho según el entorno. Incluso con la misma filosofía de diseño, el diseño necesario cambia según las versiones de las herramientas que uses, el tamaño del equipo o qué quieres automatizar. No está suficientemente generalizado como para decir «usa esto directamente».
La segunda es que entregar solo una plantilla sin la lógica detrás genera problemas para quien la usa. Por ejemplo, cuando construyes un mecanismo para que un agente de IA verifique algo, si no tienes claro de antemano qué confías y qué pones en duda, el sistema puede parecer que «verifica» en apariencia pero estar vacío por dentro. Dar solo la plantilla sin transmitir el razonamiento que la sostiene facilita que ocurra exactamente eso. Llevarte el modo de pensar mientras lees los registros es, a largo plazo, más útil.
No habrá explicaciones de herramientas ni información de últimas novedades
No escribiré artículos que enseñen paso a paso cómo usar una herramienta concreta. Tampoco trataré qué funciones tiene tal herramienta o qué se ha añadido recientemente.
Las herramientas relacionadas con IA cambian rápido. Si escribo procedimientos de uso, quedan obsoletos en pocos meses. En cambio, documentar «por qué el diseño está pensado así» deja algo que permanece incluso cuando las herramientas cambian. A eso me limito.
Puede que el nombre de alguna herramienta aparezca en los registros. Pero es solo contexto para entender la situación, no un artículo de explicación sobre esa herramienta.
No revelaré quién hay detrás
Por último, esto también lo dejo escrito.
No aparecerá información personal sobre quién escribe este blog. Ni nombre, ni cara, ni trayectoria. El nombre Structure Log se usa como la identidad del blog no solo para mantener la privacidad, sino también porque prefiero que lo leas como un registro de «qué se diseñó y qué ocurrió», no como «quién lo escribió».
No hace falta juzgar si «esta persona es increíble, así que me fío» o «es un aficionado, no sirve de referencia». Es suficiente con que tomes el contenido de los registros, lo compares con tu situación y decidas si te resulta útil.
No saber quién hay detrás no debería ser un obstáculo para leer.
Lee sabiendo dónde están los límites
He descrito cuatro cosas que no obtendrás.
No hay recetas de efecto inmediato. No se reparten plantillas para copiar y pegar. No hay tutoriales de herramientas ni actualizaciones de novedades. Y no sabrás quién está detrás.
Al leerlo así junto, quizás alguien piense «¿y para qué leer esto entonces?». Pero la razón por la que publico este tipo de registros es que observar un proceso de diseño en curso tiene un valor distinto al de recibir algo terminado. Que haya fallos, que todavía esté a medias —eso puede conectar con la sensación de «quizás yo también podría intentarlo». Al menos, eso es lo que intento: crear ese punto de contacto con ese tipo de lector.
Si lees sabiendo dónde están los límites, creo que lo que sí puedes obtener también lo recibirás de una forma más directa.
A partir del siguiente capítulo, entro en los registros concretos: qué diseños probé y cómo resultaron.