Qual é a diferença entre system prompt e user prompt?

System prompt é a lei geral que governa o comportamento para TODA tarefa, todo turno, toda conversa. User prompt é a instrução específica que você dá naquele momento. System prompt multiplica em tudo que o modelo faz daqui pra frente; user prompt é descartável e muda a cada chamada.

Como adiciono reference points no meu system prompt?

Crie códigos curtos (D1/D2 para decisões, R1/R2 para riscos, F1/F2 para achados, etc.) e associe cada item quando você apresentar 3 ou mais coisas de um mesmo tipo. Depois é só o leitor responder "que tal expandir R1?" sem precisar repetir todo o contexto. Economiza tokens e agiliza iteração.

Essa técnica funciona com outros modelos além do Claude?

Funciona universalmente, mas o impacto varia. Modelos verbosos e com tiques (tipo Opus 5) ganham mais redução. Modelos já concisos ganham menos. A técnica é universal; o ROI depende do baseline de comportamento do modelo.

Quanto tempo leva implementar essas 5 camadas?

Um bom system prompt bem pensado leva 30-60 minutos pra escrever. Depois é maintenance leve. O ROI é gigante em produção porque a mudança se replica em TODA execução do agente daqui pra frente.

Por que system prompt não é padrão em todo lugar?

Porque a maioria dos engenheiros nunca aprendeu que existe. User prompt e model selection levam luz. System prompt é invisível, mas é onde a alavancagem real vive. Esse é exatamente o achado que IndyDevDan demonstrou.

System Prompt Engineering: a alavancagem que todo engenheiro ignora

Opus 5 é um dos melhores modelos já lançados. Mas conversar com ele é uma luta — extremamente verboso, cheio de tiques irritantes ("load-bearing", "worth stating plainly"), queima tokens à toa, tenta se auto-creditar em mensagens de commit. A resposta que todo mundo dá é trocar de modelo. Mas eu descobri olhando o IndyDevDan trabalhar que a resposta real é bem mais simples: system prompt engineering — a habilidade que todo mundo declarou morta e não está morta.

O sistema que ninguém mexe

Aqui vai um achado que mudou meu jeito de pensar sobre agentes: existem 2 formas completamente diferentes de prompt engineerar um agente. Uma é o user prompt — a tarefa específica que você dá ("resuma este blog post", "cria um componente React"). A outra é o system prompt — a lei que vale pra TODA tarefa, todo turno, toda conversa. A maioria dos engenheiros só mexe no user prompt. Alguns fazem skills. Mas a alavancagem real está no system prompt, porque cada palavra escrita ali se multiplica em toda entrada e toda saída do agente daqui pra frente.

Cinco camadas de mudança

IndyDevDan demostrou ao vivo comparando dois Claude Code lado a lado — uma instância com Opus 5 padrão, outra com o system prompt sendo construído incrementalmente. Mesmo prompt rodava em ambos, e ele media tempo e tokens a cada mudança. Foram 5 camadas, uma de cada vez:

(1) Comunicação clara/concisa/acionável — só declarar a relação de trabalho ("no-BS, clear, concise, actionable relationship"). Pouca mudança sozinha. (2) Padrões positivos e negativos — lista explícita do que replicar (linguagem simples, cada fato dito uma vez, contestar premissa errada direto) e do que evitar (lista literal de palavras banidas: "load-bearing", "worth stating plainly", chains de em-dash, headings decorativos, emoji, linguagem motivacional). Resultado: praticamente sumiu "load-bearing", menos travessões. (3) Reference points — códigos tipo D1/D2 (decisões), R1/R2 (riscos), F1/F2 (achados) atribuídos quando você apresenta 3+ coisas. Economiza tokens em turnos seguintes porque é só responder "fala mais sobre R6" sem repetir contexto. (4) Hard operational boundaries — entregar só o que foi pedido no escopo pedido, não expandir pra limpeza/refactor/features, nunca adicionar co-author em commit (crítica direta à Anthropic se auto-creditando em commits do Claude), reafirmar trabalho de forma concisa. (5) Aliases — `SCR` (simplifica e reescreve), `ELI` (explica como se eu tivesse 18 anos), `FOC` (foca no que mais importa), `REF` (reescreve com reference points).

O resultado: quase metade do tempo

Resultado final: 22 segundos vs 41 segundos do Opus padrão — quase metade do tempo/tokens pro mesmo resumo de blog post. Não é marginal. Não é "5% mais rápido". É uma redução de 46%. Em produção, com milhões de tokens por mês, essa diferença é a diferença entre escalável e quebrado. Cada camada contribuiu: a primeira fez pouca diferença, mas as demais se empilharam em redução real de outputs.

Por que isso importa para devs

Três linhas retas de por que isso muda o jogo: (1) Você controla a qualidade sem trocar de modelo. Opus 5 continua Opus 5, continua inteligente, você só remove o comportamento irritante via comunicação bem escrita. Não é hacking, é engenharia. (2) Cada layer é independente. Você pode rodá-los uma de cada vez e medir o impacto. Decisão baseada em dados, não em feeling. Prompt engineering hoje é ciência, não cargo cult. (3) Sistema prompt de qualidade se replica entre contextos. Uma instância bem tunada de Claude Code roda melhor em todo fluxo, toda tarefa, toda integração que você jogar nela daqui pra frente. É uma mudança que multiplica.

In-context distillation: treino sem treinar

Tem um bônus que IndyDevDan mostrou que é bem old-school mas ainda a coisa mais eficaz que existe. Ele chama de "in-context distillation" — pegar respostas reais de um modelo que você gosta (ele usa Claude Fable 5 como exemplo, diz que Fable tem menos tique que Opus), colar como exemplo de "faça assim" no system prompt, e colar uma resposta ruim do Opus como "não faça assim" — treino por exemplo direto no prompt. Ele diz que já usava isso na era GPT-3.5. Nunca foi sexy. Mas funciona.

Conclusão

A frase de fechamento dele resume tudo: "keep the smart, drop the ass" — o modelo continua inteligente, você só remove o comportamento chato via comunicação bem escrita. Great engineering is great communicating. Opus 5 não é o problema. A falta de um system prompt bem pensado é. Assista o vídeo completo do IndyDevDan para ver essas camadas sendo construídas ao vivo e medidas em real-time — é uma master class em tuning de modelos. Tem link aqui pro vídeo completo.