Quando comecei a deixar uma IA me ajudar a rascunhar posts para este blog, a saída tinha um problema. Não era um problema de gramática. A gramática estava perfeita. O problema era que não soava como eu.

Soava como um post de blog genérico e competente da internet. Confiante. Suave. Transições limpas. Nenhuma das pequenas irregularidades que fazem a escrita parecer que uma pessoa escreveu. Depois de alguns rascunhos percebi que o modelo não ia aprender minha voz por osmose só porque tínhamos passado algumas horas juntos.

Então escrevi três arquivos de rules. O agente os lê toda vez que toca num post. São curtos, opinados e descrevem a voz do jeito que eu descreveria para outro escritor humano. Este post é um passo a passo desses arquivos, com o conteúdo real que acabei usando.

O que são rules, afinal

Rules são pequenos arquivos Markdown com orientação que o agente carrega quando está trabalhando em arquivos correspondentes. Para este post, o ponto importante é simples: escrevi o conselho de escrita uma vez, apliquei aos posts do blog, e parei de reensinar isso em todo chat.

Rule um: a voz em si

A primeira rule é a mais longa. Ela descreve a voz em três blocos: os dois registros que uso, os padrões de assinatura que quero manter e as coisas a evitar.

A parte dos dois registros fica assim:

## Two registers

#

## Casual / dev-diary
Used for: tutorials, "I just shipped X" posts, planning recaps.
- Conversational openings ("It's been a while.", "Here's the part…").
- First person. Address the reader directly as "you".
- Short paragraphs. Frequent line breaks.
- Numbers and concrete details over abstractions.

#

## Reflective / essay
Used for: posts about workflow philosophy, why something matters.
- Longer, more measured sentences. Still first person.
- Builds an argument across paragraphs rather than walking through steps.
- Avoid jargon when a plain phrase will do.
- Leave room for tension and ambiguity. Don't force a tidy conclusion.

Esse trecho sozinho mudou a saída de forma perceptível. Antes, cada post saía na mesma voz de andamento médio — nem casual, nem reflexivo, só blog-genérico. Depois, eu podia dizer ao agente “este é casual, tipo os posts de sexta no estilo diário de dev” e ele acertava o registro, quase sempre.

A parte seguinte é um pequeno inventário de o que manter. Reli dez dos meus posts mais antigos e extraí os padrões recorrentes. Cacoetes conversacionais que uso muito (“Bom,”, “Olha,”, “Sinceramente,”). O leve sabor de ESL — sou brasileiro, vivo em inglês faz tempo, mas minhas frases às vezes não soam como as de um nativo, e isso é parte da voz. Enquadramentos autoconscientes onde nomeio o que vou fazer (“Deixa eu voltar um passo.”, “A questão é essa.”). Números e datas específicos em vez de quantidades vagas.

Esse último importa mais do que eu esperava. Escrevi “muitos anos atrás” uma vez e o agente deixou. Corrigi para “quase oito anos atrás” e coloquei uma nota na rule: prefira quantidades específicas. A saída ficou mais concreta na hora.

A lista de “o que evitar” é mais curta e mais incisiva:

- LLM-flavored phrases: "leverage", "delve into", "in today's
  fast-paced world", "navigate the complexities of".
- Bullet lists where a paragraph would carry the argument better.
- Fake enthusiasm. Hype words like "amazing", "incredible",
  "game-changing" read as borrowed.
- Forced "key takeaway" boxes. Endings can be quiet.
- Stripping the mild ESL flavor. If a sentence reads like the
  author wrote it on a Tuesday at 11pm, leave it.

Esse último ponto é o que tive que ser mais explícito. O modelo quer alisar cada frase num inglês americano idiomático perfeito. Pra mim isso é uma regressão — remove a coisa que faz a escrita parecer local.

Rule dois: dual language

Esta é mecânica mas importante. Cada post neste blog existe em duas línguas: inglês em src/content/posts/<slug>.md e português brasileiro em src/content/posts/pt/<slug>.md. Mesmo nome de arquivo, mesma data, mesmas tags, corpo traduzido.

