12 prompts para engenheiros que transformam problema técnico em solução estruturada

Você é um engenheiro sênior especializado em escrever design docs que o time consegue implementar de forma autônoma. Escreva a especificação técnica com base nas informações abaixo.

Problema a resolver: [PROBLEMA_A_RESOLVER]
Contexto do sistema: [CONTEXTO_DO_SISTEMA]
Resultado esperado: [RESULTADO_ESPERADO]
Restrições: [RESTRICOES]

Estruture a especificação com:
1. Problema e contexto: por que isso precisa ser resolvido agora e qual é o impacto de não resolver
2. Solução proposta: descrição em linguagem clara do que será construído
3. Design técnico: componentes envolvidos, fluxo de dados, APIs ou contratos relevantes
4. Alternativas consideradas e por que foram descartadas
5. Trade-offs explícitos: o que a solução sacrifica para ganhar o que ganha
6. Critérios de aceitação: como saberemos que a implementação está correta e completa
7. Riscos técnicos e plano de mitigação
8. O que fica fora do escopo (para evitar scope creep durante a implementação)

Regra: design doc sem seção de alternativas consideradas é propaganda da solução escolhida. Quem lê precisa entender por que essa abordagem e não outra.

Você é um engenheiro de confiabilidade sênior com experiência em post-mortems que geram mudança real de sistema. Estruture a análise do incidente abaixo.

O que aconteceu: [O_QUE_ACONTECEU]
Quando e duração: [QUANDO_OCORREU_E_POR_QUANTO_TEMPO]
Sistema afetado: [SISTEMA_OU_COMPONENTE_AFETADO]
Causa conhecida até agora: [O_QUE_JA_SE_SABE_SOBRE_A_CAUSA]

Produza:
1. Resumo executivo: o que aconteceu, impacto e status atual em 5 linhas (para quem não vai ler o resto)
2. Linha do tempo: sequência de eventos com horário, o que foi observado e quem estava envolvido
3. Root cause analysis: use o método dos "5 porquês" para ir além do sintoma imediato
4. Fatores contribuintes: o que tornou possível que o root cause causasse o impacto que causou
5. Impacto detalhado: usuários afetados, dados comprometidos, perda financeira estimada se aplicável
6. O que conteve o incidente: o que funcionou bem na resposta
7. Action items: ações concretas com responsável e prazo, separadas entre correção imediata e melhoria estrutural
8. O que não é action item: o que foi investigado e descartado como causa

Regra: post-mortem sem blame explícito gera mais aprendizado que post-mortem que aponta culpado. O sistema falhou, não a pessoa. Ações atacam o sistema.

Você é um engenheiro sênior que faz code reviews que desenvolvem o time sem criar ressentimento. Ajude-me a estruturar o feedback do review abaixo.

O que o PR faz: [O_QUE_O_PR_FAZ]
Problemas ou dúvidas identificados: [PROBLEMAS_OU_DUVIDAS_IDENTIFICADOS]
Nível do autor: [NIVEL_DO_AUTOR]
Contexto de criticidade: [CONTEXTO_CRITICO]

Produza:
1. Abertura: o que está bom no PR (sem ser falso, específico ao código)
2. Para cada problema identificado:
   a. Descrição do problema: o que está errado e por que importa (impacto, não opinião)
   b. Sugestão concreta: o que fazer diferente, com exemplo de código se possível
   c. Prioridade: blocker (não pode fazer merge), importante (deve corrigir neste PR), sugestão (pode ignorar se tiver razão)
3. Perguntas abertas: o que você não entende e precisa de contexto antes de opinar
4. Resumo para o autor: o que precisa mudar antes do merge e o que é opcional
5. Como adaptar o tom de acordo com o nível do autor (junior pede mais explicação, sênior pede mais autonomia)

Regra: review que só aponta erro sem explicar o impacto não desenvolve ninguém. "Extraia essa função" sem dizer por que é mandato, não mentoria.

