Durante o Clojure South, Marlon Silva, Engenheiro de Software S\u00eanior no Nubank, compartilhou sua perspectiva sobre um desafio recorrente para os engenheiros de software que trabalham com IA hoje: como ir al\u00e9m do uso de assistentes de IA e come\u00e7ar a projetar agentes de IA confi\u00e1veis e orientados a tarefas.<\/p>\n\n\n\n
Segundo Marlon, a ind\u00fastria tornou cada vez mais f\u00e1cil consumir IA \u2014 APIs, copilots e assistentes est\u00e3o em toda parte \u2014, mas construir sistemas baseados em IA ainda exige que os engenheiros tomem uma s\u00e9rie de decis\u00f5es de baixo n\u00edvel, muitas vezes desconfort\u00e1veis. Em sua palestra, ele focou em desmistificar essas decis\u00f5es, tratando a IA n\u00e3o como uma ‘caixa preta’, mas como infraestrutura e integra\u00e7\u00e3o que precisam ser analisadas de forma expl\u00edcita.<\/p>\n\n\n\n
Em vez de apresentar um novo framework ou camada de abstra\u00e7\u00e3o, Marlon percorreu as escolhas arquitet\u00f4nicas que ele acredita serem as mais importantes ao construir agentes na pr\u00e1tica, e explicou por que o Clojure oferece uma base particularmente s\u00f3lida para explorar esse espa\u00e7o.<\/p>\n\n\n\n
Marlon come\u00e7ou argumentando que qualquer iniciativa s\u00e9ria de IA come\u00e7a com a infraestrutura \u2014 especificamente, como as equipes acessam os modelos. Embora essa decis\u00e3o seja frequentemente tratada como um detalhe de implementa\u00e7\u00e3o, ele enfatizou que ela impacta diretamente a escalabilidade, a experimenta\u00e7\u00e3o, a seguran\u00e7a e a integra\u00e7\u00e3o com sistemas existentes.<\/p>\n\n\n\n
Do seu ponto de vista, os engenheiros geralmente enfrentam duas op\u00e7\u00f5es:<\/p>\n\n\n\n
De acordo com Marlon, quando as equipes est\u00e3o operando dentro de uma organiza\u00e7\u00e3o, o padr\u00e3o mais pragm\u00e1tico \u00e9 usar os modelos j\u00e1 dispon\u00edveis por meio de seus provedores de nuvem. Isso elimina a sobrecarga de contrata\u00e7\u00e3o (procurement<\/em>) e permite que os engenheiros foquem na constru\u00e7\u00e3o de sistemas em vez de gerenciar fornecedores.<\/p>\n\n\n\n Uma vez estabelecido o acesso aos modelos, Marlon apontou um segundo problema inevit\u00e1vel: a fragmenta\u00e7\u00e3o das APIs. Cada provedor exp\u00f5e formatos de requisi\u00e7\u00e3o, par\u00e2metros e SDKs diferentes, o que complica rapidamente o desenvolvimento e torna a experimenta\u00e7\u00e3o dispendiosa.<\/p>\n\n\n\n Em sua palestra, Marlon descreveu essa fragmenta\u00e7\u00e3o como um dos primeiros “pontos de dor” (pain points) de escalabilidade que as equipes encontram quando a IA vai al\u00e9m de um simples script ou prova de conceito.<\/p>\n\n\n\n Para resolver isso, ele apresentou o LiteLLM como uma camada de unifica\u00e7\u00e3o pr\u00e1tica. O LiteLLM \u00e9 um proxy que padroniza o acesso a m\u00faltiplos modelos e provedores sob uma \u00fanica API, independentemente de onde o modelo esteja hospedado.<\/p>\n\n\n\n Marlon destacou tr\u00eas benef\u00edcios concretos dessa abordagem:<\/p>\n\n\n\n Do ponto de vista de Marlon, esse tipo de proxy n\u00e3o \u00e9 uma otimiza\u00e7\u00e3o: ele se torna infraestrutura fundamental assim que a IA passa a fazer parte de um sistema real.<\/p>\n\n\n\n Marlon ent\u00e3o desafiou uma suposi\u00e7\u00e3o comum no espa\u00e7o da IA: a de que modelos maiores s\u00e3o sempre melhores.<\/p>\n\n\n\n Para agentes de IA orientados a tarefas, ele argumentou que isso raramente \u00e9 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\u00e7\u00f5es espec\u00edficas e bem definidas.<\/p>\n\n\n\n Segundo ele, as amplas capacidades de generaliza\u00e7\u00e3o dos grandes LLMs \u2014 modelos capazes de escrever ensaios ou prosas longas \u2014 s\u00e3o desnecess\u00e1rias para a maioria das cargas de trabalho de um agente. Us\u00e1-los nesses contextos leva a desperd\u00edcio de capacidade, custos mais altos e aumento de complexidade.<\/p>\n\n\n\n Ele destacou diversas vantagens pr\u00e1ticas dos SLMs:<\/p>\n\n\n\n Para Marlon, escolher SLMs n\u00e3o \u00e9 uma concess\u00e3o, mas sim uma decis\u00e3o de engenharia alinhada aos requisitos reais de sistemas baseados em agentes.<\/p>\n\n\n\n A partir da\u00ed, Marlon mudou o foco para o ferramental. Ele explicou que o desenvolvimento de IA \u00e9 inerentemente experimental: prompts mudam, par\u00e2metros s\u00e3o ajustados, modelos s\u00e3o trocados e suposi\u00e7\u00f5es s\u00e3o testadas constantemente. Nesse contexto, os ciclos de feedback do desenvolvedor s\u00e3o fundamentais. \u00c9 aqui que o Clojure se destaca.<\/p>\n\n\n\n Marlon descreveu o Clojure como uma linguagem ergon\u00f4mica \u2014 n\u00e3o apenas pela sintaxe, mas pelo seu modelo de desenvolvimento orientado ao REPL. A capacidade de avaliar fun\u00e7\u00f5es de forma incremental, inspecionar resultados imediatamente e iterar sem reiniciar a aplica\u00e7\u00e3o muda fundamentalmente a forma como os engenheiros exploram os problemas.<\/p>\n\n\n\n Em sua experi\u00eancia, esse fluxo de trabalho interativo se alinha perfeitamente com a maneira como os sistemas de IA s\u00e3o constru\u00eddos e refinados. Al\u00e9m do REPL, Marlon destacou duas vantagens de interoperabilidade:<\/p>\n\n\n\n Para Marlon, essa combina\u00e7\u00e3o torna o Clojure uma camada de orquestra\u00e7\u00e3o robusta para sistemas de IA que precisam se integrar a m\u00faltiplos ecossistemas.<\/p>\n\n\n\n Para concretizar essas ideias, Marlon realizou uma demonstra\u00e7\u00e3o ao vivo. Ele come\u00e7ou 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.<\/p>\n\n\n\n Em seguida, ele reproduziu os mesmos fluxos em Clojure, importando o pacote Python LiteLLM diretamente no tempo de execu\u00e7\u00e3o (runtime) do Clojure. As fun\u00e7\u00f5es Python foram chamadas a partir do c\u00f3digo Clojure, com entradas e sa\u00eddas manipuladas de forma interativa.<\/p>\n\n\n\n Segundo Marlon, a parte mais importante da demonstra\u00e7\u00e3o n\u00e3o foi o fato de essa abordagem funcionar, mas como ela muda a experi\u00eancia de desenvolvimento. Fluxos de trabalho baseados em Python geralmente exigem trocas frequentes de contexto \u2014 editar arquivos, rodar scripts e reiniciar processos. Com o Clojure e o REPL, todo o ciclo de feedback permanece dentro do editor. Para dom\u00ednios explorat\u00f3rios como a IA, Marlon argumentou que essa diferen\u00e7a se traduz diretamente em intera\u00e7\u00f5es mais r\u00e1pidas e maior foco.<\/p>\n\n\n\n Marlon encerrou enfatizando que os agentes de IA ainda s\u00e3o um campo jovem e em r\u00e1pida evolu\u00e7\u00e3o. Bibliotecas, arquiteturas e boas pr\u00e1ticas ainda est\u00e3o mudando, o que torna a flexibilidade um requisito essencial.<\/p>\n\n\n\n Ele tamb\u00e9m deixou um alerta: conceder autonomia excessiva aos modelos sem limites e controles claros pode levar a sistemas fr\u00e1geis. Em sua vis\u00e3o, frameworks que privilegiam fluxos de controle obscuros e dependem majoritariamente do pr\u00f3prio LLM incentivam uma abordagem de desenvolvimento do tipo “lan\u00e7ar e rezar” (ship and pray). Ao mesmo tempo, Marlon apontou que novas arquiteturas de agentes est\u00e3o surgindo ativamente de grupos de pesquisa em organiza\u00e7\u00f5es como Nvidia e DeepMind, sinalizando que mudan\u00e7as significativas ainda est\u00e3o por vir.<\/p>\n\n\n\n Sua conclus\u00e3o foi pragm\u00e1tica: combinar uma infraestrutura bem escolhida, modelos dimensionados para o problema e ferramentas que favore\u00e7am a explora\u00e7\u00e3o cria uma base s\u00f3lida para construir sistemas de IA fundamentados na disciplina da engenharia. O reposit\u00f3rio compartilhado durante a palestra serve como ponto de partida para engenheiros interessados em continuar essa explora\u00e7\u00e3o.<\/p>\n\n\n\n Small Language Models are the Future of Agentic AI<\/a><\/p>\n\n\n\n AlphaEvolve: A coding agent for scientific and algorithmic discovery<\/a><\/p>\n\n\n\n GitHub – <\/a>marlonjsilva\/clj-agents<\/a><\/p>\n\n\n\n GitHub – clj-python\/libpython-clj<\/a><\/p>\n\n\n\n <\/p>\n\n\n\nO problema da fragmenta\u00e7\u00e3o: APIs em excesso<\/h2>\n\n\n\n
\n
Por que modelos menores costumam funcionar melhor para agentes<\/h2>\n\n\n\n
\n
Por que o Clojure se encaixa nesse espa\u00e7o de problema<\/h2>\n\n\n\n
\n
Da teoria \u00e0 pr\u00e1tica: a demonstra\u00e7\u00e3o ao vivo<\/h2>\n\n\n\n
Conclus\u00e3o<\/h2>\n\n\n\n
Refer\u00eancias<\/h2>\n\n\n\n