O prompt como artefato

Nove cursos mostraram que você vai mudar prompts, não pesos. Este curso mostra como fica um prompt quando você aceita isso e o projeta direito.

Na prática, a história costuma ser outra. Um prompt começa como uma frase clara. Alguém adiciona uma regra depois de um incidente. Alguém adiciona um exemplo. Alguém adiciona "IMPORTANTE: nunca faça X" em maiúsculas, porque o modelo fez X. Dezoito meses depois, são quatrocentas linhas de cicatrizes acumuladas. Ninguém sabe quais ainda importam, e todo mundo tem medo de apagar qualquer coisa.

Qualquer artefato sem estrutura, sem dono e sem teste acaba assim, por mais disciplinado que seja o time. E um prompt é um artefato, por mais que pareça um parágrafo.

Por que um prompt é diferente do código ao redor

Quatro propriedades tornam um prompt incômodo de manter, e cada uma tem uma resposta de engenharia:

A quarta é a perigosa. Código que quebra para de funcionar. Um prompt que quebra continua produzindo saída confiante, bem formatada e um pouco pior, e nenhuma exceção dispara um alerta para alguém.

Camadas, não um parágrafo

Um prompt bem arquitetado é feito de partes com funções distintas, que mudam em ritmos distintos:

flowchart TB
  A["Identidade e regras — muda raramente"] --> B["Definição da tarefa — muda com a feature"]
  B --> C["Exemplos — mudam com os dados"]
  C --> D["Contexto recuperado — muda a cada requisição"]
  D --> E["Entrada do usuário — muda a cada requisição"]
  E --> F["Contrato de saída — muda com o consumidor"]

Separar as camadas tem duas consequências, e as duas pesam mais do que parece.

Ritmos de mudança diferentes pedem lugares diferentes. Identidade e regras ficam no código e mudam por revisão. Exemplos ficam numa tabela e mudam por uma interface, como defendeu o curso de few-shot. Contexto recuperado é montado por requisição. Juntar tudo numa única string faz as partes estáveis serem editadas com a mesma frequência das voláteis.

A ordem é uma decisão de custo. Com as camadas estáveis primeiro e as voláteis por último, toda requisição repetida lê do cache tudo o que está acima do último ponto de corte, por uma fração do preço de entrada. Um prompt com camadas intercaladas não pode ser cacheado, e isso aparece na fatura.

O que a "arquitetura" traz

Compare dois times com a mesma tarefa.

O primeiro tem uma string de prompt. Melhorá-la é editar prosa e torcer. Testá-la é tentar algumas entradas. Ninguém consegue dizer qual das quatrocentas linhas está fazendo o trabalho, e, sendo honesto, algumas não fazem nada e uma atrapalha.

O segundo tem uma camada de identidade em código, uma definição de tarefa por rota, exemplos como linhas de tabela, um montador de contexto com orçamento e um schema de saída. Esse time consegue mudar uma camada e medir o efeito, apagar uma regra e ver se algo muda, e responder "por que o modelo fez isso" apontando um componente.

Nenhum dos dois tem um modelo melhor. O segundo time tem um sistema que consegue entender.

O que este curso cobre

1. O prompt como artefato (você está aqui).
2. Anatomia: o que pertence a cada camada, e em que ordem.
3. Composição sem acoplamento.
4. Andaimes de raciocínio, e o que o adaptive thinking tornou obsoleto.
5. Montagem de contexto sob orçamento.
6. Prompts de vários turnos e estado.
7. Juntando tudo: um catálogo de prompts em Rails.

Este é o último curso dedicado só ao prompt. Ele vem depois de agentes, Claude Code, schemas e fine-tuning de propósito: a estrutura certa de um prompt depende do sistema de que ele faz parte, e agora você conhece esse sistema.

Pontos-chave

• Um prompt é um artefato sem compilador, com efeitos não locais, sem dono claro e com degradação silenciosa.
• Ele degrada sem quebrar, e é por isso que um conjunto de avaliação e métricas de regressão substituem o compilador.
• Organize o prompt em camadas com funções distintas: identidade, tarefa, exemplos, contexto, entrada e contrato de saída.
• Camadas mudam em ritmos diferentes, então ficam em lugares diferentes: código, tabelas, montagem por requisição.
• Ordene as camadas do estável ao volátil para que a parte que nunca muda seja lida do cache.