Um modelo pode vencer benchmarks de programação e ainda falhar no trabalho que ocupa o dia de um desenvolvedor: entender um repositório existente, localizar a origem de um bug e corrigir o problema sem quebrar outras partes do sistema. É essa diferença entre pontuação e entrega real que torna relevante a dúvida sobre o Gemini 4 relatada por funcionários do Google.
Segundo o Eurisko.com.br, com base em uma reportagem da Bloomberg, pessoas com acesso interno ao projeto questionaram o desempenho do modelo em determinadas tarefas reais de programação, apesar dos resultados fortes em benchmarks. Isso não prova que o Gemini 4 seja ruim para desenvolvimento — nem permite concluir que outros modelos sejam melhores em todos os cenários. Mas aponta para uma questão que eu considero essencial: o que exatamente estamos chamando de capacidade de programação?
Benchmarks de programação não medem o trabalho inteiro
Um benchmark costuma transformar uma habilidade em uma tarefa delimitada. O modelo recebe uma pergunta, um trecho de código ou uma descrição relativamente clara e precisa produzir uma resposta que possa ser comparada com um resultado esperado.
Isso é útil para comparar modelos sob condições controladas. O problema aparece quando alguém interpreta a nota como uma previsão direta de produtividade em um projeto real. Escrever uma função isolada é diferente de alterar um sistema com dependências, convenções internas, testes incompletos e requisitos que mudam durante a implementação.
Em um repositório real, o trabalho costuma começar antes do código. É preciso entender onde a lógica está, quais módulos dependem dela, como reproduzir o erro e quais comportamentos existentes não podem mudar. Depois vêm a implementação, os testes, a revisão do diff e, muitas vezes, uma segunda rodada para corrigir efeitos colaterais.
O que uma pontuação alta pode esconder
Benchmarks variam em formato e dificuldade. Alguns medem a geração de código a partir de uma especificação; outros avaliam se o modelo consegue resolver issues em repositórios. Mesmo os testes mais próximos do trabalho real não representam toda a diversidade de uma equipe: arquitetura legada, documentação desatualizada, ferramentas próprias e regras de negócio pouco explícitas.
Também importa o método de avaliação. O resultado pode mudar conforme o modelo recebe uma ou várias tentativas, tem acesso a ferramentas, pode executar testes ou recebe contexto previamente selecionado. Uma nota sem esses detalhes é difícil de interpretar. “Acertou” pode significar que passou um teste específico, não que a alteração seja segura, legível ou adequada para manutenção.
Por isso, eu trato benchmarks como evidência parcial, não como certificado de que uma IA consegue assumir tarefas de ponta a ponta. Eles ajudam a formular perguntas; não substituem uma avaliação no fluxo de trabalho que a equipe realmente usa.
Por que programar em um repositório é mais difícil
Imagine uma issue simples: “O usuário recebe erro ao salvar o perfil quando o campo de telefone está vazio”. A solução pode exigir descobrir se o problema está no formulário, na validação da API, na serialização ou no banco de dados. Uma alteração aparentemente pequena pode afetar clientes antigos, dados existentes ou outro fluxo de atualização.
Um agente de programação precisa lidar com pelo menos quatro etapas conectadas:
- Exploração: encontrar os arquivos relevantes e entender como o projeto organiza responsabilidades.
- Diagnóstico: distinguir a causa do sintoma, em vez de apenas silenciar a mensagem de erro.
- Alteração: fazer a menor mudança compatível com os padrões e as interfaces existentes.
- Verificação: executar testes, analisar falhas e conferir se o diff não inclui mudanças acidentais.
O modelo também pode tropeçar em requisitos ambíguos. Se a issue não esclarece o comportamento esperado para um campo vazio, a resposta correta talvez seja pedir contexto, não inventar uma regra. Em software, uma implementação plausível ainda pode estar errada para o produto.
Gemini 4, Claude e GPT: compare no seu fluxo, não por torcida
Quando avalio ferramentas de programação, não escolho apenas pelo nome do modelo ou por uma tabela de resultados. Comparo alternativas — como Gemini, Claude e GPT — na mesma tarefa, com o mesmo repositório, o mesmo contexto inicial e as mesmas permissões. Em algumas equipes, modelos abertos também entram na comparação por motivos de custo, privacidade ou execução local.
O resultado depende do conjunto inteiro: modelo, janela de contexto, ferramentas disponíveis, qualidade da busca no repositório, instruções do agente e ambiente de execução. Um modelo pode ser bom em explicar código, mas exigir supervisão frequente para editar vários arquivos. Outro pode produzir uma primeira solução convincente, mas ignorar uma convenção interna que só aparece em testes ou documentação.
Para comparar de forma justa, observo indicadores práticos: a tarefa foi concluída? Os testes relevantes passaram? Quantas intervenções humanas foram necessárias? O agente mudou arquivos sem relação com o problema? O diff é fácil de revisar? A solução respeita as interfaces existentes?
Não existe um vencedor universal. Um resultado obtido em um projeto TypeScript bem testado pode não se repetir em um monólito antigo com documentação incompleta. A escolha deve refletir os repositórios e os riscos da equipe, não uma classificação isolada.
Na Prática: como avaliar um modelo de programação
Eu montaria uma avaliação pequena, repetível e baseada em tarefas que já aconteceram no projeto. O objetivo não é criar um benchmark acadêmico, mas descobrir onde a ferramenta economiza tempo — e onde acrescenta risco.
- Selecione tarefas reais. Use issues resolvidas, bugs reproduzíveis e pequenas melhorias. Remova informações que revelem a solução antes de apresentar a tarefa ao modelo.
- Prepare o mesmo ponto de partida. Use a mesma revisão do repositório, instruções, ferramentas e limites de tempo para cada alternativa.
- Defina critérios antes de testar. Inclua testes existentes, critérios de aceitação e condições como “não alterar a API pública”.
- Registre o processo. Anote tentativas, comandos executados, falhas, correções humanas e arquivos modificados. O resultado final sozinho esconde o custo de chegar até ele.
- Revise o diff manualmente. Testes passando são necessários, mas não garantem que a implementação seja simples, segura ou compatível com as regras do produto.
Um exemplo básico de verificação automatizada com Python é executar a suíte de testes após a alteração e falhar claramente quando ela exceder o tempo definido. O trecho abaixo pressupõe que o projeto usa pytest e que o ambiente já está preparado:
import subprocess
import sys
def run_tests(timeout_seconds=120):
try:
result = subprocess.run(
[sys.executable, "-m", "pytest", "-q"],
check=False,
capture_output=True,
text=True,
timeout=timeout_seconds,
)
except subprocess.TimeoutExpired:
print(f"Falha: testes excederam {timeout_seconds} segundos.")
return 124
if result.stdout:
print(result.stdout)
if result.stderr:
print(result.stderr, file=sys.stderr)
if result.returncode != 0:
print(f"Falha: pytest terminou com código {result.returncode}.")
else:
print("Testes concluídos com sucesso.")
return result.returncode
if __name__ == "__main__":
raise SystemExit(run_tests())Esse script não prova que a solução está correta. Ele apenas automatiza uma parte verificável do processo. Para uma avaliação mais útil, eu também compararia o diff com a issue e incluiria testes de regressão que reproduzam o comportamento original. A razão é simples: uma suíte pode passar e ainda não testar o caso que motivou a tarefa.
Erros comuns ao usar IA para programar
Confundir código compilável com solução correta
Uma resposta pode compilar e passar nos testes existentes sem atender ao requisito novo. Quando os testes são fracos, isso cria uma falsa sensação de segurança. Escreva critérios de aceitação claros e, quando possível, um teste que falhe antes da correção e passe depois dela.
Entregar contexto demais ou de menos
Colar arquivos inteiros sem explicar o objetivo pode desperdiçar contexto e dificultar a análise. Fornecer apenas a mensagem de erro, por outro lado, pode esconder a relação entre módulos. Eu começo pela issue, pelo comando que reproduz o problema e pelos arquivos mais relevantes; depois amplio a investigação conforme necessário.
Aceitar mudanças extensas sem revisar
Uma alteração grande aumenta a superfície de risco. Confira o diff, procure mudanças não relacionadas e peça justificativa para decisões arquiteturais que não estavam no escopo. Se o modelo refatorar metade do módulo para corrigir uma validação, isso merece atenção, não aprovação automática.
Tratar ausência de resposta como falha do modelo
Às vezes a tarefa está mal especificada ou depende de uma decisão de produto. Um agente que sinaliza a ambiguidade pode ser mais útil do que outro que escolhe um comportamento arbitrário e entrega código com confiança. Avalie também quando a ferramenta pede esclarecimentos e como lida com incerteza.
O que a discussão sobre o Gemini 4 significa para equipes
O relato atribuído à Bloomberg é um lembrete para separar demonstração de capacidade operacional. Se a equipe está escolhendo uma ferramenta, não precisa esperar uma nota perfeita em benchmark nem assumir que um resultado forte resolverá seus problemas. Precisa testar tarefas representativas, com controles simples e revisão humana.
Na minha avaliação, a métrica mais importante não é “quantas linhas o modelo escreveu”. É o saldo entre tempo economizado e trabalho de verificação, correção e prevenção de regressões. Uma IA que produz código rapidamente, mas exige que alguém investigue erros sutis por horas, pode não ser um ganho.
Também vale limitar permissões no começo. Dê ao agente acesso ao repositório e aos testes necessários, mas não a credenciais de produção. Use branches isoladas, revise comandos destrutivos e mantenha aprovação humana antes de integrar mudanças sensíveis. Isso não é desconfiança de um modelo específico; é engenharia de software responsável.
Perguntas frequentes sobre Gemini 4 e programação
O Gemini 4 é ruim para programar?
O relato citado não permite concluir isso. Ele aponta dúvidas internas sobre tarefas reais, apesar de resultados fortes em benchmarks. A avaliação adequada depende do tipo de projeto, das ferramentas disponíveis e dos critérios usados pela equipe.
Por que um modelo pode ir bem em benchmarks e falhar no meu repositório?
Benchmarks têm tarefas e condições delimitadas. Seu projeto pode exigir entender dependências, convenções, código legado e requisitos implícitos. Além disso, uma pontuação pode medir acertos em testes específicos, não a qualidade completa de uma alteração.
Como comparo Gemini, Claude e GPT para desenvolvimento?
Use as mesmas tarefas, o mesmo commit, as mesmas instruções e as mesmas ferramentas. Registre testes, intervenções humanas, tempo e qualidade do diff. Evite concluir qual é melhor com base em uma única issue ou em resultados obtidos em outro contexto.
Benchmarks como SWE-bench são inúteis?
Não. Eles oferecem uma referência controlada e podem ajudar a acompanhar progresso. Mas não representam todos os repositórios nem substituem testes no ambiente da equipe. Use-os como uma parte da avaliação, não como garantia de desempenho em produção.
Posso deixar um agente de IA integrar código automaticamente?
Para mudanças de baixo risco, uma equipe pode automatizar partes do fluxo após validar o processo. Ainda assim, mantenha testes, revisão de diff e controles de permissão. Para alterações em autenticação, dados, pagamentos ou infraestrutura, a revisão humana é especialmente importante.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.