Como usar IA para programar: fluxos que reduzem o risco

Regras para pedir ajuda de IA com segurança

A melhor forma de usar IA para programar é deixá-la mais lenta exatamente nos momentos em que chutar é perigoso. A IA consegue explicar código desconhecido, transformar erros em hipóteses, rascunhar testes, revisar diffs e sugerir refatorações. Ela também consegue inventar APIs, ignorar dependências ocultas, se apegar demais ao trecho que você colou ou produzir um patch que parece limpo enquanto muda um comportamento que você queria preservar.

Use esta regra: a IA propõe, o seu repositório decide. A fonte da verdade é o código, a reprodução que falha, a suíte de testes, os logs de execução, os requisitos do produto e a revisão humana. Um bom parceiro de programação com IA deve ajudar você a raciocinar a partir desses artefatos em vez de substituí-los.

Regra	Por que importa	O que pedir ao modelo
Reproduza primeiro	Evita patches aleatórios	"Reformule o comportamento com falha e as evidências antes de sugerir código."
Mantenha o escopo pequeno	Reduz o risco de regressão	"Proponha a menor mudança segura e liste os arquivos afetados."
Preserve o comportamento	Protege usuários e contratos	"Diga quais invariantes esta mudança não pode quebrar."
Exija testes	Torna a resposta verificável	"Escreva testes que falham antes da correção e passam depois."
Revise antes do merge	Pega erros ditos com confiança	"Revise este diff quanto a correção, segurança e casos extremos faltando."

Isso vale para qualquer modelo. OpenAI, Anthropic e outros provedores publicam documentação que descreve capacidades, janelas de contexto e padrões de uso de ferramentas diferentes. Essas capacidades são úteis, mas não substituem um fluxo de trabalho disciplinado. Para trabalho de engenharia, avalie os modelos pelo mesmo critério que você usaria com alguém do time: eles pedem o contexto que falta, reduzem a incerteza, respeitam restrições e deixam um rastro que você consegue verificar?

Fluxo de trabalho para depuração

Um fluxo confiável de depuração com IA tem cinco etapas: reproduzir, isolar, levantar hipóteses, corrigir e verificar. Não comece com "conserta isso". Comece pela evidência. Dê ao modelo o comando que falha, o erro exato, o comportamento esperado, o comportamento observado, o código relevante, os detalhes do ambiente e qualquer mudança recente que possa ter causado o problema.

Etapa 1: capture a reprodução. Para código de backend, inclua a requisição, a resposta, o status code, os logs e o teste que falha. Para código de frontend, inclua a rota, a ação do usuário, o erro no console do navegador, a resposta de rede, o estado do componente e a descrição de uma captura de tela, se for relevante. Para problemas de build, inclua o comando, o gerenciador de pacotes, a versão do Node e o erro completo em volta da primeira falha.

Etapa 2: peça hipóteses antes de código. Um modelo cuidadoso deve ranquear as causas prováveis e dizer que evidência sustenta cada uma. Se ele não conseguir distinguir entre as causas, peça o menor passo de diagnóstico possível. Pode ser um log, um teste focado, uma checagem de tipos ou a leitura de mais um arquivo.

Etapa 3: peça o menor patch possível. Diga ao modelo para não renomear variáveis, não reescrever o código ao redor, não introduzir dependências e não mudar o comportamento público sem justificar o motivo. Peça que ele devolva a causa raiz, o esboço do patch, os arquivos afetados, os testes e o risco.

Etapa 4: rode os testes localmente. A saída da IA não é uma etapa de verificação. A verificação é o comando ou o caminho do usuário que prova o comportamento. Se não existir teste automatizado, peça ao modelo que crie primeiro um teste de regressão e só depois implemente a correção.

Prompt de depuração:

Atue como um parceiro cuidadoso de depuração. Ainda não escreva código. Primeiro, reformule a reprodução, o comportamento esperado, o comportamento observado e as três causas raiz mais prováveis. Ranqueie cada causa pela evidência. Depois sugira o menor passo de diagnóstico. Bug: [descreva]. Comando ou ação do usuário: [cole]. Erro/logs: [cole]. Código relevante: [cole]. Restrições: [stack, arquivos que não devem ser tocados, comportamento a preservar].

Prompt de correção:

Com a causa raiz confirmada, proponha a menor correção segura. Retorne: causa raiz, arquivos/funções a mudar, esboço do patch, testes que falham antes e passam depois, casos extremos e risco de rollback. Não refatore código não relacionado. Contexto: [cole].

Fluxo de trabalho para revisão de código

Muitas vezes a IA rende mais como revisora do que como primeira autora. Quando você pede que ela revise um diff, ela consegue procurar casos extremos esquecidos, problemas de segurança, suposições desatualizadas, lacunas de teste e mudanças de comportamento. O segredo é deixar a revisão específica. Se você perguntar "isso está bom?", vai receber uma aprovação educada. Se pedir o risco de correção, é bem mais provável receber objeções úteis.

Dê ao modelo o diff, o comportamento pretendido, os testes relacionados e quaisquer restrições. Peça que ele ignore estilo menor, a não ser que afete a manutenibilidade. Você quer que a revisão priorize bugs, não implicância de fachada.

Área da revisão	Perguntas que a IA deve responder
Correção	O diff realmente atende ao requisito?
Risco de regressão	Que comportamento existente pode mudar sem querer?
Segurança	Entradas, autenticação, segredos, permissões e riscos de injeção estão tratados?
Tratamento de erros	O que acontece com nulos, timeouts, retentativas, respostas ruins ou estado parcial?
Testes	Quais afirmações de comportamento ficaram sem cobertura?
Manutenibilidade	Isso segue os padrões locais e mantém a mudança compreensível?

