Hoy he tenido el privilegio de estar un par de horas en las oficinas de Tinybird escuchando al equipo de app.build y Tinybird hablar de cómo han integrado LLMs en sus productos. En el artículo de hoy veremos algunos puntos interesantes que he sacado de ambas charlas.

Mi enfoque a estos modelos sigue siendo a nivel usuario, pero la sesión de hoy me ha permitido entender un poco más la magia que hay tras herramientas como Copilot, Q, Cline, Claude Code … o Kiro.

Al final… es una máquina de estados

Una de las primeras cosas que he aprendido en esta sesión es que la complejidad de estos sistemas se parece menos a de un wrapper de una llamada a ChatGPT, Claude, Gemini, o Llama, y más a la máquina de estados de una máquina de vending que programé durante la carrera.

En ambos ejemplos, el usuario habla con una interfaz, pero bajo el capó esta petición pasa por múltiples estados. En dichos estados podemos tener operaciones como.

• Validación de entrada y petición de información adicional
• Generación y validación de plan de ejecución.
• Ejecución del plan, validación y recuperación.

Es un juego de optimización donde en cada estado se balancea la cantidad de información que se envía al modelo, que tipo de modelo se usa y cuantas veces se evalúa. Veamos con detalle estos tres tipos de operaciones:

Validando la entrada

Los modelos de lenguaje son sorprendentemente buenos a la hora de dar forma a texto muy ambiguo, pero es un proceso que consume recursos. Una de las maneras de repartir recursos que mostraron es emplear un modelo más rápido y barato como Google Gemini Flash para este tipo de operaciones, ya que no requieren razonamiento y dan una respuesta instantánea.

Para validar la entrada mencionaron cómo usaban al modelo para hacer preguntas sobre el prompt pasado por el usuario, asegurando tener todo lo necesario, o de lo contrario, responder con una pregunta para que proporcionara más información. Esto lo he visto en funcionamiento en Claude Desktop cuando le pido que investigue sobre un concepto pero necesita más información para empezar el proceso.

Generando un plan de ejecución

Con la entrada del usuario «limpia», el siguiente tema fue establecer contexto y un plan de ejecución. Una clave clave, mencionaban, era dar contexto suficiente como para que el modelo sepa por donde empezar pero darle espacio para explorar, ya que una de las limitaciones de los modelos actuales es que demasiado contexto degrada el modelo.

Una manera de darle espacio para explorar era guiar al modelo con reglas, que es una manera de permitir que descubra el contexto por sí mismo, es un concepto que hemos visto sobre todo en agentes, y del que espero hablar pronto.

Otra manera de asegurarse que el modelo no se diluye era poder tener múltiples modelos especializados en un área concreta, con un subconjunto del contexto, y que se pudieran ejecutar con el mayor paralelismo posible.

Como parte de la generación del plan, explicaron además una primera combinación de determinismo con no-determinismo, y era el uso de use-tool, una manera de ejecutar comandos locales desde el modelo y leer el resultado que es mucho más sencilla y rápida que usar un MCP (Model Context Protocol, una API más compleja basada en servicios para modelos de lenguaje)

Esto permitía, por ejemplo, ejecutar una primera y rápida validación de los comandos a ejecutar (si has generado código SQL, puedes querer validarlo como parte de la generación del plan de ejecución). Para sacar el mayor partido a este paradigma, recomendaban que la respuesta fuera muy clara y descriptiva, especialmente con códigos de error que se pudieran interpretar por parte del modelo.

Finalmente, aunque los modelos han evolucionado mucho en los últimos 2 años, tener un plan de ejecución claro y parcialmente estructurado (He visto cómo están volviendo los tags de XML para organizar secciones) permite una ejecución más eficiente.

Ejecución del plan, validación y recuperación

A la hora de ejecutar el plan lo que más me llamó la atención es cómo se combinaban determinismo y no-determinismo. Por una parte en app.build ejecutan el mismo plan varias veces de manera paralela y en múltiples ramas. El ejemplo que daban era el siguiente:

Para generar una API en backend, se ejecutaba el mismo plan múltiples veces de manera concurrente y la ejecución que tuviera todos los tests en verde «ganaba». Dentro de cada ejecución, cada vez que los tests fallaban, se iniciaba otra ejecución concurrente de esa rama, y así hasta un número determinado.

El uso de paralelización y de decisiones deterministas (si este proceso falla ejecutarlo un número finito de veces) tiene un coste, ya que se generan caminos que se descartan, pero, según comentaban, daba como resultado un código mucho mejor que el que se generaba solo con una ejecución singular.

Por otra parte, en Tinybird tenían un modelo determinista de recuperación ante errores, eso les permitía evitar que el modelo divagara. Veamos el ejemplo:

Si una llamada al servicio da como resultado que las entradas están en cuarentena, el modelo tendría que ir a la documentación, ver cómo sacar las entradas de la cuarentena, ver qué hacer con las entradas e interpretar cómo han acabado allí.

En vez de eso, lo que hicieron fue que si el resultado es cuarentena, se extraen los datos de la tabla de cuarentena, se injectan esos datos en el modelo y se le instruye para que procese esas entradas.

Esta combinación de determinismo y no-determinismo, que también se puede extender a áreas como seguridad (los permisos de acceso a los datos se gestionan en la capa determinista de la aplicación mediante un token de autenticación).

Conclusiones

Me he dejado cosas en el tintero como caching, evals para comparar la respuesta de los modelos o herramientas como Playwright para probar interfaces. Sin embargo, estas tres ideas de validación, generación y ejecución, resuenan con temas de los que hemos hablado anteriormente, como el modelo Plan/Act que vimos en al Parte 3 de la serie.

una vez más ha sido un privilegio estar en la sala y escuchar la experiencia de la gente que está usando estos modelos no solo como usuarios, sino como parte de los productos que construyen.