Durante o Clojure South, Marlon Silva, Engenheiro de Software Sênior no Nubank, compartilhou sua perspectiva sobre um desafio recorrente para os engenheiros de software que trabalham com IA hoje: como ir além do uso de assistentes de IA e começar a projetar agentes de IA confiáveis e orientados a tarefas.

Segundo Marlon, a indústria tornou cada vez mais fácil consumir IA — APIs, copilots e assistentes estão em toda parte —, mas construir sistemas baseados em IA ainda exige que os engenheiros tomem uma série de decisões de baixo nível, muitas vezes desconfortáveis. Em sua palestra, ele focou em desmistificar essas decisões, tratando a IA não como uma ‘caixa preta’, mas como infraestrutura e integração que precisam ser analisadas de forma explícita.

Em vez de apresentar um novo framework ou camada de abstração, Marlon percorreu as escolhas arquitetônicas que ele acredita serem as mais importantes ao construir agentes na prática, e explicou por que o Clojure oferece uma base particularmente sólida para explorar esse espaço.

Infraestrutura em primeiro lugar: onde seus modelos residem é importante

Marlon começou argumentando que qualquer iniciativa séria de IA começa com a infraestrutura — especificamente, como as equipes acessam os modelos. Embora essa decisão seja frequentemente tratada como um detalhe de implementação, ele enfatizou que ela impacta diretamente a escalabilidade, a experimentação, a segurança e a integração com sistemas existentes.

Do seu ponto de vista, os engenheiros geralmente enfrentam duas opções:

  • Provedores diretos de IA (Vendors): Marlon observou que esses provedores são um excelente ponto de entrada para desenvolvedores individuais. O cadastro é simples, as APIs são bem documentadas e é possível começar a experimentar quase imediatamente. Para aprendizado e exploração inicial, esse caminho minimiza a fricção.
  • Provedores de Nuvem (Cloud Providers): Para organizações, no entanto, Marlon argumentou que aproveitar os relacionamentos de nuvem já existentes costuma ser a melhor decisão a longo prazo. A maioria das empresas já possui contas, faturamento, controles de segurança e observabilidade implementados. Provedores de nuvem como AWS e GCP tornam possível acessar modelos de múltiplos laboratórios de IA sem introduzir novos fornecedores à infraestrutura tecnológica (stack).

De acordo com Marlon, quando as equipes estão operando dentro de uma organização, o padrão mais pragmático é usar os modelos já disponíveis por meio de seus provedores de nuvem. Isso elimina a sobrecarga de contratação (procurement) e permite que os engenheiros foquem na construção de sistemas em vez de gerenciar fornecedores.

Conheça nossas oportunidades

O problema da fragmentação: APIs em excesso

Uma vez estabelecido o acesso aos modelos, Marlon apontou um segundo problema inevitável: a fragmentação das APIs. Cada provedor expõe formatos de requisição, parâmetros e SDKs diferentes, o que complica rapidamente o desenvolvimento e torna a experimentação dispendiosa.

Em sua palestra, Marlon descreveu essa fragmentação como um dos primeiros “pontos de dor” (pain points) de escalabilidade que as equipes encontram quando a IA vai além de um simples script ou prova de conceito.

Para resolver isso, ele apresentou o LiteLLM como uma camada de unificação prática. O LiteLLM é um proxy que padroniza o acesso a múltiplos modelos e provedores sob uma única API, independentemente de onde o modelo esteja hospedado.

Marlon destacou três benefícios concretos dessa abordagem:

  • Uma interface unificada: permitindo que as equipes troquem de modelos sem precisar reescrever o código de integração.
  • Observabilidade centralizada: criando um ponto único para logging, depuração e auditoria das interações com os modelos.
  • Controle de custos: que ele enfatizou ser crítico. O uso de tokens escala rapidamente em produção, e o LiteLLM permite que as organizações monitorem e limitem o uso por equipe, serviço ou chave.

Do ponto de vista de Marlon, esse tipo de proxy não é uma otimização: ele se torna infraestrutura fundamental assim que a IA passa a fazer parte de um sistema real.

Por que modelos menores costumam funcionar melhor para agentes

Marlon então desafiou uma suposição comum no espaço da IA: a de que modelos maiores são sempre melhores.

Para agentes de IA orientados a tarefas, ele argumentou que isso raramente é verdade. Citando pesquisas recentes da Nvidia, Marlon explicou que os Modelos de Linguagem Pequenos (SLMs – Small Language Models) costumam ser uma escolha melhor para agentes projetados para executar ações específicas e bem definidas.

Segundo ele, as amplas capacidades de generalização dos grandes LLMs — modelos capazes de escrever ensaios ou prosas longas — são desnecessárias para a maioria das cargas de trabalho de um agente. Usá-los nesses contextos leva a desperdício de capacidade, custos mais altos e aumento de complexidade.

