Você abriu a vaga de Backend Sênior, leu "experiência com IA generativa no ecossistema Java" e pensou que sabia o suficiente. Aí veio a pergunta que separou a sala: "qual a diferença entre Spring AI 1.x e 2.0, e o que quebra no seu tool calling quando você migra?". Quem só tinha lido o título do release travou ali.
A partir de junho de 2026, essa pergunta entrou no roteiro das entrevistas técnicas de backend Java. O Spring AI 2.0 chegou em release candidate carregando o Spring Boot 4 como dependência obrigatória, e mudou o jeito como as ferramentas (tools) são executadas. Bora ver, na prática, o código antes e depois e a resposta que mostra senioridade de verdade.
Você abriu a vaga de Backend Sênior, leu "experiência com IA generativa no ecossistema Java" e pensou que sabia o suficiente. Aí veio a pergunta que separou a sala: "qual a diferença entre Spring AI 1.x e 2.0, e o que quebra no seu tool calling quando você migra?". Quem só tinha lido o título do release travou ali.
A partir de junho de 2026, essa pergunta entrou no roteiro das entrevistas técnicas de backend Java. O Spring AI 2.0 chegou em release candidate carregando o Spring Boot 4 como dependência obrigatória, e mudou o jeito como as ferramentas (tools) são executadas. Bora ver, na prática, o código antes e depois e a resposta que mostra senioridade de verdade.
Neste artigo você vai sair com três coisas na mão: o que de fato mudou da 1.x para a 2.0, o trecho de código que quebra em silêncio na migração, e um roteiro de respostas para quando o entrevistador puxar esse assunto. Sem teoria solta, com código que parece de produção.
Por que o mercado começou a perguntar isso agora
O timing não é coincidência. O Spring AI 2.0 saiu em RC1 no dia 6 de junho de 2026 e em RC2 no dia 9, segundo o anúncio oficial no blog da Spring. No mesmo mês, o Spring Boot 3.5 perde o suporte aberto (EOL em 30 de junho). Quem acompanha o ecossistema sabe o que isso significa: as empresas estão revisando arquitetura, e a pergunta de entrevista vira termômetro de quem está ligado no mercado de hoje.
A pegadinha da 2.0 é que ela não é só "mais uma versão". Ela amarrou o Spring Boot 4 como dependência dura. Não dá para adotar o Spring AI 2.0 mantendo o Boot 3.x. Ou seja, migrar o stack de IA virou parte de um projeto maior de migração de plataforma. Se a sua app ainda está no Boot 3.5, vale ler antes o roteiro de migração pro Spring Boot 4, porque o Spring AI 2.0 vai cobrar isso de você.
Antes de mexer no código, vale lembrar como uma tool funciona no Spring AI. Você anota um método e o framework o expõe ao modelo como uma função que ele pode chamar:
@Component
public class PedidoTools {
private final PedidoRepository repository;
PedidoTools(PedidoRepository repository) {
this.repository = repository;
}
@Tool(description = "Busca a situacao de um pedido pelo seu id")
public String situacaoDoPedido(Long pedidoId) {
return repository.findById(pedidoId)
.map(Pedido::getStatus)
.orElse("Pedido nao encontrado");
}
}
Esse método o modelo enxerga como uma ferramenta chamada situacaoDoPedido. Quando o usuário pergunta "cadê meu pedido 8842?", o modelo decide chamar a tool, recebe o resultado e responde em linguagem natural. Até aqui, 1.x e 2.0 são iguais. A diferença está em quem executa esse ciclo de chamada.
O que muda: o loop de tools saiu do ChatModel
No Spring AI 1.x, o loop de execução de tools era automático. Você registrava a ferramenta no ChatClient e o ChatModel cuidava de tudo por baixo dos panos: detectava o pedido de tool call, executava o método, devolvia o resultado ao modelo e repetia até a resposta final. Esse era o jeito errado de assumir que "sempre vai funcionar magicamente". E era exatamente isso que a 2.0 veio mexer.
Olha como ficava o serviço na 1.x. O ciclo de tools acontecia sozinho dentro do call():
// ANTES (Spring AI 1.x) - o loop de tools rodava sozinho no ChatModel
@Service
public class AssistenteService {
private final ChatClient chatClient;
AssistenteService(ChatClient.Builder builder, PedidoTools tools) {
this.chatClient = builder
.defaultTools(tools) // bastava registrar a tool
.build();
}
public String responder(String pergunta) {
return chatClient.prompt()
.user(pergunta)
.call()
.content(); // o ChatModel executava o loop de tools por dentro
}
}
Na 2.0, esse loop foi removido do ChatModel. O modelo passou a só sinalizar "quero chamar a tool X com esses argumentos", e a responsabilidade de executar a ferramenta e devolver o resultado ficou explícita, no ToolCallingAdvisor que você adiciona ao ChatClient. A API antiga de toolNames() e o SpringBeanToolCallbackResolver também foram aposentados.
O detalhe cruel: se você só subir a versão e não adicionar o advisor, nada estoura. Não tem exceção, não tem erro vermelho no log. O modelo simplesmente devolve a resposta como se não houvesse ferramenta nenhuma, ignorando a tool. É o tipo de bug que passa no code review e só aparece em produção quando o cliente reclama que "o assistente parou de consultar os pedidos". Esse mesmo padrão de erro silencioso a gente já viu na migração do Jackson 3, e ele é traiçoeiro pela mesma razão: o compilador não te avisa.
O jeito certo na 2.0: ToolCallingAdvisor explícito
O conserto é direto quando você sabe onde olhar. Você declara o ToolCallingAdvisor como default do ChatClient, e aí o ciclo de tools volta a funcionar. É assim que os sêniores fazem: tornam explícito o que antes era mágica implícita.
// DEPOIS (Spring AI 2.0) - o advisor executa o loop de tools de forma explicita
@Service
public class AssistenteService {
private final ChatClient chatClient;
AssistenteService(ChatClient.Builder builder, PedidoTools tools) {
this.chatClient = builder
.defaultAdvisors(ToolCallingAdvisor.builder().build()) // NOVO: obrigatorio
.defaultTools(tools)
.build();
}
public String responder(String pergunta) {
return chatClient.prompt()
.user(pergunta)
.call()
.content(); // agora o advisor cuida do ciclo de chamada
}
}
Repare numa coisa importante para a entrevista: o método responder não mudou uma linha. A mudança é toda na composição do ChatClient, não no ponto de uso. Isso é ótimo porque significa que a migração é cirúrgica, fica concentrada no lugar onde você monta o cliente. E se você quiser controle fino, dá para configurar o limite de iterações do loop, evitando que o modelo entre num vai e volta infinito de chamadas de tool:
Tem uma diferença aqui que rende ponto na entrevista: você pode registrar o advisor de duas formas. Como defaultAdvisors no builder, valendo para todo uso daquele cliente, ou por requisição, com .advisors(...) dentro do prompt(). A escolha não é estética. Quando todas as chamadas precisam de tools, o default deixa o código limpo. Mas quando só alguns fluxos usam ferramentas (e outros são chat puro), aplicar o advisor por requisição evita que o modelo gaste tokens decidindo sobre tools que não existem naquele contexto. Já vi time perder dinheiro de API por deixar tudo no default sem pensar nisso.
ToolCallingAdvisor advisor = ToolCallingAdvisor.builder()
.maxIterations(5) // trava de seguranca contra loop de tools sem fim
.build();
ChatClient chatClient = builder
.defaultAdvisors(advisor)
.defaultTools(new PedidoTools(repository))
.build();
Se você quiser ir mais fundo no que quebra além do tool calling (mudanças de pacote, propriedades renomeadas, remoção de classes), eu detalhei o caminho completo no artigo sobre o código de tools que vai quebrar no Spring AI 2.0. Aqui o foco é o que cai na entrevista.
O impacto prático: as 4 perguntas que vão cair
Como Tech Leader, já conduzi muita entrevista de backend sênior, e aprendi que não adianta o candidato decorar a feature. O que diferencia é conseguir explicar o porquê da mudança e o risco que ela traz. Então separei as quatro perguntas mais prováveis sobre Spring AI 2.0 e a resposta que demonstra senioridade.
1. "Por que o Spring AI 2.0 tirou o loop de tools do ChatModel?" Resposta de sênior: para separar responsabilidades. O ChatModel volta a fazer só uma coisa, falar com o modelo. A orquestração de tools (executar, validar, repetir) passa a ser um advisor componível, que você pode trocar, testar e instrumentar isolado. É a mesma filosofia de tornar explícito o que era implícito.
2. "O que acontece se eu migrar e esquecer o advisor?" Aqui é onde a maioria erra. A resposta certa é: nada explode, as tools são silenciosamente ignoradas. Quem responde "vai dar exceção" entrega que nunca migrou de verdade.
3. "Por que o 2.0 exige Spring Boot 4?" Porque a 2.0 se apoia em recursos do Boot 4 e do Framework 7 (auto-configuração nova, módulos repaginados). Não é capricho, é dependência técnica real. E como o Boot 3.5 sai de suporte em 30 de junho, a migração casa com o ciclo de fim de vida da plataforma.
4. "Como você testaria essa migração com segurança?" Resposta forte: um teste de integração que faz uma pergunta cuja resposta só é possível chamando a tool, e que falha se a tool não for chamada. Assim o erro silencioso vira erro barulhento no CI:
@SpringBootTest
class AssistenteToolCallingTest {
@Autowired AssistenteService assistente;
@Test
void deveChamarToolDePedido() {
String resposta = assistente.responder("Qual a situacao do pedido 8842?");
// se o advisor sumir, a tool nao roda e o assert quebra no CI
assertThat(resposta).contains("ENTREGUE");
}
}
Quem responde com um teste assim mostra que entende o risco real da migração, não só a sintaxe. E é exatamente esse tipo de visão que move a conversa salarial do pleno para o sênior. Se você quer entender melhor como o mercado sênior de Java mudou, dá uma olhada em como o DevOps clássico sumiu das vagas Java sênior.
Indo além: tools, MCP e o Spring AI como plataforma
Tem um ponto que rende ponto extra na entrevista: conectar tool calling ao MCP (Model Context Protocol). O Spring AI 2.0 deixou simples expor o seu próprio Boot 4 como um servidor de ferramentas para outros agentes consumirem. Se quiser ver esse lado, eu mostro o passo a passo em como transformar seu Spring Boot 4 em ferramenta de IA com 3 anotações. A documentação oficial do projeto também vale o bookmark: o repositório do Spring AI no GitHub é a fonte mais atualizada das mudanças de API.
Quando usar o advisor com mais cuidado? Em fluxos onde a tool tem efeito colateral (gravar no banco, disparar pagamento). Aí você quer o maxIterations baixo e validação dos argumentos antes de executar. Quando não se preocupar tanto? Em tools de leitura pura, como a consulta de pedido do exemplo. Saber fazer essa distinção é o que separa quem copia tutorial de quem pensa em produção.
Resumo e próximo passo
Se você fixar três ideias deste artigo, já está à frente da maioria dos candidatos:
- O loop de tools saiu do ChatModel na 2.0: agora é o
ToolCallingAdvisorexplícito noChatClientque executa o ciclo. - Esquecer o advisor falha em silêncio: sem exceção, a tool é só ignorada. Por isso o teste de integração é obrigatório.
- Spring AI 2.0 exige Spring Boot 4: a migração de IA vem junto com a migração de plataforma, e o Boot 3.5 sai de suporte em 30 de junho.
Agora me conta: a sua empresa já está planejando subir pro Spring AI 2.0, ou ainda está segurando no Boot 3.x? Escreve nos comentários em que ponto da migração vocês estão, quero entender como está sendo na real para os times brasileiros.
Na próxima, vou pegar o lado de quem constrói o agente do zero: como montar um RAG que decide sozinho quando buscar no vector store, usando tool calling no Spring AI. Fica de olho aqui no Meu Universo Nerd.
Perguntas frequentes
Preciso migrar para o Spring Boot 4 para usar o Spring AI 2.0?
Sim. O Spring AI 2.0 traz o Spring Boot 4 como dependência obrigatória. Se a sua app está no Boot 3.x, a adoção do 2.0 vem junto com a migração de plataforma. Para apps que ainda não podem migrar, o Spring AI 1.1.x segue recebendo correções por enquanto.
Meu tool calling vai quebrar com erro ao migrar?
Não com erro visível, e esse é o perigo. Sem o ToolCallingAdvisor no ChatClient, as ferramentas são ignoradas sem lançar exceção. O sintoma é o assistente "esquecer" de consultar dados. Por isso o teste de integração que valida a chamada da tool é essencial.
Dá para manter Spring AI 1.x em produção por mais tempo?
Dá, enquanto a linha 1.1.x receber patches. Mas com o Boot 3.5 saindo de suporte em 30 de junho de 2026, segurar no stack antigo acumula dívida técnica. O ideal é planejar a migração agora, no calendário do EOL.
O ToolCallingAdvisor afeta a performance?
O custo de orquestração é o mesmo que o loop fazia antes, só que agora explícito. O ganho é controle: você define maxIterations para evitar loops de tool sem fim e pode instrumentar o advisor para observabilidade, algo que era difícil quando o ciclo ficava escondido no ChatModel.
Isso cai mesmo em entrevista de backend Java?
A partir de junho de 2026, sim, especialmente em vagas que pedem IA generativa no ecossistema Spring. Saber explicar a mudança de tool calling, o motivo arquitetural e o risco do erro silencioso é um diferenciador concreto de senioridade.