IA para pensar projeto: perguntas antes do primeiro commit

Se você tem 30 segundos (TL;DR)

• Usar IA para pensar projeto pode render mais quando a IA pergunta e você responde, antes de qualquer linha de código.
• A resposta pronta escolhe o usuário, o escopo e a stack por você, com base em um contexto que o modelo não tem.
• O roteiro abaixo tem 4 blocos de perguntas e uma regra que manda a IA refutar resposta fraca.
• A saída é um DECISOES.md curto, com trechos seus citados e gaps marcadas como [ABERTO], e ele vira a instrução do primeiro commit.

O que a resposta pronta decide

Um pedido como “crie um app de controle de gastos” tem dezenas de gaps. O modelo precisa preencher cada uma para devolver algo coerente. Ele escolhe quem usa e como usa o app, quais telas existem e em que linguagem tudo roda.

Cada gap preenchido é uma decisão que você não tomou. Ela chega com cara de plano, bem formatada e confiante. Você só descobre que discorda dela semanas depois, quando o código já depende dela. Quem usa IA para pensar projeto desse jeito recebe as decisões prontas.

Modelos de linguagem também tendem a concordar com quem pergunta. Sharma e colegas mediram esse viés em 2023: cinco assistentes de IA mostraram sycophancy de forma consistente em quatro tarefas de texto livre. O mesmo estudo mostra que humanos e modelos de preferência às vezes preferem a resposta que concorda à resposta correta. Uma ideia fraca recebe um plano forte, e o plano esconde a fraqueza da ideia.

Em inglês comum, sycophancy é bajulação: puxar o saco, concordar com quem tem poder pra agradar ou ganhar alguma coisa. O sycophant é o bajulador.

A linha do meio engana mais. Você escolhe, mas escolhe dentro de um cardápio que outro montou.

Pedir código no primeiro prompt de um projeto novo transforma essas lacunas em arquivos antes de você decidir qualquer uma delas. Eu não peço código antes de ter o problema escrito com as minhas palavras.

A entrevista socrática

É uma entrevista conduzida pelo método de Sócrates: em vez de fazer perguntas soltas e anotar respostas, o entrevistador encadeia perguntas que partem do que a pessoa acabou de dizer e vão cavando até chegar no raciocínio por trás.

A entrevista socrática funciona como a prova de roupa no alfaiate. Ele pergunta e mede, e cada medida que você confirma vira um corte no tecido. Já o terno comprado pronto da loja, vem cortado com as medidas de outra pessoa.

Ao usar IA para pensar projeto, o mecanismo é o mesmo. O modelo faz uma pergunta, você responde, e a resposta confirmada vira uma linha do arquivo de decisões. O modelo não corta nada sozinho.

A ordem dos blocos tem motivo. Cada bloco usa as respostas do anterior. Limite sem usuário definido vira chute, e entregável sem limite vira lista de desejos.

O diagrama separa resposta vaga de “não sei”. A resposta vaga tenta responder e não cabe em uma linha, então a IA reformula a pergunta. O “não sei” admite o gap e diz o que falta para fechar ela, por exemplo uma conversa com a pessoa do bloco 2.

Uma pergunta aberta deixa o bloco seguir só quando o critério de saída do bloco continua atendido sem ela. Se o gap derruba o critério, o bloco para até você ter a resposta.

Configure a IA para perguntar

O modelo volta para o modo resposta com facilidade. Para usar IA para pensar projeto, a instrução base precisa proibir sugestões de forma explícita e mandar a IA refutar. Cole isto no início da conversa, ou no system prompt da ferramenta que você usa:

Você vai me entrevistar sobre uma ideia de projeto.
Regras:
1. Faça uma pergunta por vez. Espere minha resposta.
2. Não sugira solução, stack, nome, arquitetura ou recurso.
3. Se minha resposta for vaga, pergunte de novo com outras palavras.
   Se eu disser "não sei", anote a pergunta como [ABERTO],
   com o que falta para responder, e siga.
4. Se eu pedir sugestão, não dê opções. Pergunte qual critério
   eu uso para decidir e quais opções eu ja conheço.
5. Siga os blocos na ordem: problema, usuário, limites,
   primeiro entregável.
6. Ao fim de cada bloco, liste cada resposta minha como citação
   literal entre aspas, uma por linha, e peça confirmação.
7. Não passe para o próximo bloco sem minha confirmação.
8. Não elogie nem concorde com minhas respostas. Se uma resposta
   contradiz outra, não responde a pergunta ou não atende o
   critério de saída, aponte o trecho e pergunte de novo.

A regra 4 mantém a última linha da tabela verdadeira. Quando você pede ajuda, a IA devolve uma pergunta sobre critério, e as opções saem de você.

A regra 8 ataca a concordância que o estudo de Sharma e colegas descreve. Sem ela, uma resposta fraca atravessa os 4 blocos com o mesmo aval.

A regra 6 troca memória por busca. Cada trecho entre aspas precisa existir no chat. Um sinônimo fora das aspas não muda o plano, então deixe passar. Corrija o trecho que acrescenta público, recurso ou restrição que você não citou.

Defina o problema

O primeiro bloco da entrevista de IA para pensar projeto separa o problema da solução. Muita ideia chega como solução disfarçada: “um app que faz X”. O bloco só termina quando você descreve a dor sem citar o app.

