Se você tem 30 segundos (TL;DR)
- A síndrome da tela branca parece um cardápio sem fim: cada escolha abre outras, e nada fecha a pergunta. Um rascunho de IA chega como um prato já servido, e a única decisão que sobra é o que tirar.
- Com o rascunho na tela, “o que deve existir aqui?” vira “este trecho fica?”. No estudo de Vaithilingam, a maioria preferiu o Copilot pelo ponto de partida, mesmo sem melhora necessária no tempo.
- Peça um rascunho pequeno, que já deixe de fora o que você cortaria depois.
- O preço aparece na leitura. No DORA, engenheiros relatam mais esforço de verificação. Em projetos maduros, Becker mediu aumento de 19% no tempo de conclusão com IA.
- Um hook de pre-commit barra o commit até o checklist entrar no stage com 14 caixas marcadas e o código junto. O stage é a área do Git com as alterações preparadas para o próximo commit.
Por que a tela branca trava
Um repositório vazio faz uma pergunta aberta: o que deve existir aqui? Nome do projeto, estrutura de pastas, biblioteca de testes e formato de configuração brigam pela primeira decisão. Cada uma puxa outras, e enquanto nenhuma fecha, o arquivo continua vazio.
Com um rascunho na tela, a pergunta muda para “este trecho fica?”. A resposta tem três saídas: manter, cortar ou reescrever. Ae decisão fica do tamanho do código na tela, e por isso gero o rascunho antes de escrever qualquer linha.
O cardápio serve só como imagem. A meta-análise de Scheibehenne, Greifeneder e Todd (2010) achou efeito médio perto de zero sobre sobrecarga de escolha. Ela não prova que opção demais trava alguém.
O ponto de partida nos estudos
Segundo a análise do DORA publicada em 10 de março de 2026, o rascunho inicial move o engenheiro do estado de criação para o estado de edição. A análise usa 1.110 respostas abertas de engenheiros do Google. Uma delas diz: “I get frozen in front of a blank page.”
No estudo de Vaithilingam, Zhang e Glassman, o Copilot não melhorou necessariamente o tempo nem a taxa de sucesso. Mesmo assim, a maioria dos participantes quis usar a ferramenta no dia a dia. Os motivos foram o ponto de partida útil e menos esforço buscando na internet.
| Estudo | O que testou | O que achou |
|---|---|---|
| Peng, Kalliamvakou, Cihon e Demirer, 2023 | Copilot de 2022, implementar um servidor HTTP em JavaScript o mais rápido possível | O grupo com Copilot terminou 55,8% mais rápido |
| Vaithilingam, Zhang e Glassman, 2022 | 24 participantes, cada um testado em todas as condições | Tempo e taxa de sucesso não melhoraram necessariamente, mas a maioria preferiu a ferramenta |
| Barke, James e Polikarpova, 2022 | 20 participantes, tarefas em quatro linguagens | O uso se divide em modo de aceleração e modo de exploração |
| Becker, Rush, Barnes e Rein, 2025 | Ferramentas do início de 2025, 16 desenvolvedores experientes, 246 tarefas em projetos maduros | Com IA liberada, o tempo de conclusão subiu 19% |
| DORA, 2026 | Análise temática de 1.110 respostas abertas de engenheiros do Google | O tempo poupado na criação vai para auditoria e verificação, sem medição de tempo |
Peça um rascunho pequeno
No estudo de Barke, James e Polikarpova, o modo de exploração aparece quando o programador ainda não sabe como seguir. Aí ele usa a ferramenta pra ver opções. A tela branca cai nesse modo.
Um rascunho grande devolve a trava com outra cara: muito código pra ler antes da primeira decisão. Vamos pedir pouco e deixar de fora, já no pedido, o que o checklist corta depois.
Gere o primeiro rascunho de <o que o projeto faz>, em <linguagem e versão>.
Entregue só: estrutura de pastas, ponto de entrada, uma função do caminho principal e um teste dela.
Não crie abstração nem opção de configuração que eu não pedi.
Não use tratamento de erro genérico que engole a exceção.
Não escreva comentário que repete o código.
Liste cada dependência com nome e versão.O preço aparece na leitura
No estudo de Vaithilingam, os participantes tiveram dificuldade pra entender, editar e depurar o código gerado. Essa dificuldade atrapalhou as tarefas, e todo corte depende de entender o código.
Mesmo assim, prefiro um rascunho ruim a um arquivo vazio. Trecho errado eu corto, e arquivo vazio não me dá nada pra cortar.
Em projeto maduro, o resultado muda. O ensaio controlado randomizado de Becker, Rush, Barnes e Rein sorteou cada uma das 246 tarefas para liberar ou proibir IA. Os 16 desenvolvedores tinham em média 5 anos de experiência nos projetos.
| Momento | Efeito da IA no tempo de conclusão |
|---|---|
| Previsão dos desenvolvedores, antes das tarefas | 24% menor |
| Previsão de especialistas em economia | 39% menor |
| Previsão de especialistas em aprendizado de máquina | 38% menor |
| Estimativa dos desenvolvedores, depois do estudo | 20% menor |
| Medição do estudo | 19% maior |
A ordem da revisão
O rascunho passa por quatro perguntas. Se não consigo explicar o trecho em uma frase, ele sai e pula as outras.
Corte o que você não explica
Corto todo trecho que não consigo explicar em uma frase, mesmo que funcione. A dificuldade apareceu na hora de entender o código.
## Cortar
- [ ] Removi todo trecho que não consigo explicar em uma frase
- [ ] Removi abstração ou opção de configuração que ninguém pediu
- [ ] Removi tratamento de erro genérico que engole a exceção
- [ ] Removi comentário que repete o que o código já dizReescreva o que o modelo não conhece
Na tabela de temas do DORA, alucinação aparece como tema negativo nos dez usos analisados. Alucinação é quando a IA apresenta informação inventada ou incorreta como se fosse verdadeira. Limitação de conhecimento aparece em sete. O texto também diz que ferramentas genéricas têm dificuldade na integração final com sistemas internos.
Regra de negócio e entrada externa dependem do seu domínio, então reescrevo esses trechos mesmo quando parecem certos. Depois, eles passam pelas caixas de Manter. Cada item começa pela condição, e o item marcado continua verdadeiro num rascunho sem regra de negócio.
## Reescrever
- [ ] Se há regra de negócio, reescrevi com os nomes do domínio
- [ ] Se há entrada externa, reescrevi a validação dela
- [ ] Se há segredo ou credencial, movi para variável de ambiente ou vault
- [ ] Se há teste que passa quando a regra muda, reescrevi o testeMantenha só o que você conferiu
Nas respostas do DORA, engenheiros contam que o tempo poupado na escrita foi para a auditoria do código gerado. É percepção, porque a análise é temática e não mede tempo. O texto também diz que verificar é uma tarefa cognitiva diferente de criar. Por isso, pra manter um trecho eu preciso de prova.
## Manter
- [ ] Se há dependência, conferi nome e versão no registro de pacotes
- [ ] Se há configuração repetitiva, conferi contra a documentação oficial
- [ ] Rodei o caminho principal localmente
- [ ] Li cada arquivo que entra no commitFeche o lote antes do commit
No DORA, o protótipo sai quase na hora, mas a etapa final pede precisão, edge cases e integração. Essa etapa pode custar mais que construir tudo à mão desde o início. O texto recomenda lotes pequenos, que dá pra revisar e testar.
O checklist não reduz esse custo de integração. O último bloco só limita o tamanho do lote.
## Antes do commit
- [ ] O diff cabe em uma sessão de revisão
- [ ] Se há testes, eles rodam e falham quando quebro a regra de propósitoQuando a IA ajuda a começar
Nenhum estudo citado compara gerar e cortar com escrever do zero. Uso a IA pra sair do zero porque, pra mim, cortar pesa menos.
| Situação | O fluxo ajuda? | Motivo |
|---|---|---|
| Travei na tela branca e não sei por onde começar | Sim | O rascunho pequeno troca a pergunta aberta por “este trecho fica?” |
| Conheço o projeto e já sei o caminho | Talvez não | No estudo de Becker, desenvolvedores experientes em projetos maduros levaram 19% mais tempo com IA |
| Já tenho o rascunho e quero uma parada antes do commit | Sim | O hook barra o commit até o checklist marcado entrar com o código |
| Quero saber se gerar sai mais barato que escrever | Não | Nenhum estudo citado mede essa troca, e os estudos de Peng e Becker apontam em direções opostas |
| Quero um lote pequeno para revisar | Em parte | O pedido e uma caixa cobrem isso, mas o hook não mede o diff |
| O checklist já entrou num commit | Não | O hook sai com 0 |
Bloqueie o commit sem checklist
Vamos juntar os quatro blocos em REVISAO-RASCUNHO.md, na raiz do repositório. No topo, coloque o título # Revisão do primeiro rascunho gerado por IA. O arquivo fica com 14 caixas.
O hook age enquanto o checklist não existe no HEAD (git). Isso cobre repositório sem commits e repositório criado por scaffold, como o create-next-app. Ele lê a versão do checklist que está no stage. O arquivo no disco não conta.
#!/usr/bin/env bash
set -euo pipefail
readonly CHECKLIST="REVISAO-RASCUNHO.md"
readonly EXPECTED_ITEMS=14
readonly ANY_ITEM='^[[:space:]]*([-*+]|[0-9]+[.)])[[:space:]]+\[.\]'
readonly DONE_ITEM='^[[:space:]]*([-*+]|[0-9]+[.)])[[:space:]]+\[[xX]\]'
if git cat-file -e "HEAD:$CHECKLIST" 2>/dev/null; then
exit 0
fi
if ! git cat-file -e ":$CHECKLIST" 2>/dev/null; then
echo "Commit barrado: adicione $CHECKLIST ao stage antes." >&2
exit 1
fi
other_files="$(git diff --cached --name-only | grep -vxF "$CHECKLIST" || true)"
if [[ -z "$other_files" ]]; then
echo "Commit barrado: o stage tem só $CHECKLIST, adicione o código revisado junto." >&2
exit 1
fi
staged_checklist="$(git show ":$CHECKLIST")"
all_items="$(grep -cE "$ANY_ITEM" <<<"$staged_checklist" || true)"
done_items="$(grep -cE "$DONE_ITEM" <<<"$staged_checklist" || true)"
if (( all_items != EXPECTED_ITEMS || done_items != EXPECTED_ITEMS )); then
echo "Commit barrado: $done_items de $all_items caixas marcadas em $CHECKLIST, esperado $EXPECTED_ITEMS de $EXPECTED_ITEMS" >&2
grep -nE "$ANY_ITEM" <<<"$staged_checklist" | grep -vE '\[[xX]\]' >&2 || true
exit 1
fiSalve o script como pre-commit e instale no repositório. Num diretório sem Git, rode git init antes. Depois, adicione o checklist e o código ao stage no mesmo commit:
cp pre-commit .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit
git add -A
git commit -m "primeiro rascunho revisado"O git cat-file -e "HEAD:$CHECKLIST" falha em repositório sem commits e quando o checklist nunca entrou num commit. Nos dois casos, o hook segue pra verificação. Com : na frente, o git cat-file -e confere a versão do stage, e o git show lê essa versão.
O git diff --cached --name-only lista os arquivos do stage, e o grep -vxF tira o checklist da lista. Lista vazia barra o commit. As duas regex aceitam -, *, + ou número como marcador, com recuo e espaços extras.
O hook conta todas as caixas e as marcadas com x ou X. O commit só passa quando as duas contagens dão 14. O || true existe porque o grep sai com 1 quando não acha nada, e o set -e pararia o script.
Os limites do checklist
O hook não lê o código nem o texto das caixas.
| Caso | O hook barra? |
|---|---|
| Checklist vazio ou com caixas apagadas | Sim |
Caixa aberta com *, +, número ou recuo |
Sim |
| Commit só com o checklist | Sim |
| 14 linhas marcadas sem leitura do código | Não |
| Checklist marcado com um arquivo sem relação com o rascunho | Não |
git commit --no-verify |
Não |
| Commit inicial do scaffold, feito antes da cópia do hook | Não |
| Rascunho novo depois que o checklist entrou num commit | Não |
O scaffold faz o commit dele antes de você copiar o hook, então esse código entra sem checklist. A trava pega o commit seguinte, que traz o rascunho gerado. Depois do commit com o checklist, a trava para de agir e o checklist vira lista manual.
A pasta .git/hooks fica fora do versionamento, então cada repositório precisa da sua cópia do hook. Não coloque o hook no template do git init, configurado em init.templateDir. O git clone também usa esse template, e aí todo repositório sem o checklist no HEAD teria os commits barrados, inclusive clones de terceiros.
As fontes consultadas também têm limites. Os estudos vão do Copilot de 2022 até ferramentas de fevereiro a junho de 2025. O DORA avisa que perguntas anteriores da pesquisa podem ter puxado as respostas para geração de código. O mesmo texto diz que o conflito entre velocidade e qualidade provavelmente diminui com ferramentas mais maduras.
Fontes
- Scheibehenne, Greifeneder e Todd, Can There Ever Be Too Many Options? A Meta-Analytic Review of Choice Overload (Journal of Consumer Research, 2010)
- Vaithilingam, Zhang e Glassman, Expectation vs. Experience: Evaluating the Usability of Code Generation Tools Powered by Large Language Models (CHI 2022)
- Barke, James e Polikarpova, Grounded Copilot: How Programmers Interact with Code-Generating Models
- DORA, Balancing AI tensions: Moving from AI adoption to effective SDLC use
- Becker, Rush, Barnes e Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
- Peng, Kalliamvakou, Cihon e Demirer, The Impact of AI on Developer Productivity: Evidence from GitHub Copilot
Deixe um comentário