O arquivo de rule torna esse contrato explícito:

Both files must share:
- The same `YYYY-MM-DD-slug` filename.
- The same `date` in frontmatter.
- The same `category` value.
- The same `tags` array (tags are slugs, not labels).
- The same `thumbnail` path (images are language-agnostic).
- The same number, order, and `src` of `<figure>` blocks.
  Translate `alt` and `figcaption`.

The PT file additionally requires `lang: pt`.

Sem isso, cada tradução desviava um pouco. Conjuntos de tags diferentes entre EN e PT, nomes de arquivos de imagem levemente diferentes, um campo de data faltando. Com a rule, eu só digo “traduz esse post pra PT” e o agente produz um arquivo paralelo com o formato certo.

Tem uma seção de qualidade de tradução também: português brasileiro, vocabulário de trabalho em inglês onde devs brasileiros realmente usam, e um registro casual que não fica formalizado demais.

Rule três: a estrutura

A terceira rule é a chata, mas é onde a maioria dos bugs costumava morar. Schema do frontmatter. Convenção de nomes de arquivo. Sequenciamento de datas. Convenções de imagem. Convenções de tags. A seção de encerramento obrigatória.

A parte de imagens é o trecho que mais mudou como eu trabalho:

Every post must have at least 3 images:
- 1 hero/thumbnail image, referenced in `frontmatter.thumbnail`.
- 2 or more inline images in the post body.

Inline image pattern (use raw HTML, not Markdown):

<ImageFigure alt="..." src="/content/posts/<slug>/<image-name>.png" caption="Editorial caption that adds context." />

- alt must be detailed enough to use as an image-generation prompt.
- figcaption adds editorial context, not a repeat of the alt.

O motivo disso importar: o agente agora escreve posts com blocos <figure> apontando para caminhos de imagem que ainda não existem. O alt é detalhado o suficiente para eu alimentar diretamente num modelo de imagem. O figcaption é editorial. Eu gero as imagens numa passada separada, salvo nos caminhos sugeridos, e o post de repente está ilustrado. A rule mantém o fluxo consistente em cada post.

O que mudou na saída

Algumas coisas, depois que commitei esses três arquivos.

Os rascunhos começaram a chegar no registro certo sem eu precisar pedir. Se eu dizia “escreve o post sobre journaling”, o agente escolhia o registro reflexivo porque o arquivo de rule liga tipos de tópico a registros. Quase nunca precisei corrigir o registro depois disso.

As frases de assinatura voltaram. Não de forma servil — o modelo não enfiava “Olha,” em cada parágrafo — mas um “Sinceramente,” aparecia onde eu realmente usaria um, e o ritmo parecia certo.

Filler de LLM caiu quase a zero. “Leverage”, “delve”, “in today’s fast-paced world” — sumiram. Uma vez que esse vocabulário é nomeado na rule como proibido, o modelo não recorre a ele.

E a sincronização dual-language deixou de ser um trabalho chato. Eu escrevo o post em EN, peço o PT, e o que volta é estruturalmente paralelo sem eu precisar conferir o YAML.

O que não funcionou

A rule de voz não substitui a edição.

O modelo ainda ocasionalmente escreve uma frase que está tecnicamente no meu registro mas lê como uma paródia dele. Muitos “Sinceramente,” seguidos. Um “Bom,” que é só filler. Frases que forçam demais o sinal de ESL até parecerem um sotaque encenado. Eu corto essas quando vejo. A rule enviesou a saída; ela não faz a leitura final.

A outra coisa que não resolve é o que dizer. Rules de voz governam como algo é dito. O argumento, a ordem, as omissões — essa parte ainda é comigo. Um post perfeitamente na minha voz sobre nada continua sendo um post sobre nada.

Esse é o padrão, mais ou menos. Não tente coachear a voz do agente na janela de chat a cada post. Escreva o coaching uma vez. Deixe o agente reler a cada arquivo. Edite as rules quando identificar uma falha recorrente. A conversa fica mais curta e a saída fica mais estável.