Tras una breve pausa en verano vuelvo a la carga con mi serie de IA y LLMs. En el artículo de hoy hablaremos sobre cómo perder totalmente la concentración cuando es otro «quien teclea» y algunas ideas que estoy poniendo en práctica para no perder el foco.

El día que todo se fue al traste

Llevo utilizando agentes (especialmente Cline) de manera profesional y casi a diario desde mayo de este año, y comenté mis experiencias en el primer artículo de la serie. Todos los días son diferentes en estas herramientas, pero recuerdo uno que fue particularmente importante.

Un día que, en mi afán por conseguir completar más tareas, decidí abrir varias instancias de Cline y Visual Studio en paralelo y ejecutar varias tareas a la vez en proyectos diferentes. El resultado fue desastroso: Toda la productividad ganada con los agentes se perdían en mi constante cambio de contexto, la falta de concentración hacían que perdiera mucho tiempo corrigiendo los diferentes caminos y eso dio como resultado que acabara el día completamente agotado y sin tener una sensación de progreso. En resumen, como decían en Parque Jurásico: …estaban tan preocupados con si podían o no que no se detuvieron a pensar si debían.

Análisis en frío

En este punto pasaron varias cosas. La primera es la constatación de que, al menos yo, soy terrible haciendo multi-tarea. En general el cambio de contexto, especialmente en contextos de problemas o de tareas que requieren concentración, nos hace poco eficientes y nos agota. Aunque no seamos conscientes, seguimos pensando en el problema o el contexto anterior en lo que se denomina la atención residual.

La segunda, y relacionada con la primera, es que perdí tanto tiempo y energía en estar cambiando de contexto que no me concentré lo suficiente en los problemas reales que quería solucionar. No estar concentrados en la era de los LLMs es peligroso, es más fácil equivocarnos interactuando con el LLM, es más fácil ignorar bugs visibles y caer en un hilo interminable que un compañero ha denominado «Death Loop», en el que le sigues pidiendo al LLM que corrija sus errores cual jugador en una máquina tragaperras.

Flow

El estado de «Flow» lo definió Mihály Csíkszentmihályi de esta manera:

el hecho de sentirse completamente comprometido con la actividad por sí misma. El ego desaparece. El tiempo vuela. Toda acción, movimiento o pensamiento surgen inevitablemente de la acción, del movimiento y del pensamiento previos, […]. Todo tu ser está allí, y estás aplicando tus facultades al máximo.

Lo que buscamos es conseguir el efecto deseado, estar trabajando de manera centrada en un problema que nos resulte suficientemente difícil. La pregunta es, si podemos hacerlo cuando escribimos código, ¿cómo conseguir ese estado cuando no estamos guiando el resultado de manera indirecta?

La respuesta está implícita en la pregunta, y es que nuestra concentración necesita moverse a guiar el resultado, más allá de dejar a la máquina trabajar por sí sola, para maximizar nuestra efectividad.

Estrategias para maximizar el flow

Ventana partida

Una idea con la que he estado experimentando es la de ventana partida. Usando herramientas como Rectangle para Mac y aprendiendo los atajos de teclado, puedo tener el agente ejecutando de un lado, y del otro de la pantalla una herramienta como Obsidian en la que voy definiendo las siguientes tareas, así como la siguiente petición que le voy a hacer al agente.

Esto me permite mantener mi memoria de trabajo centrada en el problema actual o en variantes del mismo, mantener un registro de los pasos que voy dando y cuando vienen las distracciones (que siempre vienen, tanto internas como externas) poder volver a recuperar la concentración.

Ejemplo: Estoy trabajando en una aplicación de gestión de tareas, si estoy en este paso: Agregar categorías a las tareas, Mi lista de pasos siguientes va a tener:

• Agregar tests a las categorías
• Definir tamaño máximo
• Agregar búsqueda por categoría.

Parar y leer

Otra idea que estoy usando para reducir la cantidad de veces en las que caigo en un «Dead Loop» es parar frecuentemente y leer en detalle el código que ha generado el LLM. Reconozco que más de una vez cuando estoy haciendo pequeñas utilidades o scripts efímeros, me quedo con tener algo que funciona.

Cuando estamos escribiendo código de producción, o código que vayamos a mantener posteriormente, una ventaja de parar y leer con detalle es que podemos notar cuando el LLM está agregando complejidad adicional, y nos da la oportunidad de simplificar antes de que el código crezca sin control. Los LLMs son maximalistas, con lo cual el código que escriben es extensivo, muchas veces cubriendo casos de uso que no tengamos en mente en un principio y que no necesitemos cubrir.

Ejemplo: Siguiendo el paso anterior de Agregar categorías a la tarea, el siguiente paso va a ser comprobar que las categorías no están generando complejidad adicional, que el modelo de datos es simple, y si no la siguiente tarea se convierte en algo del estilo Agregar categoría como una propiedad de la tarea en vez de una lista

Divide y vencerás

La manera que he encontrado más eficiente de trabajar con LLMs es la misma que se puede usar para delegar en otras personas o para abordar un problema relativamente grande, que es dividirlo en unidades de ejecución independientes.

Curiosamente, podemos usar los LLMs para, dada una tarea a alto nivel, sugerir maneras de ejecutar de manera independiente, y luego podemos guiar al agente combinando tareas o dividiéndolas más aún en base a nuestro criterio.

El uso de unidades de ejecución pequeñas reduce riesgos de alucinaciones, y nos permite seguir llevando un registro sostenible del progreso.

Ejemplo: Siguiendo el paso anterior de Agregar categorías a la tarea, podemos convertirlo en una serie de pasos más detallados, como:

• Definir modelo de datos de categoría con tamaño máximo
• Crear categorías de manera separada
• Asignar categorías a tareas existentes
• Crear categorias al crear tareas.

Autonomía planificada

No todas las tareas requieren nuestra supervisión, en ocasiones queremos que el agente revise una base de código y nos proporcione artefactos como Diagramas, Explicaciones o Sugerencias.

En este caso, crear un documento en Markdown que defina nuestro objetivo, instrucciones y formato del resultado nos puede ayudar a delegar este tipo de tareas y, una vez terminada la investigación, podemos revisar los resultados.

Para este tipo de tareas suelo especificar que el análisis sea sencillo, y que cite las fuentes (los ficheros de código) que le han llevado a tomar dichas conclusiones. Este análisis requiere una parte importante de pausa y reflexión, eso nos permite comprobar la información y reaccionar en caso de que las conclusiones no sean correctas.

Ejemplo: Suponiendo que estamos haciendo el análisis de un sistema existente, nuestro prompt puede incluir los siguientes mensajes:

- Crear un diagrama de dependencias a nivel de clases del sistema de tareas.
- Las dependencias externas (que el codigo fuente no esté en el repositorio) han de estar en otro color. 
- Crear una definición en una línea para cada clase.
- Enlazar rutas completas de achivo
- Listar los tipos de datos que maneja el sistema, donde se leen y donde se almacenan

Pese a su utilidad, no debemos olvidar de leer estos anális con escepticismo, parar, leer y comprobar antes de dar por buenas las conclusiones.

Conclusiones

El ecosistema de agentes basados en LLM cambia constantemente y es posible que dentro de unos meses estemos trabajando de maneras completamente diferentes y que los agentes tengan una autonomía que nos permita orquestar y paralelizar el trabajo.

Hasta entonces, seguimos siendo el cuello de botella de estos sistemas, y ser consciente de ello nos puede hacer más eficientes, usando estas herramientas para mantener el foco en vez de para perderlo. del todo.