Ele destacou diversas vantagens práticas dos SLMs:

  • Eficiência de custos: modelos como o Llama 4 Scout no AWS Bedrock custam ordens de magnitude a menos por token do que os grandes modelos proprietários.
  • Menor consumo de energia: tornando-os uma escolha mais responsável em escala e mais ecológica.
  • Ajuste fino (Fine-tuning) viável: adaptar um modelo de 7 a 10 bilhões de parâmetros para um domínio específico é algo realista, enquanto fazer o mesmo com modelos gigantescos muitas vezes não é viável para a maioria das empresas.

Para Marlon, escolher SLMs não é uma concessão, mas sim uma decisão de engenharia alinhada aos requisitos reais de sistemas baseados em agentes.

Por que o Clojure se encaixa nesse espaço de problema

A partir daí, Marlon mudou o foco para o ferramental. Ele explicou que o desenvolvimento de IA é inerentemente experimental: prompts mudam, parâmetros são ajustados, modelos são trocados e suposições são testadas constantemente. Nesse contexto, os ciclos de feedback do desenvolvedor são fundamentais. É aqui que o Clojure se destaca.

Marlon descreveu o Clojure como uma linguagem ergonômica — não apenas pela sintaxe, mas pelo seu modelo de desenvolvimento orientado ao REPL. A capacidade de avaliar funções de forma incremental, inspecionar resultados imediatamente e iterar sem reiniciar a aplicação muda fundamentalmente a forma como os engenheiros exploram os problemas.

Em sua experiência, esse fluxo de trabalho interativo se alinha perfeitamente com a maneira como os sistemas de IA são construídos e refinados. Além do REPL, Marlon destacou duas vantagens de interoperabilidade:

  • Interoperabilidade com Java: Como o Clojure roda na JVM, ele tem acesso direto ao ecossistema Java. SDKs de nuvem, clientes HTTP, ferramentas de observabilidade e bibliotecas maduras estão disponíveis de imediato.
  • Interoperabilidade com Python: Com bibliotecas como a libpython-clj, o Clojure pode importar e executar código Python diretamente. Embora não seja tão fluido quanto a integração com Java, essa capacidade permite que os engenheiros reutilizem ferramentas de IA baseadas em Python sem abandonar o fluxo interativo do Clojure.

Para Marlon, essa combinação torna o Clojure uma camada de orquestração robusta para sistemas de IA que precisam se integrar a múltiplos ecossistemas.

Da teoria à prática: a demonstração ao vivo

Para concretizar essas ideias, Marlon realizou uma demonstração ao vivo. Ele começou com scripts simples em Python que enviavam texto, imagens e PDFs para modelos hospedados no Bedrock via um proxy local LiteLLM. Esses exemplos estabeleceram uma base usando ferramentas familiares.

Em seguida, ele reproduziu os mesmos fluxos em Clojure, importando o pacote Python LiteLLM diretamente no tempo de execução (runtime) do Clojure. As funções Python foram chamadas a partir do código Clojure, com entradas e saídas manipuladas de forma interativa.

Segundo Marlon, a parte mais importante da demonstração não foi o fato de essa abordagem funcionar, mas como ela muda a experiência de desenvolvimento. Fluxos de trabalho baseados em Python geralmente exigem trocas frequentes de contexto — editar arquivos, rodar scripts e reiniciar processos. Com o Clojure e o REPL, todo o ciclo de feedback permanece dentro do editor. Para domínios exploratórios como a IA, Marlon argumentou que essa diferença se traduz diretamente em interações mais rápidas e maior foco.

Conclusão

Marlon encerrou enfatizando que os agentes de IA ainda são um campo jovem e em rápida evolução. Bibliotecas, arquiteturas e boas práticas ainda estão mudando, o que torna a flexibilidade um requisito essencial.

Ele também deixou um alerta: conceder autonomia excessiva aos modelos sem limites e controles claros pode levar a sistemas frágeis. Em sua visão, frameworks que privilegiam fluxos de controle obscuros e dependem majoritariamente do próprio LLM incentivam uma abordagem de desenvolvimento do tipo “lançar e rezar” (ship and pray). Ao mesmo tempo, Marlon apontou que novas arquiteturas de agentes estão surgindo ativamente de grupos de pesquisa em organizações como Nvidia e DeepMind, sinalizando que mudanças significativas ainda estão por vir.

Sua conclusão foi pragmática: combinar uma infraestrutura bem escolhida, modelos dimensionados para o problema e ferramentas que favoreçam a exploração cria uma base sólida para construir sistemas de IA fundamentados na disciplina da engenharia. O repositório compartilhado durante a palestra serve como ponto de partida para engenheiros interessados em continuar essa exploração.

Referências

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

Conheça nossas oportunidades