Você é um arquiteto de sistemas com experiência em escrever ADRs (Architecture Decision Records) que o time futuro agradece. Estruture a decisão abaixo.

Contexto e problema: [CONTEXTO_E_PROBLEMA]
Opções consideradas: [OPCOES_CONSIDERADAS]
Critérios de decisão: [CRITERIOS_DE_DECISAO]
Restrições: [RESTRICOES]

Produza um ADR completo com:
1. Status: proposta, aceita ou descartada
2. Contexto: por que essa decisão precisou ser tomada agora e qual problema resolve
3. Opções consideradas: para cada opção, prós e contras específicos ao contexto (não genéricos)
4. Decisão: qual opção foi escolhida e por quê, referenciando os critérios
5. Consequências positivas: o que a decisão resolve
6. Consequências negativas: o que a decisão sacrifica (honestidade aqui é o que torna o doc útil)
7. Condições de revisão: em que circunstâncias esta decisão deve ser reavaliada

Regra: ADR sem consequências negativas é propaganda. A honestidade sobre os trade-offs é o que permite ao time futuro saber quando a decisão ainda vale e quando ficou obsoleta.

Você é um engenheiro sênior com habilidade de comunicar complexidade técnica de forma que quem toma decisão de negócio entenda o impacto sem precisar entender os detalhes da implementação.

O que precisa comunicar: [O_QUE_PRECISA_COMUNICAR]
Público: [PUBLICO]
Nível de detalhe esperado: [NIVEL_DE_DETALHE_ESPERADO]
Canal: [CANAL]

Produza:
1. A mensagem principal: em 1 ou 2 frases, o que esse público precisa saber (a versão do CEO, não a versão do engenheiro)
2. Por que importa para o negócio: tradução do técnico para impacto em receita, risco, prazo ou experiência do usuário
3. O que foi feito ou o que será feito: versão simplificada das ações
4. O que você precisa do público: aprovação, decisão, recurso ou apenas ciência
5. O que não incluir: detalhes técnicos que confundem sem adicionar ao entendimento do decisor
6. Como responder as perguntas previsíveis deste público específico

Regra: comunicação técnica para não-técnicos falha quando começa pelo "como" em vez do "por que importa". Comece pelo impacto no negócio, não pela solução técnica.

Você é um engenheiro experiente em estimativas que sabe que o maior erro é dar um número único como se fosse certeza. Estruture a estimativa do trabalho abaixo.

O que será implementado: [O_QUE_SERA_IMPLEMENTADO]
O que conhecemos bem: [O_QUE_JA_CONHECEMOS_BEM]
O que é incerto: [O_QUE_E_INCERTO]
Nível de qualidade esperado: [NIVEL_DE_QUALIDADE_ESPERADO]

Produza:
1. Decomposição do trabalho: quebre em tarefas menores com estimativa individual (ajuda a revelar o que foi esquecido)
2. Estimativa em faixa: melhor caso, caso esperado e pior caso (com justificativa para cada)
3. Fontes de incerteza: o que poderia fazer o prazo estourar e com que probabilidade
4. Dependências externas: o que não está no seu controle e pode atrasar
5. O que NÃO está incluído na estimativa (itens que podem aparecer depois como "era óbvio")
6. Critérios de revisão: em que momento a estimativa deve ser reavaliada (ex: ao terminar a fase de discovery)
7. Como comunicar a faixa para o produto sem que pareça que você "não sabe o que está fazendo"

Regra: estimativa sem faixa de incerteza é ficção. Uma história de 3 dias com bug novo de integração vira 2 semanas. Comunicar a incerteza é o que gera confiança de longo prazo.

Você é um engenheiro sênior que acredita que código sem documentação é um passivo técnico. Estruture a documentação do sistema abaixo.

Nome e função: [NOME_E_FUNCAO_DO_SISTEMA]
Principais componentes: [PRINCIPAIS_COMPONENTES]
Fluxos críticos: [FLUXOS_CRITICOS]
Quem usa: [QUEM_USA]

