Gemini 3.5 Pro: Google arquivou o modelo e acelerou o Gemini 4

2>O Google enterrou o Gemini 3.5 Pro em silêncio — e isso diz muito sobre o estado da corrida em 2026

Quando li a análise da Semi Analysis publicada originalmente pelo Eurisko.com.br, uma coisa me chamou a atenção antes de qualquer jargão de mercado: o Google prometeu um modelo, mostrou em slide para investidores, e simplesmente… não entregou. Junho virou julho, julho virou agosto, e nada. Na minha experiência acompanhando ciclos de lançamento de modelos grandes, isso não é atraso operacional — é sinal de que algo mais profundo aconteceu internamente.

O Gemini 3.5 Pro era vendido como o passo intermediário entre o 3 Pro e o suposto Gemini 4, com foco em coding agêntico, tarefas de longa duração e fluxos complexos multi-etapa. O fato de o Google ter arquivado isso internamente e acelerado o 4 revela três coisas que eu quero destrinchar aqui: a estratégia da Alphabet está em transição, o conceito de “versão intermediária” está morrendo, e nós, devs, precisamos parar de construir produtos em cima de promessas de roadmap.

O que realmente foi prometido (e por que importava para devs)

Em junho de 2025, o Sundar Pichai subiu no palco para investidores e cravou datas. Quem trabalha com desenvolvimento sério lembra como esse tipo de apresentação funciona: bullets bem desenhados, KPIs projetados, e modelos posicionados como “diferenciais competitivos”. O Gemini 3.5 Pro aparecia nos materiais oficiais com promessas técnicas específicas:

• Codificação agêntica de longa duração — a ideia de um modelo que sustentasse contexto e planejamento por horas, não minutos.
• Execução multi-step confiável — menos alucinação entre etapas, melhor capacidade de corrigir o próprio erro.
• Integração nativa com fluxos de trabalho de engenharia — algo próximo do que o Devin e o Cursor vêm tentando resolver.

Para quem programa, isso não era marketing vazio. Coding agêntico de longa duração é o santo graal de 2026 — é o que separa um copilot de um engenheiro júnior. Eu mesmo tenho testado as alternativas atuais em produção e a lacuna entre “modelo responde bem em uma janela” e “modelo termina um PR inteiro sem intervenção humana” continua brutal.

Por que pular do 3 Pro direto para o 4 faz sentido (e o que isso esconde)

Existem duas leituras possíveis, e na minha opinião as duas estão acontecendo ao mesmo tempo.

Leitura otimista: o Google percebeu que um salto incremental não gera diferenciação. A concorrência está brutal — GPT-5, Claude 4.5 Opus, Grok 4, Llama 4 Maverick — e lançar um “3.5” seria entregar uma nota de rodapé. Pular para o 4 permite reposicionar a marca com um salto perceptível.

Leitura pragmática: versões intermediárias viraram ônus de marketing. Em 2024 e 2025, vimos o GPT-4.5, Claude 3.5 Sonnet, Gemini 1.5 Pro — todos “meio passos” que confundiram o usuário final e geraram ruído no ecossistema. O ecossistema de APIs amadureceu: devs querem saber “qual modelo uso hoje, e quando ele vai ser depreciado”.

O terceiro ponto, e esse ninguém fala, é custo de inferência. Treinar um modelo intermediário exige alocar capacidade de TPU que poderia ir para o 4. Quando a margem de lucro por token cai, cada ciclo de treinamento precisa justificar ROI. O Google não é uma ONG — é uma empresa que precisa entregar crescimento de margem em cloud, e modelos intermediários raramente pagam a conta.

Na Prática: como testar os modelos Gemini disponíveis hoje e não depender de promessa

Como dev, a maior lição que tiro desse episódio é: nunca bloqueie seu produto em uma versão que ainda não existe. O caminho seguro é sempre implementar uma camada de abstração sobre o provedor. Aqui vai um exemplo funcional em Node.js que costumo usar:

// provider-agnostic-llm-router.js
// Camada de abstração para trocar de provedor sem reescrever o app

class LLMRouter {
  constructor(providers) {
    this.providers = providers; // { google, openai, anthropic, ... }
  }

  async complete({ task, prompt, options = {} }) {
    const selection = this.selectProvider(task, options);
    const provider = this.providers[selection.name];

    if (!provider) throw new Error(`Provider ${selection.name} não configurado`);

    try {
      const result = await provider.generate(prompt, {
        ...options,
        model: selection.model,
      });
      return { ...result, provider: selection.name, model: selection.model };
    } catch (err) {
      // Fallback automático se o modelo principal falhar
      if (selection.fallback) {
        const fb = selection.fallback;
        const fallbackProvider = this.providers[fb.name];
        const fbResult = await fallbackProvider.generate(prompt, {
          ...options,
          model: fb.model,
        });
        return { ...fbResult, provider: fb.name, model: fb.model, fallback: true };
      }
      throw err;
    }
  }

