"Meus Prompts Favoritos", de Jeffrey Emanuel Prompt 4: O Otimizador de Cérebro Grande "Primeiro, leia TODOS os arquivos AGENTS dot md e README dot md com muita atenção e entenda TODOS os dois! Depois, use seu modo agente de investigação de código para entender completamente o código, a arquitetura técnica e o propósito do projeto. Depois, depois de fazer um trabalho extremamente minucioso e meticuloso em tudo isso e entender profundamente todo o sistema existente, o que ele faz, seu propósito, como é implementado e como todas as peças se conectam entre si, preciso que você investigue e estude de forma hiper-intensiva essas questões relacionadas a este projeto: Existem outras ineficiências graves no sistema central? Lugares no código onde: 1) mudanças realmente mudariam a diferença em termos de latência/resposta geral e throughput; 2) e onde nossas mudanças seriam comprovadamente isomorfas em termos de funcionalidade, para que soubéssemos com certeza que isso não mudaria as saídas resultantes dadas as mesmas entradas (para métodos numéricos aproximados, você pode interpretar "igual" como "dentro da distância épsil"; 3) onde você tem uma visão clara para uma abordagem obviamente melhor em termos de algoritmos ou estruturas de dados (note que, para isso, você pode incluir em suas contemplações estruturas de dados menos conhecidas e algoritmos mais esotéricos/sofisticados/matemáticos, assim como formas de reformular o(s) problema(s) para que outro paradigma seja exposto, como a teoria da otimização convexa ou técnicas de programação dinâmica. Também note que, se você conhece bibliotecas de terceiros bem escritas que funcionam bem, podemos incluí-las no projeto). Use ultrathink."
Se você gostou deste prompt, confira os prompts do irmão mais velho:
Jeffrey Emanuel
Jeffrey Emanuel10 de jan., 12:18
Incluí a versão em miniatura deste prompt aqui porque a série "Meus Prompts Favoritos" supostamente são pedaços compactos, em tamanho de mordidas e autônomos. Mas hoje transformei isso em um sistema realmente insano. Não é relevante se você está criando outro programa CRUD no React ou uma lista de tarefas, mas se você está fazendo algo bem complicado em Rust ou Golang, ou algo envolvendo dados complexos, essa abordagem é quase assustadora pelo que pode fazer. É um processo de 2 rodadas. Aqui está a Rodada 1: --- Primeiro, leia TODOS os arquivos AGENTS dot md e README dot md com muita atenção e entenda TODOS os dois! Depois, use seu modo agente de investigação de código para entender completamente o código, a arquitetura técnica e o propósito do projeto. Depois, depois de fazer um trabalho extremamente minucioso e meticuloso em tudo isso e entender profundamente todo o sistema existente, o que ele faz, seu propósito, como é implementado e como todas as peças se conectam entre si, preciso que você investigue e estude de forma hiper-intensiva essas questões relacionadas a este projeto: Existem outras ineficiências graves no sistema central? lugares na base de código onde 1) mudanças realmente mudariam a diferença em termos de latência/resposta geral e throughput; 2) de modo que nossas mudanças seriam comprovadamente isomorfas em termos de funcionalidade, para que soubéssemos com certeza que não mudaria as saídas resultantes dadas as mesmas entradas; 3) onde você tem uma visão clara para uma abordagem obviamente melhor em termos de algoritmos ou estruturas de dados (note que, para isso, você pode incluir em suas contemplações estruturas de dados menos conhecidas e algoritmos mais esotéricos/sofisticados/matemáticos, bem como formas de reformular o(s) problema(s) para que outro paradigma seja exposto, como a lista mostrada abaixo (Nota: Antes de propor qualquer otimização, estabeleça métricas de referência (latência p50/p95/p95/p99, throughput, pico de memória) e capture perfis de CPU/alocação/I/O para identificar hotspots reais): - N+1 eliminação de padrões de consulta/busca - E/S com cópia zero / reutilização de buffer / scatter-gather - custos do formato de serialização (overhead de análise pars/codificação) - filas limitadas + backpressure (previnem blowup de memória e latência de cauda) - Travas com fragmentação / listradas para reduzir a contenção - memoização com estratégias de invalidação de cache - técnicas de programação dinâmica - teoria da otimização convexa - Avaliação preguiçosa / computação diferida - padrões iteradores/geradores para evitar a materialização de grandes coleções - processamento em streaming/chunked para trabalho limitado por memória - tabelas de pré-computação e consulta - Consulta baseada em índice vs reconhecimento linear - busca binária (sobre dados e no espaço de resposta) - técnicas de dois ponteiros e janela deslizante - somas prefixas / agregados cumulativos - ordenação topológica e consciência DAG para grafos de dependência - detecção de ciclos - união-find para conectividade dinâmica - travessia de grafos (BFS/DFS) com terminação antecipada - Dijkstra / A* para caminhos mais curtos ponderados - filas prioritárias / heaps - tentativas para operações de prefixo - filtros de Bloom para pertença probabilística - árvores de intervalo/segmento para consultas de intervalo - indexação espacial (árvores k-d, quadtrees, R-trees) - estruturas de dados persistentes/imutáveis - Semântica de copiar ao escrever - Pooling de objetos/conexões - seleção de política de despejo de cache (LRU/LFU/ARC) - seleção de algoritmos conscientes de lotes - lotamento e coalescência assíncrona de I/O - estruturas sem travas para cenários de alta contensão - roubo de trabalho para paralelismo recursivo - otimização do layout da memória (SoA vs AoS, localidade cache) - curto-circuito e terminação antecipada - internamento de strings para valores repetidos - Raciocínio de análise amortizada Levando em consideração estes guias gerais quando aplicável: VERIFICAÇÕES DE APLICABILIDADE DE DP: - Subproblemas sobrepostos? → memoize com chave de estado estável - Particionamento/lotamento ótimo? → somas prefixo + DP de intervalo - Grafo de dependência com travessias repetidas? → DP topológico de passagem única VERIFICAÇÕES DE OTIMIZAÇÃO CONVEXA: - Forçar a alocação/agendamento exato? → Fluxo LP / custo mínimo com desempate determinístico - Ajuste contínuo de parâmetros com perda explícita? → mínimos quadrados / QP regularizados - Grande objetivo convexo decomponível? → ADMM / métodos proximais Também note que, se você conhece bibliotecas de terceiros bem escritas que funcionam bem, podemos incluí-las no projeto). REQUISITOS DE METODOLOGIA: A) Linha de base primeiro: Executar o conjunto de testes e uma carga de trabalho representativa; Grave a latência, taxa de transferência e memória de pico do P50/P95/P99 com comandos exatos. B) Perfil antes de propor: Capturar CPU + alocação + perfis de E/S; Identifique os 3 a 5 principais pontos quentes por % de tempo antes de sugerir mudanças. C) Oráculo de equivalência: Defina saídas douradas explícitas + invariantes. Para grandes espaços de entrada, adicione testes baseados em propriedades ou metamórficos. D) Prova de isomorfismo por alteração: Cada diferencial proposto deve incluir um breve esboço de prova explicando por que as saídas não podem mudar (incluindo ordenação, desempate, comportamento em ponto flutuante e sementes RNG). E) Matriz de Oportunidades: Classificar os candidatos por (Impacto × Confiança) / Esforço antes de implementar; Foque apenas em itens que provavelmente vão mover P95+ ou throughput de forma significativa. F) Diferenciais mínimos: Uma alavanca de desempenho por troca. Sem fatores não relacionados. Inclua orientações de rollback caso exista algum risco. G) Guarda-corpos de regressão: Adicionar limiares de referência ou ganchos de monitoramento para evitar regressões futuras. Use o ultrathink. --- Você pode rodar isso uma vez no Claude Code com Opus 4.5 e outra no Codex com GPT 5.2 Codex (comecei a usar só o High porque o Extra High é lento demais para mim, a menos que eu esteja prestes a dormir). Depois que terminarem, dê umas 5 rodadas rápidas a cada um deste: "Ótimo. Revise tudo novamente para ver se há falhas óbvias, omissões ou erros, erros conceituais, erros, etc. Use ultrathink" Depois, peça para salvarem as saídas assim: "OK, guarde tudo isso para PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md" "OK, guarde tudo isso como PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md" Então, no Claude Code, faça: "Compare o que você fez com PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__GPT.md e pegue os melhores elementos disso e os entrelace no seu plano para conseguir um plano híbrido de melhor dos dois mundos superior, editando seu arquivo original de plano." Então isto: Releia AGENTS dot md para ainda estar fresco na sua mente. Agora leia TODO o PLAN_FOR_ADVANCED_OPTIMIZATIONS_ROUND_1__OPUS.md. Depois revise cada conta com muito cuidado — tem certeza de que faz sentido? É o ideal? Poderíamos mudar algo para fazer o sistema funcionar melhor para os usuários? Queremos um conjunto abrangente e granular de contas para tudo isso, com tarefas, subtarefas e estrutura de dependências sobrepostas, com comentários detalhados para que tudo seja totalmente autossuficiente e autodocumentado (incluindo contexto relevante, raciocínio/justificativa, considerações, etc. — tudo o que queremos que nosso "eu futuro" saiba sobre os objetivos, intenções, o processo de pensamento e como isso serve aos objetivos gerais do projeto). As contas devem ser tão detalhadas que nunca precisemos consultar o documento original do plano de desconto. Ele reflete com precisão TODO o arquivo do plano de desconto de forma abrangente? Se for necessária mudança, revise as contas ou crie novas ou feche as inválidas ou inaplicáveis. É muito mais fácil e rápido operar no "espaço do planejamento" antes de começarmos a implementar essas coisas! NÃO SIMPLIFIQUE DEMAIS! NÃO PERCA NENHUM RECURSO OU FUNCIONALIDADE! Além disso, certifique-se de que, como parte dessas contas, incluamos testes unitários abrangentes e scripts de teste e2e com logs detalhados e excelentes para garantir que tudo esteja funcionando perfeitamente após a implementação. Lembre-se de usar APENAS a ferramenta 'bd' para criar e modificar as contas e adicionar as dependências às contas." Depois, algumas rodadas de: "Verifique cada conta com muito cuidado — tem certeza que faz sentido? É o ideal? Poderíamos mudar algo para fazer o sistema funcionar melhor para os usuários? Se sim, revise as contas. É muito mais fácil e rápido operar no "espaço do planejamento" antes de começarmos a implementar essas coisas! NÃO SIMPLIFIQUE DEMAIS! NÃO PERCA NENHUM RECURSO OU FUNCIONALIDADE! Também certifique-se de que, como parte das contas, incluamos testes unitários abrangentes e scripts de teste e2e com logs detalhados e excelentes para garantir que tudo está funcionando perfeitamente após a implementação. Use ultrathink." Depois, solte o enxame para implementar tudo. Depois, prepare-se para a SEGUNDA RODADA.
715