O espelho: RFC vs. prompt de sistema

Vamos direto ao ponto. Cada seção clássica de um RFC tem um equivalente direto num prompt de sistema:

Parece simples demais? Parece. Mas a maioria dos prompts que a gente vê por aí ignora pelo menos metade dessas seções. E é exatamente aí que as coisas dão errado.

Vamos caminhar por cada linha dessa tabela com exemplos concretos.

Problem Statement -> Contexto e papel

No RFC, o problem statement responde: “por que estamos fazendo isso?” No prompt, o contexto faz a mesma coisa. Ele ancora o agente numa realidade específica.

Sem contexto, o agente opera no vácuo. Com contexto, ele sabe quem é, onde está e por que foi chamado.

# Sem contexto (problem statement)

A diferença é a mesma entre um RFC que começa com “Precisamos de notificações” e um que começa explicando o volume de eventos, os problemas atuais de duplicata, e o impacto no suporte.

Proposed Solution -> Descrição da tarefa

A solução proposta no RFC diz o que vai ser construído. No prompt, a descrição da tarefa faz o mesmo: diz ao agente exatamente o que ele precisa fazer.

# Vago

No RFC, a proposed solution tem verbos de ação e descreve fluxos. No prompt, idem. A clareza aqui é o que separa um agente produtivo de um agente perdido.

Constraints -> Regras e limites

Essa é talvez a seção mais negligenciada – e a mais poderosa. No RFC, as constraints dizem: “construa dentro dessas paredes.” No prompt, as regras fazem o mesmo.

# Sem constraints

É aqui que você evita que o agente tome decisões por conta. Sem constraints, ele escolhe o caminho que parece mais lógico para ele – que raramente é o mais lógico para o seu projeto.

Non-Goals -> Exclusões explícitas

Se constraints dizem o que fazer dentro, non-goals dizem o que fica fora. No mundo dos prompts, isso se traduz em exclusões explícitas – os famosos “NÃO faça”.

"NÃO implemente:

Parece óbvio? Para um humano experiente no projeto, talvez. Para um agente, não. Sem essas exclusões, um modelo capaz vai olhar para o domínio de notificações e naturalmente pensar em retry, analytics, real-time. Ele está tentando ser completo. Seu trabalho é dizer onde a completude termina.

Open Questions -> Pedidos de esclarecimento

No RFC, open questions são pontos que o autor ainda não resolveu e quer discutir com o time. No prompt, isso se traduz em instruir o agente a perguntar antes de decidir.

"Se o usuário não tem preferência de canal configurada,

Essa seção transforma o agente de um executor cego em um colaborador. Em vez de preencher lacunas com suposições (que é o instinto natural do modelo), ele sinaliza incerteza. Exatamente como um bom engenheiro faria ao ler um RFC com pontos em aberto.

Acceptance Criteria -> Formato de saída e critérios de sucesso

No RFC, critérios de aceite definem “como sabemos que deu certo.” No prompt, eles definem o formato e a qualidade esperada da saída.

"Saída esperada para cada notificação processada:

Sem critérios de aceite, como você sabe se o agente fez um bom trabalho? Você não sabe. Fica na intuição. E intuição não escala.

Na prática: do RFC ao prompt

Chega de teoria. Vamos pegar um RFC fictício de um serviço de notificações e transformá-lo num prompt de sistema. Lado a lado.

O RFC

TÍTULO: Serviço de Notificações para Eventos de Compra

O prompt de sistema

PAPEL:

Olha os dois lado a lado. Cada seção do RFC mapeou diretamente para uma seção do prompt. O problema virou o papel. A solução virou a tarefa. As restrições viraram regras. O fora de escopo virou “NÃO FAÇA”. As questões abertas viraram “QUANDO TIVER DÚVIDA”. Os critérios de aceite viraram o formato de saída.

Não é coincidência. É a mesma estrutura de pensamento, aplicada a um interlocutor diferente.

Vago vs. estruturado: o que muda na prática

Pra deixar o contraste claro, veja o que acontece quando você usa um prompt vago versus um prompt com estrutura de RFC.

Prompt vago:

"Cria um serviço de notificações pro meu e-commerce."

O agente provavelmente vai: escolher seus próprios providers, inventar um sistema de templates, implementar retry, adicionar analytics, criar um painel de preferências, e talvez até um sistema de A/B testing de mensagens. Tudo isso sem você pedir. Muito trabalho, pouco valor, e horas de limpeza pela frente.

Prompt com estrutura de RFC:

O que a gente escreveu acima. O agente faz exatamente o que foi pedido, nos limites que foram definidos, e sinaliza quando encontra algo que não sabe resolver.

Gergely Orosz, no Pragmatic Engineer, faz uma observação que cabe perfeitamente aqui: a forma como informação flui molda a cultura de um time. O mesmo vale para agentes. A estrutura do seu prompt molda o comportamento do agente.

Escrita como quality gate

Uma última reflexão. Em times de engenharia maduros, o RFC passa por review antes de virar código. Alguém lê, questiona, aponta lacunas. É um quality gate.

Prompts de sistema merecem o mesmo tratamento. Se um prompt vai guiar o comportamento de um agente que interage com seu sistema de produção, ele deveria passar por um review tão rigoroso quanto um pull request.

Leia o prompt em voz alta. Pergunte: “se um dev junior lesse isso, ele saberia o que fazer?” Se a resposta é não, o agente também não vai saber. Revise. Peça feedback. Trate o prompt como artefato de engenharia, não como texto descartável.