Prompt de revisão de código:

Revise este diff como um mantenedor rigoroso, mas prático. Foque em correção, risco de regressão, segurança, casos extremos e testes faltando. Ignore estilo menor, a menos que ele crie risco real de manutenção. Retorne uma tabela com problema, prioridade, evidência do diff, correção sugerida e teste necessário. Comportamento pretendido: [cole]. Diff: [cole]. Testes existentes: [cole].

Para mudanças de alto risco, use um fluxo de comparação de correções entre modelos no Whizi. Rode o mesmo prompt de revisão em dois ou três modelos. Se um modelo apontar um possível problema, não aceite de olhos fechados: verifique se o problema é real no código. O objetivo não é colecionar mais opiniões. O objetivo é ampliar a superfície de revisão antes do merge.

Fluxo de trabalho para refatoração e testes

Refatorar com IA é arriscado porque muitas refatorações são julgadas pelo que não muda. O modelo pode deixar o código mais bonito enquanto altera sutilmente o comportamento, o tratamento de erros, o tempo de execução ou os contratos públicos. Um fluxo de refatoração mais seguro começa definindo os invariantes antes de encostar na implementação.

Passo 1: descreva o objetivo da refatoração. Exemplos: reduzir duplicação, quebrar um componente grande, isolar o acesso a dados, simplificar condicionais, migrar um wrapper de API ou melhorar a testabilidade. Depois diga o que precisa continuar igual: assinaturas de funções públicas, comportamento das rotas, nomes de eventos, formatos de resposta, analytics, permissões, comportamento de acessibilidade e expectativas de desempenho.

Passo 2: peça um plano em etapas. Um bom plano de refatoração com IA deve ser reversível. Cada etapa deve mexer em uma área pequena, incluir testes e produzir um estado intermediário funcionando. Evite reescritas de uma tacada só, a menos que o código seja minúsculo e bem coberto por testes.

Passo 3: escreva testes de caracterização. Antes de mudar o código, peça à IA que identifique o comportamento atual e rascunhe testes que travem os casos importantes. Esses testes são especialmente úteis em código legado, onde a intenção não está clara. Eles devem incluir entradas normais, entradas de fronteira, caminhos de falha e um caso de regressão ligado ao motivo da refatoração.

Passo 4: implemente uma etapa por vez. Depois de cada etapa, rode os testes e peça uma revisão focada. Se o modelo propuser uma abstração ampla, faça com que ele prove que a abstração remove duplicação ou risco de verdade. Caso contrário, mantenha o código sem graça e local.

Prompt de planejamento de refatoração:

Crie um plano de refatoração em etapas. Objetivo: [objetivo]. Código atual: [cole]. Restrições: preservar o comportamento público, minimizar mudanças desnecessárias, seguir os padrões existentes, evitar novas dependências, manter toda etapa testável. Retorne: invariantes, mapa de dependências, etapas, arquivos afetados, testes por etapa, risco de rollback e lista de verificação para a revisão.

Prompt de testes unitários:

Escreva testes antes de mudar a implementação. Use o estilo de teste existente mostrado aqui: [cole]. Comportamento a preservar: [cole]. Código sob teste: [cole]. Retorne nomes dos testes, setup, entrada, resultado esperado e por que cada teste importa. Inclua caminho feliz, caso de fronteira, caso de erro e caso de regressão.

Modelos de prompt

Prompts fortes para programação não são longos porque são sofisticados. Eles são longos o bastante para eliminar a ambiguidade. O modelo precisa de papel, tarefa, contexto, restrições, formato de saída e critérios de verificação. Salve os prompts que funcionam para que a IA vire um fluxo de engenharia repetível, em vez de uma conversa isolada.

Prompt de explicação de código:

Explique este código para um desenvolvedor que está entrando no projeto. Cubra propósito, entradas, saídas, fluxo de dados, dependências, modos de falha e testes que aumentariam a confiança. Separe os fatos visíveis no código das suposições. Código: [cole].

Prompt de código seguro:

Revise este código quanto a riscos de segurança. Foque em autenticação, permissões, injeção, segredos, validação, redirecionamentos inseguros, manipulação de arquivos, risco de dependências e exposição de dados sensíveis. Retorne apenas problemas com evidência, impacto, correção sugerida e teste ou checagem manual. Código/diff: [cole].

Prompt para comparar correções entre modelos:

Estou comparando modelos de IA para uma tarefa de programação. Use apenas o contexto fornecido. Retorne causa raiz, menor correção segura, testes, riscos, suposições e perguntas. Dê uma nota de confiança de 1 a 5 e liste que evidência mudaria a sua resposta. Tarefa: [cole]. Contexto: [cole].

Lista de verificação de QA antes de aceitar código gerado por IA:

• O modelo reformulou a tarefa corretamente.
• O patch é menor que o problema, não maior.
• O comportamento público e os contratos estão nomeados.
• Os testes cobrem diretamente o bug ou o objetivo da refatoração.
• Os casos extremos e os caminhos de falha estão listados.
• As entradas sensíveis à segurança foram revisadas.
• O diff segue os padrões existentes do projeto.
• Você rodou o teste, o lint, o build ou a reprodução manual pertinentes.
• Uma pessoa revisou o diff final.

O Whizi é útil quando você quer comparar correções sem mudar a tarefa. Cole o mesmo prompt de depuração ou de revisão em vários modelos e depois pontue os resultados por evidência, escopo, testes e risco. Comece pelas alternativas ao ChatGPT para programar se quiser um guia de escolha de modelo, compare planos em preços ou crie uma conta para rodar o fluxo no seu próprio código.