---
title: "Por que engenheiros seniores tropeçam na construção de agentes de IA"
author: "Ricardo Pupo Larguesa"
date: "2026-06-24 17:13:00-03"
category: "Opinião"
url: "http://scale.press/portal/aintuicao/post/2026/06/24/por-que-engenheiros-seniores-tropecam-na-construcao-de-agentes-de-ia/md"
---

## Resumo
- Philipp Schmid do DeepMind lista cinco colisões de mentalidade entre engenharia tradicional e desenvolvimento de agentes.
- Texto substitui estruturas de dados como estado principal dos agentes.
- Erros deixam de ser falhas para virar input de aprendizado e recuperação.
- Avaliações holísticas (evals) substituem testes unitários fixos.
- APIs precisam ser explícitas porque agentes não carregam contexto implícito do desenvolvedor.
- Princípios práticos: preserve significado, projete para recuperação, avalie em vez de afirmar, construa para deletar.

---

Philipp Schmid, do Google DeepMind, apresentou no fim de maio um diagnóstico sobre o uso da IA no desenvolvimento de sistemas. Ele argumenta que engenheiros seniores carregam anos de contexto implícito que agentes simplesmente não possuem. O talk “Why (Senior) Engineers Struggle to Build AI Agents” lista cinco colisões de mentalidade que explicam por que muitas tentativas de construir agentes emperram logo na transição do protótipo para algo que roda de verdade.

## Do determinismo ao texto como estado

A primeira colisão é a mais básica. Engenharia tradicional espera caminhos lineares e estados discretos. Agentes operam em texto: o que antes era uma struct ou um enum vira prompt, resposta e nova chamada. Schmid ressalta que isso exige APIs explícitas e autodescritivas, porque o agente só vê schema e docstring. Quem já viu um deleteItem óbvio para o desenvolvedor e opaco para o modelo entende do que estou falando.

## Entregar o controle e aceitar que erros são input

A segunda e terceira colisões andam juntas. Parar de ditar cada passo e permitir que o agente decida exige confiança que muitos times ainda não construíram. Quando o agente roda quinze minutos e erra, reiniciar do zero custa caro. A lição aprendida é projetar para recuperação: checkpoints, logs detalhados e caminhos de fallback que não dependam de recomeçar tudo. É usar técnicas de looping via engenharia de prompt.

## De testes unitários para avaliações reais

A quarta colisão é a mais dolorosa para quem vem de engenharia de software clássica. Unit tests verificam se entrada fixa gera saída fixa. Com agentes a pergunta certa é “com que frequência funciona?”. Schmid chama isso de evals: múltiplas execuções, métricas de sucesso em cenários variáveis. Manter o mesmo rigor de teste sem essa mudança de lente é receita para falsos positivos em produção.

## Agentes evoluem, APIs não

Por fim, o quinto ponto: agentes melhoram com modelos mais novos; APIs ficam estáticas. A recomendação é construir para deletar. Se o agente de hoje depende de um prompt frágil, amanhã você provavelmente vai reescrever com o próximo modelo. Aceitar isso reduz apego a soluções que envelhecem rápido.

Quem já tentou colocar agentes em produção sabe que o gargalo raramente é o modelo. É a quantidade de contexto implícito que transferimos mal para o sistema. O talk de Schmid oferece um vocabulário útil para nomear esses tropeços antes que eles virem dívida técnica.

Link para o talk completo: [YouTube](https://www.youtube.com/watch?v=3_gYbhABcAE). Mais detalhes no resumo técnico: [StartupHub](https://www.startuphub.ai/ai-news/ai-research/2026/google-deepmind-explains-ai-agent-building-struggles).

Conectar com o que já venho discutindo sobre agentes e engenharia de prompt reforça a mesma ideia: o problema não é falta de modelo melhor, é falta de mentalidade que aceite incerteza como parte do projeto.