Durante Clojure South, Marlon Silva, Ingeniero de Software Senior en Nubank, compartió su perspectiva sobre un desafío recurrente para los ingenieros que trabajan con IA hoy en día: cómo ir más allá del uso de asistentes de IA y comenzar a desarrollar agentes de IA confiables y orientados a tareas.

Según Marlon, la industria ha facilitado cada vez más el consumo de IA (las API, los copilotos y los asistentes están en todas partes), pero construir sistemas potenciados por IA todavía requiere que los ingenieros tomen una serie de decisiones de bajo nivel que a menudo resultan incómodas. En su charla, se enfocó en desmitificar esas decisiones, planteando la IA no como una ″caja negra″, sino como infraestructura e integraciones sobre las cuales se debe razonar explícitamente.

En lugar de presentar un nuevo framework o una capa de abstracción, Marlon recorrió las elecciones arquitectónicas que considera más importantes al construir agentes en la práctica, y explicó por qué Clojure ofrece una base particularmente sólida para explorar este espacio.

La infraestructura primero: el lugar donde residen tus modelos importa

Marlon comenzó argumentando que cualquier iniciativa seria de IA empieza con la infraestructura; específicamente, con la forma en que los equipos acceden a los modelos. Aunque esta decisión suele tratarse como un detalle de implementación, enfatizó que impacta directamente en la escalabilidad, la experimentación, la seguridad y la integración con los sistemas existentes.

Desde su perspectiva, los ingenieros suelen enfrentarse a dos opciones:

  • Proveedores directos de IA: Marlon señaló que estos proveedores son un excelente punto de entrada para desarrolladores individuales. Registrarse es sencillo, las API están bien documentadas y es posible empezar a experimentar casi de inmediato. Para el aprendizaje y la exploración temprana, este camino minimiza la fricción.
  • Proveedores de nube: Sin embargo, para las organizaciones, Marlon argumentó que aprovechar las relaciones existentes con la nube suele ser la mejor decisión a largo plazo. La mayoría de las empresas ya tienen cuentas, facturación, controles de seguridad y observabilidad implementados. Proveedores de nube como AWS y GCP permiten acceder a modelos de múltiples laboratorios de IA sin introducir nuevos proveedores en el ecosistema técnico (stack).

Según Marlon, cuando los equipos operan dentro de una organización, lo más pragmático es usar los modelos que ya están disponibles a través de sus proveedores de nube. Esto elimina la carga administrativa de adquisición (procurement) y permite que los ingenieros se concentren en construir sistemas en lugar de gestionar proveedores.

Descubre las oportunidades

El problema de la fragmentación: demasiadas API

Una vez establecido el acceso a los modelos, Marlon señaló un segundo problema inevitable: la fragmentación de las API. Cada proveedor expone diferentes formatos de solicitud, parámetros y SDK, lo que complica rápidamente el desarrollo y encarece la experimentación.

En su charla, Marlon describió esta fragmentación como uno de los primeros puntos de dolor en el escalamiento que encuentran los equipos cuando la IA va más allá de un simple script o una prueba de concepto.

Para abordar esto, presentó a LiteLLM como una capa de unificación práctica. LiteLLM es un proxy que estandariza el acceso a múltiples modelos y proveedores bajo una sola API, independientemente de dónde esté alojado el modelo.

Marlon destacó tres beneficios concretos de este enfoque:

  • Una interfaz unificada: que permite a los equipos cambiar de modelo sin tener que reescribir el código de integración.
  • Observabilidad centralizada: creando un punto único para el registro (logging), la depuración (debugging) y la auditoría de las interacciones con los modelos.
  • Control de costos: un punto que enfatizó como crítico. El consumo de tokens escala rápidamente en producción, y LiteLLM permite a las organizaciones rastrear y limitar el uso por equipo, servicio o clave.

Desde la perspectiva de Marlon, este tipo de proxy no es una optimización: se convierte en infraestructura fundamental tan pronto como la IA forma parte de un sistema real.

Por qué los modelos más pequeños suelen funcionar mejor para los agentes

Marlon desafió luego una suposición común en el ámbito de la IA: que los modelos más grandes siempre son mejores.

Para los agentes de IA orientados a tareas, argumentó que esto rara vez es cierto. Citando investigaciones recientes de Nvidia, Marlon explicó que los Modelos de Lenguaje Pequeños (SLM, por sus siglas en inglés) suelen adaptarse mejor a agentes diseñados para ejecutar acciones específicas y bien definidas.

Según él, las amplias capacidades de generalización de los grandes LLM —modelos capaces de escribir ensayos o prosa extensa— son innecesarias para la mayoría de las cargas de trabajo de los agentes. Usarlos en estos contextos genera un desperdicio de capacidad, costos más altos y una mayor complejidad.