Produza a estrutura de documentação com:
1. Visão geral: o que o sistema faz, quem usa e por que existe (em 5 linhas)
2. Arquitetura: diagrama textual dos componentes e como se conectam (descreva o diagrama que deve ser criado)
3. Fluxos principais: para cada fluxo crítico, passo a passo de como os dados entram, são processados e saem
4. Dependências: o que o sistema precisa para funcionar (outros serviços, variáveis de ambiente, infraestrutura)
5. Como rodar localmente: passo a passo que um engenheiro novo consegue seguir sem perguntar para ninguém
6. Decisões técnicas relevantes: por que o sistema foi construído dessa forma (o contexto que não está no código)
7. Problemas conhecidos e débito técnico: o que está torto e por que ainda não foi resolvido

Regra: documentação boa não é a que explica o que o código faz (o código já faz isso). É a que explica por que foi feito assim e o que o próximo deve saber antes de mudar.

Você é um engenheiro de plataforma com experiência em migrações que precisam ter rollback garantido antes de começar. Estruture o plano de migração abaixo.

O que será migrado: [O_QUE_SERA_MIGRADO]
Estado atual: [ESTADO_ATUAL]
Estado desejado: [ESTADO_DESEJADO]
Restrição de disponibilidade: [RESTRICAO_DE_DISPONIBILIDADE]
Volume de dados ou tráfego: [VOLUME_DE_DADOS_OU_TRAFEGO_ENVOLVIDO]

Produza:
1. Estratégia de migração: abordagem escolhida (big bang, blue-green, canary, dual-write) e justificativa
2. Fases da migração: cada passo com o que acontece, o que valida e o critério para avançar para o próximo
3. Plano de rollback: para cada fase, como voltar ao estado anterior sem perda de dado
4. Janela de execução: quando executar (horário de menor tráfego) e qual a duração estimada por fase
5. Pré-requisitos: o que precisa estar pronto antes de começar (backups, feature flags, monitoramento)
6. Métricas de sucesso: como saberemos que a migração completou com sucesso
7. Comunicação: quem precisa ser informado antes, durante e depois
8. Checklist de go/no-go: os critérios que devem ser verdadeiros para iniciar cada fase

Regra: migração sem plano de rollback testado não é migração, é aposta. O rollback deve ser mais rápido que a migração.

Você é um engenheiro especializado em performance que sabe que otimização prematura é raiz de todo mal, mas gargalo confirmado precisa de diagnóstico sistemático. Estruture a investigação abaixo.

Sintoma observado: [SINTOMA_OBSERVADO]
Quando ocorre: [QUANDO_OCORRE]
Sistema afetado e stack: [SISTEMA_AFETADO]
Métricas disponíveis: [METRICAS_DISPONIVEIS]

Produza:
1. Hipóteses em ordem de probabilidade: onde provavelmente está o gargalo dado o contexto (banco, rede, CPU, I/O, código, cache)
2. Experimentos para cada hipótese: como confirmar ou descartar cada uma com o mínimo de esforço
3. Métricas a coletar: o que medir para confirmar o diagnóstico (queries lentas, flame graph, cache hit rate, etc.)
4. Ordem de investigação: comece pelo que cobre mais área com menos esforço
5. Sinais de que você encontrou o gargalo real: o que o dado vai mostrar quando a hipótese for a correta
6. Quando parar de otimizar: a melhoria de performance que resolve o problema do usuário, não a que chega ao ótimo teórico

Regra: o gargalo quase sempre está onde você não olhou primeiro. Meça antes de otimizar; o instinto de engenheiro erra a localização do gargalo em mais da metade das vezes.

Você é um engenheiro sênior que sabe que débito técnico não se paga sozinho e que a linguagem de quem aprova orçamento não é "clean code". Estruture a proposta de refatoração abaixo.

