Prompts para programação

A IA precisa do contexto certo do software

Um assistente de código vê apenas o que a ferramenta fornece: arquivo aberto, seleção, histórico, documentos anexados ou índice do repositório. Ele pode sugerir uma API inexistente quando versão, framework ou convenção não estão explícitos. Informe linguagem, runtime, bibliotecas principais, sistema operacional quando relevante e comandos de teste.

Inclua os arquivos que definem contratos: tipos, interfaces, schema, configuração e testes próximos. Evite enviar tudo sem necessidade, pois aumenta ruído e exposição. Resuma a arquitetura e indique onde a mudança deve ficar.

Descreva restrições não funcionais: compatibilidade, desempenho, acessibilidade, segurança, observabilidade e proibição de novas dependências. A IA otimiza o que você especifica e pode ignorar o que ficou implícito.

Escreva a tarefa como critérios de aceite

“Crie um login” omite autenticação, sessão, recuperação, ameaça e experiência. Transforme a solicitação em comportamento verificável: entradas válidas e inválidas, autorização, erros, persistência e condição de pronto. Use exemplos de entrada e saída quando houver contrato.

Separe requisitos obrigatórios de preferências. Se a IA encontrar conflito, peça que pare e explique em vez de escolher silenciosamente. Para mudanças grandes, solicite primeiro um plano com arquivos afetados, riscos e testes; aprove antes de editar.

Critérios devem incluir o que não mudar. Compatibilidade e escopo protegem contra refatorações oportunistas que tornam o diff difícil de revisar.

Peça uma mudança pequena e explicável

Mudanças amplas escondem regressões. Divida por unidade entregável: adicionar teste, ajustar função, atualizar chamada e documentar. Peça o menor patch que satisfaz o critério e proíba reformatação não relacionada.

Solicite que o assistente liste suposições e decisões. Uma explicação curta de por que o código está correto é útil; uma narrativa longa não substitui teste. Se a tarefa depende de informação atual de biblioteca, consulte documentação oficial da versão instalada.

Revise o diff, não apenas o arquivo final. Confirme se não foram removidos controles, alterados padrões públicos ou adicionadas dependências. Em times, siga o mesmo processo de revisão aplicado a código humano.

1. Peça análise do problema e plano de arquivos.
2. Confirme suposições e critérios de aceite.
3. Implemente a menor unidade coerente.
4. Execute testes e verificações relevantes.
5. Revise diff, riscos e comportamento não coberto.
6. Repita para a próxima unidade.

Depuração com exemplo mínimo reproduzível

Para diagnosticar, envie a mensagem completa, stack trace, entrada mínima, saída atual, saída esperada, versões e passos para reproduzir. Diga o que já tentou e o que aconteceu. Remova segredos e dados de clientes.

Peça hipóteses ordenadas por evidência e um teste que diferencie cada uma. Isso é melhor do que solicitar uma correção imediata, que pode mascarar o sintoma. Alterar várias coisas ao mesmo tempo destrói informação diagnóstica.

Depois da correção, crie um teste de regressão que falhava antes. Verifique caminhos adjacentes e remova logs temporários. Causa raiz e impacto merecem registro quando o bug atingiu produção.

Testes são parte do prompt, não etapa opcional

Peça testes do comportamento, não apenas cobertura de linhas. Inclua casos felizes, limites, erros, autorização e regressões. Informe framework e padrões existentes. Testes gerados podem reproduzir a mesma suposição errada do código; revise se realmente falham quando o comportamento quebra.

Execute a suíte no ambiente correto. Erros de compilação, lint, tipos, migração e integração não são visíveis em um bloco isolado. Para funções críticas, considere propriedades, fuzzing, testes de concorrência e carga.

Não peça para “garantir 100% de correção”. Defina evidências: testes específicos, análise estática, revisão, benchmark e observação em ambiente controlado.

• Teste de unidade para regras locais.
• Teste de integração para banco, fila, arquivo ou API.
• Teste de contrato para interfaces entre serviços.
• Teste de regressão para falha já observada.
• Teste de segurança para autorização, validação e abuso.
• Teste de desempenho quando latência ou volume fazem parte do requisito.

Segurança e privacidade no código gerado

Peça modelagem de ameaças proporcional: ativos, atores, fronteiras de confiança, entradas não confiáveis e impacto. Exija validação, autorização no servidor, queries parametrizadas, tratamento seguro de arquivos, limites de taxa, logs sem dados sensíveis e mensagens de erro adequadas.

Nunca cole credenciais ou dumps de produção. Use placeholders e dados sintéticos. Se um segredo apareceu na conversa, considere rotação conforme a política. Verifique se a ferramenta usa entradas para treinamento e quais controles empresariais existem.

Prompt injection é relevante quando o software conecta modelo a documentos e ferramentas. Conteúdo recuperado deve ser tratado como dado não confiável; limite permissões, valide argumentos, peça confirmação para ações sensíveis e registre chamadas.

Dependências, APIs e versões

Modelos podem sugerir pacotes inexistentes, APIs obsoletas ou opções de outra versão. Forneça manifest e lockfile relevantes e peça preferência pela biblioteca padrão e dependências existentes. Antes de instalar algo novo, confirme repositório, mantenedor, licença, atividade e vulnerabilidades.

Use documentação oficial para sintaxe atual. Não aceite uma chamada apenas porque compila: verifique semântica, limites, paginação, retries e contrato de erro. Em SDKs de nuvem, confirme região, permissões e custo.

Atualizações exigem changelog, guia de migração e testes. Peça um plano de rollback e não misture migração de versão com nova funcionalidade sem necessidade.

Revisão, refatoração e documentação

Na revisão, informe objetivo e risco. Peça achados priorizados com arquivo, trecho, impacto, evidência e correção. Evite comentários genéricos. Para refatorar, defina comportamento que deve permanecer e crie testes de caracterização antes.

Documentação deve refletir código real. Forneça interfaces, comandos e exemplos executáveis; peça que lacunas sejam marcadas. Verifique se exemplos não expõem tokens nem orientam práticas inseguras.

Um assistente pode explicar código legado e mapear dependências, mas valide por navegação, testes e histórico. Comentários podem estar desatualizados; comportamento executado é a referência operacional.

Fluxo seguro de trabalho

Use a IA como colaboradora sujeita às mesmas barreiras de engenharia: branch, revisão, testes, integração contínua, ambientes separados, observabilidade e rollback. Quanto maior a autonomia para editar ou executar, menores devem ser as permissões e mais fortes os limites.

Não execute comandos que não entende. Leia migrações, scripts de infraestrutura e operações destrutivas. Faça backup e ensaio quando necessário. A responsabilidade pela mudança é de quem a aprova e publica.

1. Defina contexto, escopo e critérios de aceite.
2. Proteja segredos e selecione apenas arquivos necessários.
3. Peça plano e identifique riscos antes do patch.
4. Implemente em unidades pequenas.
5. Execute testes, lint, tipos e análise de segurança.
6. Revise diff, dependências e documentação.
7. Implante de forma controlada, monitore e mantenha rollback.