Marlon detalló varias ventajas prácticas de los SLM:

  • Eficiencia de costos: modelos como Llama 4 Scout en AWS Bedrock cuestan órdenes de magnitud menos por token que los grandes modelos propietarios.
  • Menor consumo de energía: lo que los convierte en una opción más responsable a escala y más ecológica.
  • Ajuste fino (fine-tuning) viable: adaptar un modelo de entre 7 y 10 mil millones de parámetros a un dominio específico es algo realista, mientras que hacer lo mismo con modelos extremadamente grandes a menudo no lo es para la mayoría de las empresas.

Para Marlon, elegir SLM no es un sacrificio, sino una decisión de ingeniería alineada con los requisitos reales de los sistemas basados en agentes.

Por qué Clojure encaja en este espacio de problemas

A partir de ahí, Marlon cambió el enfoque hacia las herramientas. Explicó que el desarrollo de IA es inherentemente experimental: los prompts cambian, los parámetros se ajustan, los modelos se intercambian y las suposiciones se ponen a prueba constantemente. En ese contexto, los ciclos de retroalimentación (feedback loops) del desarrollador son fundamentales. Aquí es donde Clojure destaca.

Marlon describió a Clojure como un lenguaje ergonómico, no solo por su sintaxis, sino por su modelo de desarrollo impulsado por el REPL. La capacidad de evaluar funciones de forma incremental, inspeccionar resultados de inmediato e iterar sin reiniciar la aplicación cambia fundamentalmente la forma en que los ingenieros exploran los espacios de problemas.

En su experiencia, este flujo de trabajo interactivo se alinea estrechamente con la forma en que se construyen y perfeccionan los sistemas de IA. Más allá del REPL, Marlon destacó dos ventajas de interoperabilidad:

  • Interoperabilidad con Java: Dado que Clojure se ejecuta en la JVM, tiene acceso fluido al ecosistema de Java. Los SDK de la nube, clientes HTTP, herramientas de observabilidad y bibliotecas maduras están disponibles de inmediato.
  • Interoperabilidad con Python: Con bibliotecas como libpython-clj, Clojure puede importar y ejecutar código Python directamente. Aunque no es tan fluido como la integración con Java, esta capacidad permite a los ingenieros reutilizar herramientas de IA basadas en Python sin abandonar el flujo de trabajo interactivo de Clojure.

Para Marlon, esta combinación convierte a Clojure en una capa de orquestación robusta para sistemas de IA que necesitan integrarse con múltiples ecosistemas.

De la teoría a la práctica: la demostración en vivo

Para concretar estas ideas, Marlon realizó una demostración en vivo. Comenzó con scripts sencillos en Python que enviaban texto, imágenes y archivos PDF a modelos alojados en Bedrock a través de un proxy local de LiteLLM. Estos ejemplos establecieron una base utilizando herramientas familiares.

Luego, reprodujo los mismos flujos de trabajo en Clojure, importando el paquete de Python LiteLLM directamente en el entorno de ejecución (runtime) de Clojure. Las funciones de Python se llamaban desde el código de Clojure, gestionando las entradas y salidas de forma interactiva.

Según Marlon, la parte más importante de la demostración no fue que este enfoque funcione, sino cómo cambia la experiencia de desarrollo. Los flujos de trabajo basados en Python suelen requerir cambios de contexto frecuentes: editar archivos, ejecutar scripts y reiniciar procesos. Con Clojure y el REPL, todo el ciclo de retroalimentación permanece dentro del editor.

Para dominios exploratorios como la IA, Marlon argumentó que esta diferencia se traduce directamente en una iteración más rápida y un enfoque más profundo.

Conclusión

Marlon cerró enfatizando que los agentes de IA siguen siendo un campo joven y en rápida evolución. Las bibliotecas, arquitecturas y mejores prácticas aún están cambiando, lo que hace que la flexibilidad sea un requisito clave.

También ofreció una nota de advertencia: otorgar a los modelos una autonomía excesiva sin límites y controles claros puede dar lugar a sistemas frágiles. En su opinión, los frameworks que favorecen un flujo de control oscuro y dependen principalmente del propio LLM fomentan un enfoque de ″lanzar y rezar″ (ship and pray) en el desarrollo de IA. Al mismo tiempo, Marlon señaló que están surgiendo activamente nuevas arquitecturas de agentes desde grupos de investigación en organizaciones como Nvidia y DeepMind, lo que indica que aún quedan cambios significativos por delante.

Su conclusión fue pragmática: combinar una infraestructura bien elegida, modelos dimensionados para el problema y herramientas que favorezcan la exploración crea una base sólida para construir sistemas de IA fundamentados en la disciplina de la ingeniería. El repositorio compartido durante la charla sirve como punto de partida para los ingenieros interesados en continuar con esa exploración.

Small Language Models are the Future of Agentic AI

AlphaEvolve: A coding agent for scientific and algorithmic discovery

GitHub – marlonjsilva/clj-agents

GitHub – clj-python/libpython-clj

Descubre las oportunidades