  selectProvider(task, options) {
    // Routing baseado no tipo de tarefa
    if (task === 'long-context-analysis' && options.tokens > 100000) {
      return {
        name: 'google',
        model: 'gemini-2.5-pro', // use o que EXISTE hoje
        fallback: { name: 'anthropic', model: 'claude-4-5-sonnet' },
      };
    }
    if (task === 'code-review' || task === 'refactor') {
      return {
        name: 'anthropic',
        model: 'claude-4-5-sonnet',
        fallback: { name: 'openai', model: 'gpt-5' },
      };
    }
    if (task === 'fast-classification') {
      return {
        name: 'google',
        model: 'gemini-2.5-flash',
        fallback: { name: 'openai', model: 'gpt-5-mini' },
      };
    }
    return { name: 'openai', model: 'gpt-5' };
  }
}

module.exports = { LLMRouter };

O ponto crítico desse padrão: o nome do modelo é uma variável, não uma constante. Quando o Gemini 4 sair (se sair), você troca uma string. Quando o Gemini 2.5 Pro for depreciado (vai ser), idem. Já vi empresa em produção quebrar porque tinha `model: “gpt-4″` hardcoded em 200 lugares.

Erros Comuns que devs cometem (e que esse caso escancara)

1. Acoplar o roadmap do seu produto ao roadmap do provedor. Se sua feature depende de “Gemini 3.5 Pro chegando em junho”, você tem um problema de produto, não de IA. Sempre construa com o que existe e mantenha a porta aberta para upgrade.

2. Ignorar depreciação. Cada modelo tem um ciclo de vida finito. O Gemini 1.5 Pro já foi depreciado, o 1.0 também. Se você não tem um plano de migração documentado, sua stack vai quebrar em produção sem aviso.

3. Comprar a narrativa do “modelo vai revolucionar tudo”. Pichai falou em junho. Estamos em agosto e nada. Marketing de IA vive de slides; engenharia vive de tokens rodando. Trate promessas como promessas, não como entregas.

4. Esquecer de medir custo por token em produção. Modelos “Pro” custam 10x a mais que “Flash”. Em escala, isso é a diferença entre lucrativo e deficitário. Routing inteligente por tipo de tarefa (como mostrei acima) é obrigatório em 2026.

5. Não testar fallback. Se seu app quebra quando a API do Google cai por 3 minutos, sua UX está ruim. Implementar degradação graceful é tão importante quanto implementar o caminho feliz.

Comparativo prático: o que usar AGORA enquanto o Gemini 4 não chega

Na minha rotina, o combo que mais funciona hoje é: Claude 4.5 Sonnet para coding agêntico, Gemini 2.5 Flash para pré-processamento e classificação, e GPT-5 quando a tarefa exige raciocínio encadeado pesado. É redundante? É. É caro? Não necessariamente, porque cada um entra onde realmente performa melhor.

FAQ — Perguntas reais que devs fazem sobre isso

O Gemini 3.5 Pro ainda vai ser lançado?

Improvável. Segundo a análise da Semi Analysis referenciada pelo Eurisko, o Google já realocou os recursos internamente. Em TI aprendemos rápido: projeto arquivado uma vez raramente é reaberto, porque a janela competitiva já fechou.

Devo esperar o Gemini 4 para começar meu projeto?

Não. Construa com o que existe hoje, mantenha a abstração de modelo (como mostrei no código), e tenha um plano de upgrade pronto. Esperar modelo futuro é a forma mais rápida de entregar nada.

Por que o Google pula versões intermediárias enquanto a concorrência não?

Pressão competitiva. A OpenAI e a Anthropic segmentam mais (mini, nano, flash, pro) porque competem por diferentes faixas de preço. O Google está tentando consolidar a percepção de liderança com saltos maiores — mas isso cobra o preço de gerar desconfiança no ecossistema.

Vale a pena usar Gemini Flash em produção?

Sim, para tarefas onde latência e custo importam mais do que raciocínio profundo. Classificação, extração de entidades, sumarização de documentos grandes, pré-routing de tickets — Flash resolve muito bem. Só não peça pra ele arquitetar um sistema distribuído.

Como saber quando um modelo será depreciado?

Todo provedor sério publica um model deprecation policy. Ative os alertas de changelog, siga os canais oficiais no GitHub (cada provedor tem um repo de releases), e nunca confie em um modelo que não está marcado como “stable” para workloads críticos.

Coding agêntico já é viável em produção hoje?

Parcialmente. Eu uso em pipelines internos (CI de PR review, geração de testes unitários, refactor mecânico). Para tarefas que exigem decisão arquitetural ou acesso a contexto de negócio, ainda não confio 100%. A lacuna entre demo e produção continua real — e o caso do Gemini 3.5 Pro é exatamente sobre isso: prometer coding agêntico robusto é fácil, entregar é outra história.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.