BLOCO 1 - PROBLEMA
Minha ideia, em uma frase: {cole aqui}

Me pergunte, uma de cada vez:
- Qual situação concreta dispara esse problema?
  Quando foi a última vez que ela aconteceu?
- O que a pessoa faz hoje para contornar?
- O que custa nao resolver: tempo, dinheiro ou erro?
- Como eu sei que o problema sumiu?

Critério de saída: eu consigo descrever o problema
sem citar a solução.

Se o contorno é uma planilha que já funciona, o projeto precisa ganhar da planilha.

Defina o usuário

O segundo bloco troca “as pessoas” por uma pessoa. Usuário genérico aceita qualquer recurso, e por isso não ajuda a cortar nenhum.

BLOCO 2 - USUARIO
Me pergunte, uma de cada vez:
- Quem sente o problema primeiro?
  Nome de uma pessoa real, se existir.
- Essa pessoa decide usar, ou outra pessoa decide por ela?
- Em que momento do dia ela encontra o problema?
- Que ferramenta ela já tem aberta nesse momento?

Criterio de saída: eu consigo apontar uma pessoa
para testar a primeira versão.

A última pergunta define mais arquitetura do que parece. Se a pessoa está no celular, dentro do WhatsApp, um sistema web com login já começa atrás. Essa é a informação que a IA para pensar projeto precisa ouvir de você, sem achismo.

Declare os limites

O terceiro bloco é o que a resposta pronta mais ignora. O modelo não sabe quantas horas você tem nem quando você desiste. Sem essa informação, ele planeja para uma equipe que não existe. Na IA para pensar projeto, você entrega esses números antes que o modelo invente os dele.

BLOCO 3 - LIMITES
Me pergunte, uma de cada vez:
- Quantas horas por semana eu tenho para este projeto?
- Em que data eu paro, se nada funcionar ate la?
- O que este projeto NÃO faz na primeira versão?
- Que tecnologia eu já domino e vou usar?
- Tem dado pessoal, dinheiro ou login envolvido?

Critério de saída: eu tenho uma lista "não faz"
e uma data de parada escrita.

A lista “não faz” protege o bloco 4. Cada item dela é uma conversa futura que você não precisa ter com a IA nem com você mesmo.

Um projeto novo com stack nova e problema novo acumula duas incógnitas. Prefiro fixar a stack que já domino e deixar a dúvida só no problema. Muita gente discorda, porque projeto pessoal também serve para aprender. Os dois objetivos são válidos, mas escolha um deles de forma explícita no bloco 3.

Escolha o primeiro entregável

O último bloco do roteiro de IA para pensar projeto converte tudo em uma coisa pequena e testável. Ele usa a pessoa do bloco 2 e os limites do bloco 3 como filtro.

BLOCO 4 - PRIMEIRO ENTREGAVEL
Me pergunte, uma de cada vez:
- Qual e a menor coisa que a pessoa do bloco 2
  consegue usar de verdade?
- Ela cabe nas horas de uma semana do bloco 3?
- Que ação da pessoa mostra que funcionou?
- Qual e a mensagem do primeiro commit?

Critério de saída: o entregável cabe em uma frase
e tem um teste de aceite.

A mensagem do primeiro commit é um teste de clareza. Se você não consegue escrever essa mensagem, o entregável ainda é vago.

O arquivo de decisões

A entrevista de IA para pensar projeto termina em um arquivo. Peça para a IA montar o rascunho, mas com uma restrição: ela só pode copiar trechos das suas respostas, e o que ficou sem resposta aparece marcado.

Monte o DECISOES.md com o modelo abaixo.
Copie trechos das minhas respostas, entre aspas.
Se um campo ficou sem resposta, escreva [ABERTO]
e o que falta para responder.
Não preencha nenhum campo com sugestão sua.

# DECISOES.md

## Problema
- Situação que dispara:
- Contorno atual:
- Custo de não resolver:
- Sinal de que o problema sumiu:

## Usuário
- Pessoa:
- Quem decide usar:
- Momento do dia:
- Ferramenta já aberta:

## Limites
- Horas por semana:
- Data de parada:
- Não faz na primeira versao:
  -
- Stack:
- Dado sensível (pessoal, dinheiro, login):

## Primeiro entregável
- Frase:
- Teste de aceite:
- Mensagem do primeiro commit:

## Em aberto
- [ABERTO] {pergunta} - falta: {o que responde ela}

A seção “Em aberto” guarda só o “não sei” declarado, com o que falta para responder. Resposta vaga não entra nela, porque a regra 3 manda a IA perguntar de novo. Um gap marcado mostra o que você ainda não sabe. Um gap preenchido pela IA esconde isso.

O arquivo também serve depois. Ele entra como contexto na primeira sessão de código, e aí a IA pode propor soluções. Nessa hora, as decisões já têm dono.

Sinais de que a entrevista falhou

Uma sessão de IA para pensar projeto escorrega para o modo resposta sem aviso. Estes sinais aparecem no próprio chat:

Prefiro uma IA que me irrita com a quinta pergunta sobre o usuário a uma que me agrada com um plano de 12 telas no primeiro minuto. A pergunta chata me obriga a decidir. O plano bonito já decidiu, e decidiu com as medidas de outra pessoa.

Fontes

• Sharma et al., Towards Understanding Sycophancy in Language Models (arXiv, 2023)