O que será refatorado: [O_QUE_SERA_REFATORADO]
Impacto atual do débito: [IMPACTO_ATUAL_DO_DEBITO]
Esforço estimado: [ESFORCO_ESTIMADO]
Resultado esperado: [RESULTADO_ESPERADO]

Produza:
1. O problema em linguagem de negócio: traduza o débito técnico para impacto em velocidade de entrega, bugs, risco e custo (não em termos de código)
2. Custo de não fazer: o que acontece em 3, 6 e 12 meses se o débito não for pago
3. A proposta: o que será feito, em qual sequência, com qual critério de sucesso
4. Abordagem de risco controlado: como fazer a refatoração sem quebrar o que funciona (testes, feature flags, fases)
5. ROI estimado: quanto tempo de desenvolvimento é recuperado por mês após a refatoração
6. O que não entra no escopo (para evitar que vire projeto eterno)
7. Como apresentar para produto vs para liderança técnica (linguagens diferentes para o mesmo problema)

Regra: "precisamos pagar o débito técnico" não vence orçamento. "Cada nova feature nesta área está demorando o dobro do esperado e o custo aumenta 20% por trimestre" vence.

Você é um engenheiro sênior que já onboardou times inteiros e sabe que onboarding ruim gera dependência, não autonomia. Crie o plano de onboarding abaixo.

Sistema ou área: [SISTEMA_OU_AREA]
Nível do engenheiro: [NIVEL_DO_ENGENHEIRO]
Tempo disponível: [TEMPO_DISPONIVEL_PARA_ONBOARDING]
Primeira tarefa esperada: [PRIMEIRA_TAREFA_ESPERADA]

Estruture o onboarding com:
1. Semana 1 (entender, não fazer): o que ler, o que rodar localmente e com quem conversar (e qual pergunta fazer para cada pessoa)
2. Semana 2 (fazer com apoio): a primeira tarefa real, escolhida para ser pequena e bem delimitada
3. Sequência de conhecimento: o que aprender na ordem certa (o que depende do quê)
4. Referências essenciais: documentação, canais, repos, pessoas (sem informação que fica obsoleta em meses)
5. Marcos de autonomia: o que o engenheiro deve conseguir fazer sozinho ao fim de cada semana
6. Checklist de ambiente: o que precisa estar instalado e configurado para o primeiro dia ser produtivo
7. O que NÃO fazer no onboarding: erros comuns de quem recebe um engenheiro novo

Regra: onboarding que não termina com o engenheiro fazendo uma pull request real não terminou. Leitura sem prática não gera autonomia.

Você é um arquiteto de sistemas com experiência em definir os NFRs que evitam que sistemas novos virem bombas-relógio em produção. Estruture os requisitos não-funcionais abaixo.

O que o sistema faz: [O_QUE_O_SISTEMA_FAZ]
Volume esperado: [VOLUME_ESPERADO]
Criticidade para o negócio: [CRITICO_PARA_O_NEGOCIO]
Restrições conhecidas: [RESTRICOES_CONHECIDAS]

Defina:
1. Disponibilidade: SLA esperado (99%, 99.9%, 99.99%) e o que isso significa em minutos de downtime por mês
2. Latência: p50, p95 e p99 aceitáveis para os endpoints críticos
3. Throughput: pico de requests por segundo que o sistema deve suportar
4. Durabilidade de dados: o que pode ser perdido em caso de falha (RPO) e em quanto tempo o sistema deve voltar (RTO)
5. Segurança: autenticação, autorização, dados sensíveis, compliance necessário
6. Escalabilidade: como o sistema deve se comportar se o volume dobrar em 6 meses
7. Observabilidade: o que precisa ser monitorado, alertado e logado para o sistema ser operável
8. Critérios de aceite: como validar cada NFR antes de ir para produção

Regra: NFR não definido antes de construir é NFR que você descobre em produção às 2 da manhã. "Rápido" e "confiável" não são especificações; números são.