Este blog publica um post por dia e nenhum humano escreve o rascunho. Quem escreve é um agente de IA que roda numa tarefa agendada, pesquisa fontes primárias, gera o markdown, commita no repositório e deixa o deploy acontecer sozinho. Este post conta como isso funciona por dentro, quais regras impedem o agente de inventar coisa, e onde o sistema quebra.

A arquitetura em uma frase

Uma tarefa agendada acorda o agente, ele pesquisa o tema do dia, escreve um arquivo markdown, faz git push e a Vercel publica. Só isso.

O detalhamento:

  1. Tarefa agendada. O Claude Code Desktop suporta tarefas recorrentes: você define prompt, frequência e pasta de trabalho, e o agente inicia uma sessão sozinho no horário marcado. A nossa roda toda semana com um prompt longo que funciona como manual de redação.
  2. Calendário editorial no prompt. Segunda é benchmark de modelos, quarta é técnica, sexta é notícia, sábado é este tipo de post: bastidores e lições. O agente descobre o dia da semana via shell e segue o calendário.
  3. Conteúdo em markdown. O blog é Next.js e cada post é um arquivo com frontmatter (título, data, categoria, fontes). O Next.js lida bem com markdown e MDX, então não existe CMS, banco de conteúdo nem painel admin. O repositório é o CMS.
  4. Deploy sem cerimônia. A Vercel cria um deploy de produção a cada push na branch principal. O commit é a publicação.

Nada aqui é exótico. A parte difícil não é a arquitetura, é o controle de qualidade.

As regras que seguram o agente

A regra número um: nada inventado. Todo número, ranking e citação precisa vir de fonte primária verificável, e o post não sai sem um campo sources preenchido com no mínimo três links. Se o agente não confirma um dado na fonte, o dado morre.

Isso existe porque modelo de linguagem escreve com confiança sobre coisas que não conferiu. Deixar um agente publicar direto sem essa trava é pedir para o blog virar gerador de erro plausível.

As outras travas:

  • Fact-check antes do commit. Cada afirmação passa por revisão contra as fontes. O que não bate, sai.
  • Snapshot semanal. Nos posts de benchmark, o agente salva um JSON com os números da semana e compara com o da anterior. Sem isso, "subiu" e "caiu" viram chute.
  • Revisão de tom. O texto passa por um filtro anti-robô: cortar conector formal demais, frase de 40 palavras, sopa de bullets. Se soa como release de assessoria, reescreve.
  • Commit cirúrgico. O agente só adiciona as pastas de conteúdo no git, nunca git add -A. Um agente com permissão de commit largo é um risco desnecessário.

Onde quebra (porque quebra)

A resposta curta: quebra na fronteira entre o ambiente do agente e o mundo real. Alguns exemplos que já vivemos:

Problema Causa Correção
Push falha por autenticação O sandbox do agente não tem credencial do GitHub embutida O agente commita local e reporta; o push final é humano
Pasta certa não montada Reorganizamos os diretórios e a tarefa apontava para o caminho antigo O prompt agora declara o caminho oficial e manda verificar o remote antes de qualquer push
Markdown renderiza errado ≈20% vira texto tachado em vez de "aproximadamente 20%" Regra explícita no prompt: usar ≈ ou "cerca de"
Commit no repositório errado Mono-repo abraçando subpastas: um cd que falha silenciosamente muda o destino do push Checagem obrigatória de git remote -v antes do commit

O padrão é claro: o agente erra menos no conteúdo e mais na infraestrutura ao redor. Cada quebra virou uma linha nova no prompt, o que transforma o prompt num changelog dos nossos erros.

O que aprendemos construindo isso

Automação de conteúdo funciona quando o humano desenha as regras e o agente executa, não o contrário. Três lições práticas:

O prompt é o produto. O agente é o mesmo para todo mundo. O que diferencia o resultado é o manual que ele recebe: calendário, regras de fonte, tom, formato de commit. Escrever esse manual deu mais trabalho que configurar qualquer ferramenta.

Trave o que é irreversível. Publicar um post ruim se corrige com um commit. Push no repositório errado ou um dado inventado citado por terceiros, não. As travas mais rígidas ficam nas ações difíceis de desfazer.

Reporte é obrigatório. Toda execução termina com um resumo do que foi feito e do que falhou. Automação silenciosa é automação que você só audita quando o estrago já apareceu.

Vale a pena?

Vale, com ressalva. O custo de manutenção não é zero: o prompt evolui, as quebras de infraestrutura acontecem e a revisão humana continua existindo, só que mais barata. O que a automação comprou foi consistência. O blog publica todo dia útil de calendário há semanas, sem depender de disposição às 9h da manhã.

Software bom muta. Este pipeline também: cada erro dele vira regra nova, e a versão que roda hoje já é bem diferente da primeira. Se você quer montar algo parecido, comece pelo manual de regras, não pela ferramenta.