O que aprender com os prompts indispensáveis dos engenheiros do Google

O prompt que separa quem produz de quem orienta

Em junho de 2026, o time de developer relations do Google Cloud fez uma pergunta simples a dez de seus engenheiros e líderes: “Qual prompt você pessoalmente se recusa a trabalhar sem — e por quê?”. O resultado não foi uma lista de truques de redação. Foi a descoberta de que dez pessoas chegaram, de forma independente, à mesma conclusão: usar a IA como uma segunda opinião adversária, e não como um assistente agradável.

A metáfora de abertura do material original resume bem o problema: a maioria dos históricos de prompt parece uma gaveta de tralhas. Um pedido único para explicar um erro, um “limpa isso aqui”, um gerador de boilerplate esquecido. O que os engenheiros do Google fizeram foi diferente — transformaram o modelo em alguém que discorda, questiona e audita.

1. Escrever a especificação antes de qualquer código

Maja Bilić, gerente de produto do Google Cloud, não começa pelo código — começa fazendo o modelo argumentar com ela. A técnica atribui ao modelo uma persona cética (arquiteto principal cínico), proíbe escrever código e pede que ele liste considerações técnicas, de UX e de arquitetura antes de fazer perguntas específicas. Só depois o modelo transforma as respostas em documento de requisitos.

O raciocínio: um modelo que “ajuda a planejar um recurso” tende a concordar com o enquadramento inicial. Um modelo que critica a partir de uma persona cética precisa gerar objeções reais — e é nelas que mora o valor do planejamento.

2. Tornar os testes inegociáveis

Andrew Brogdon usa um prompt que trata teste como algo a auditar, não a gerar. Em vez de pedir testes diretamente, o modelo primeiro examina a base de código para achar o que não está coberto, avalia se o código sequer está escrito de forma testável (dependências injetadas, domínios desacoplados) e só então constrói um plano de testes. A sacada: pedir testes diretamente gera testes para o que é mais fácil de testar — não para o que realmente precisa de cobertura.

3. A limpeza em dois prompts separados

Aja Hammerly roda dois prompts estreitos e distintos, em uma conversa nova, sem contexto de desenvolvimento. O primeiro pede para rodar os testes existentes e caçar casos extremos e condições de corrida. O segundo procura outra categoria: código morto, comentários de debug, comentários que não batem mais com o código e TODOs pendentes. Separar “o que falta estruturalmente” de “o que sobrou de forma descuidada” dá respostas mais afiadas que um único “revise isso”.

4. Checagens de conformidade específicas

Rich Hyndman compartilhou uma auditoria de permissões Android: localizar todos os manifestos, extrair permissões declaradas, cruzar com o uso real no código e sinalizar o que está inchado. O padrão generaliza para qualquer superfície de conformidade — variáveis de ambiente, escopos de API, roles de IAM. O fecho é crucial: “não faça nenhuma edição até eu aprovar o plano.”

5. Dar nota ao próprio código como um revisor implacável

Shir Meir Lador ataca um problema real: peça uma revisão de código e o modelo costuma ser educado — um elogio à nomenclatura, uma sugestão de docstring, sinal verde. A solução é atribuir uma persona exigente (engenheiro principal sem tolerância para código “happy path”) e exigir uma nota de A a F para prontidão de produção. O prompt termina pedindo correções exatas, não comentários. Uma rubrica com condição real de reprovação expõe a diferença entre “esse código parece bom” e “esse código é bom”.

6. Fazer o modelo defender o próprio plano

James O’Reilly usa um dos prompts mais curtos da lista — e talvez o mais importante: depois de receber um plano, pedir que o modelo explicite os trade-offs da própria sugestão em desempenho, custo, segurança e manutenibilidade. O objetivo não é mais código; é forçar o modelo a testar o próprio raciocínio, mantendo o humano na cadeira de decisão.

7. Transformar pesquisa externa em checklist de revisão

Emma Twersky aponta o modelo para fora antes de olhar para dentro: pesquisar armadilhas de segurança e erros de lógica comuns em código gerado por IA para uma stack específica — em fóruns, issues do GitHub e blogs técnicos — e converter isso em um checklist de revisão manual. O contexto dá peso à técnica: um estudo de 2022 sobre o GitHub Copilot, com 1.689 programas gerados, encontrou vulnerabilidade real em cerca de 40% deles. Código gerado por IA compila e passa numa olhada rápida — e é exatamente isso que o torna perigoso.

8. Iterar em estágios, não em um mega-prompt

Fred Sauer defende um fluxo em fases: no início, deliberadamente menos específico (ser prescritivo cedo demais cria pontos cegos), depois uma prova de conceito, refinamento e, só no final, uma revisão de código em conversa nova. A lição geral: casar a especificidade do prompt com o estágio do trabalho — solto no começo, preciso no fim.

9. Automatizar a revisão com um script real

Remigiusz Samborski leva o padrão ao limite: em vez de lembrar de pedir revisão, a equipe dele conecta um agente de revisão ao GitHub Actions, para que cada pull request receba uma revisão estruturada e adversária automaticamente. O material mostra uma versão funcional: um script Python que captura o git diff, aplica a rubrica de notas da técnica 5 e roda no CI a cada PR.

10. Pensar em grafos, não em checklists

Karl Weinmeister fecha a lista com a técnica menos convencional: em vez de pedir uma lista genérica de testes (que produz o mesmo boilerplate independentemente do projeto), ele faz o modelo representar o fluxo do app como um grafo acíclico direcionado e raciocinar estruturalmente sobre onde falhas podem se propagar. Ele pede atenção especial às seams — termo de Michael Feathers para as fronteiras entre componentes que ficam sub-testadas justamente porque nenhum componente isolado é dono delas.

O padrão que une tudo

Colocadas lado a lado, as dez técnicas revelam algo que deixa de ser sutil: nenhuma existe para economizar digitação, e nenhuma serve para extrair mais código mais rápido. Todas existem para desfazer uma suposição humana — a de que o caminho feliz basta, que o primeiro plano é o certo, que uma olhada no diff conta como revisão. Se você adotar uma única ideia deste artigo, que seja a rubrica de notas da técnica 5: é o jeito mais rápido de sentir a diferença entre um modelo educado e um modelo que trabalha de verdade contra seus pontos cegos.