# Quando a IA deixa de chutar a documentação

> Respostas ancoradas em fontes oficiais, revisões configuráveis e métricas por repositório mostram uma IA de desenvolvimento mais verificável.

- Author: Elzo Brito
- Language: pt-BR
- Published: 2026-07-18
- Canonical URL: https://elzobrito.com/blog/quando-a-ia-deixa-de-chutar-a-documentacao/
- Translation: https://elzobrito.com/en/blog/when-ai-stops-guessing-the-docs/

---
Assistentes de programação costumam ser avaliados pela resposta que produzem. As novidades mais interessantes desta janela apontam para outra direção: avaliar de onde veio a resposta, em qual ambiente ela foi testada e que efeito teve no trabalho real. É uma mudança menos vistosa que um modelo novo, mas talvez mais importante para transformar demonstrações convincentes em ferramentas confiáveis.

O Google tornou estável uma interface para responder perguntas com base em sua documentação oficial. O GitHub, no mesmo dia, ampliou o controle sobre o ambiente de revisão do Copilot e passou a oferecer métricas de uso por repositório. Juntas, essas mudanças aproximam três peças que normalmente ficam separadas: evidência, execução e medição.

## A documentação vira uma fonte consultável, não apenas contexto

Em 17 de julho, o Google marcou como geralmente disponível o método [`AnswerQuery` da Developer Knowledge API](https://developers.google.com/knowledge/release-notes). A interface recebe uma pergunta técnica e devolve uma resposta ancorada no corpus de documentação para desenvolvedores do Google.

O detalhe decisivo está no formato da resposta. A [documentação do método](https://developers.google.com/knowledge/answer-query) mostra que, além do texto, a API retorna citações ligadas a trechos e referências com título e endereço do documento original. Antes, o método estava em prévia pública; a promoção para disponibilidade geral sinaliza que ele saiu da fase experimental da interface, sem significar que toda resposta esteja automaticamente correta.

Para quem constrói agentes, isso oferece uma alternativa à busca aberta ou a uma cópia particular de páginas que envelhece silenciosamente. Um assistente pode responder como criar um conjunto de dados no BigQuery e, ao mesmo tempo, indicar qual trecho oficial sustenta a instrução. Na prática, a citação não elimina a revisão: ela torna a revisão possível.

Também há limites claros. O corpus cobre domínios definidos pelo Google, e uma resposta fundamentada ainda pode escolher uma passagem incompleta ou interpretar mal uma pergunta. A arquitetura melhora quando o produto exibe as referências, preserva a distinção entre resposta e fonte e permite que operações sensíveis exijam confirmação.

## A revisão ganha um ambiente próprio

O GitHub levou a mesma ideia de verificabilidade para a execução. O [Copilot code review agora aceita configuração específica](https://github.blog/changelog/2026-07-17-copilot-code-review-customization-and-configurability-improvements) em `.github/workflows/copilot-code-review.yml`: o repositório pode instalar dependências, preparar ferramentas e escolher runners para a revisão. As instruções passam a ser lidas da branch de origem do pull request, o que permite testá-las antes do merge, e arquivos como `REVIEW.md`, `GEMINI.md` e `CLAUDE.md` também entram no conjunto reconhecido.

Isso corrige uma fragilidade comum. Pedir a um agente para revisar testes sem oferecer dependências, compilador ou convenções do projeto é como pedir uma inspeção mecânica apenas por fotografia. Com um ambiente reproduzível, a revisão pode consultar o sistema real em vez de inferir tudo pelo diff.

Há ainda uma fronteira de segurança explícita: o acesso à rede fica atrás de firewall por padrão e pode ser configurado separadamente do agente de desenvolvimento. O anúncio ressalva que runners auto-hospedados ainda não têm esse suporte. A consequência prática é simples: equipes que usam infraestrutura própria não devem presumir o mesmo isolamento oferecido pelo runner hospedado.

## Medir atividade não é medir qualidade

Também em 17 de julho, a [API de métricas do Copilot ganhou relatórios diários por repositório](https://github.blog/changelog/2026-07-17-repository-level-github-copilot-usage-metrics-generally-available). Dois endpoints, para organizações e empresas, registram pull requests criados ou integrados pelo agente de código e revisões realizadas pelo Copilot, incluindo contagens de sugestões por tipo de comentário.

Antes, os relatórios paravam nos níveis de organização e usuário. A nova granularidade permite descobrir onde a ferramenta realmente participa do fluxo e onde uma equipe pode precisar de configuração ou capacitação. Mas contagem de pull requests e comentários continua sendo atividade, não qualidade. Um repositório com mais sugestões não é necessariamente mais seguro, rápido ou saudável.

O uso responsável combina esses números com resultados que a própria plataforma não resolve sozinha: tempo até integração, regressões, retrabalho, incidentes e percepção dos mantenedores. A métrica útil não é “quanto usamos IA?”, e sim “em quais condições ela melhorou um resultado que importa?”.

## A próxima vantagem é poder conferir

As três mudanças compartilham uma tese discreta. A IA para desenvolvimento amadurece quando deixa rastros verificáveis: uma fonte que pode ser aberta, um ambiente que pode ser reproduzido e uma atividade que pode ser relacionada a resultados.

Modelos melhores ainda importam, mas a confiança cotidiana nasce nas bordas. Uma resposta com referência é mais útil que uma resposta apenas eloquente; uma revisão com ferramentas reais vale mais que um palpite sobre o diff; e uma métrica contextualizada ensina mais que um placar de adoção. O próximo salto talvez não seja fazer a máquina falar com mais certeza, e sim tornar mais barato conferir quando ela está certa.