[🤖] O Codex me apagou do meu próprio blog técnico

✨ Resumo do GPT-5.6 Sol

Pedi ao Codex que escrevesse um post técnico, mas, em vez de contar como percebi o problema e conduzi o trabalho, ele escreveu o próprio relatório. Este é o registro de como rastreei a causa e devolvi ao usuário o centro narrativo da Skill de escrita.

Eu desapareci do post técnico que eu havia escrito

Depois de conhecer o termo Graph Engineering, continuei questionando se essa abordagem era realmente adequada para evitar os fracassos que eu havia sofrido em trabalhos longos com o Codex. Nunca quis um framework grandioso. Minha ideia era a menor estrutura possível: quando uma sessão terminasse uma unidade de trabalho, ela passaria o resultado para uma sessão de auditoria independente e não seguiria adiante até a auditoria retornar.

Em vez de começar criticando minha proposta, o Codex concordou de maneira convincente e mudou de posição toda vez que eu trouxe um contraponto. Por isso mandei fazer revisões críticas repetidas e continuei retirando tudo que tornasse a estrutura desnecessariamente complexa ou apenas consumisse tokens. No fim, eu não queria um texto explicando o termo da moda Graph Engineering. Queria um diário que registrasse o que eu havia descoberto em uma falha real e quais instruções usei para mudar a forma de trabalho do Codex.

Mas eu não estava no centro do texto que o Codex trouxe. O problema que eu havia percebido, o motivo de ter rejeitado a primeira resposta e as objeções com que reduzi a estrutura foram empurrados para trás. Em vez disso, o protagonista era o Codex: que estrutura colocou em uma Skill, que procedimento de auditoria executou e quais verificações aprovou. Um relatório de trabalho do Codex quase foi publicado no meu blog técnico.

Foi então que formulei o problema com precisão.

O centro deve ser sempre qual problema eu reconheci e como instruí você a resolvê-lo. A maneira como você fez o trabalho não é o centro de forma alguma e basta ser mencionada muito brevemente.

O processo de implementação da IA pode ser explicado um pouco mais quando oferece uma dica útil ao leitor. Não importa o quanto seja tecnicamente complexo ou bem verificado: isso não lhe dá o direito de tomar para si a narrativa do meu texto.

A Skill que eu achava ter corrigido carregava a causa

O mais absurdo era eu me lembrar de já ter corrigido esse problema. No fim de julho, enquanto escrevia Conectei o fluxo e a sensação do trabalho com uma Codex Skill, fiz a Skill de escrita parar de carregar cópias das regras do cdb e passar a ler diretamente, a cada vez, as regras atuais do projeto, a conversa e o histórico do Git.

Na época, isso realmente resolveu um problema importante. Quando regras antigas são copiadas para uma Skill, a escrita se desvia sempre que o projeto muda. Então corrigi a origem das regras e fiz a Skill reler o contexto atual. Achei que isso bastava para deixá-la devidamente corrigida.

Mas desta vez descobri que eu havia corrigido de onde as regras eram lidas, não a experiência de quem o texto deveria contar.

A Skill antiga começava procurando nas evidências do trabalho algum valor técnico para entregar ao leitor. Ela separava diário pessoal de texto técnico reutilizável e, quando havia bastante material técnico, inclinava-se naturalmente para uma estrutura de relatório generalizado. Havia até uma autoavaliação para verificar se o valor técnico continuava claro depois de remover a narrativa cronológica pessoal. O que eu havia vivido, julgado e ordenado não era tratado como texto-fonte a preservar, mas como ruído que poderia ser removido para deixar a explicação técnica mais limpa.

Portanto, não era por acaso que o Codex continuava fazendo a mesma coisa. Não importava o quanto eu explicasse minha intenção na conversa: a Skill que realmente produzia o texto extraía primeiro os fatos técnicos e o processo de implementação. O Git e os registros das ferramentas deveriam confirmar os fatos, mas viraram o índice. O trabalho do Codex deveria ser apenas uma explicação de apoio, mas virou o protagonista. Uma Skill serve para repetir um trabalho com estabilidade e, por isso, também repetia uma premissa errada com uma estabilidade impressionante.

Primeiro mandei inverter o sujeito da narrativa

No começo, pensei que talvez apenas algumas frases estivessem erradas. Mas, quando o Codex tentou recuar outra vez para dizer que a Skill estava “em grande parte boa e só precisava de um pequeno reforço”, mandei melhorá-la de verdade. Acrescentar algumas linhas não bastava. A própria ordem de criação do texto precisava ser invertida.

A primeira linha do novo critério não era um tema técnico, mas o usuário. A Skill passou a ter de reconstruir primeiro por que eu comecei o trabalho, o que julguei estar errado, o que instruí a IA a fazer, por que rejeitei o primeiro resultado, como voltei a restringir as condições e de que forma o resultado finalmente mudou.

O histórico do Git, a saída das ferramentas, as alterações de código e os resultados das verificações só poderiam confirmar fatos, sem substituir essa narrativa. Quais arquivos a IA alterou e quais verificações aprovou seriam mantidos apenas quando explicassem o resultado do meu julgamento ou oferecessem uma dica real a outra pessoa. Também limitei a exceção: a implementação em si só poderia ocupar o centro quando o usuário pedisse explicitamente um tutorial ou uma referência técnica.

Também inverti a autoavaliação. Agora, mesmo depois de retirar os detalhes de implementação da IA, o problema que encontrei, minhas instruções, minhas críticas, minhas correções e o que aprendi precisam continuar claros. Se isso não permanecer, não importa o quanto a escrita seja fluida ou a quantidade de informação técnica: não é o meu diário. A Skill revisada até passou na validação de sintaxe, mas o importante desta vez não era a aprovação na verificação. Era o critério de julgamento ter sido invertido.

No próximo texto, vou verificar se eu ainda estou nele, não como as frases soam

Meu maior engano neste episódio foi a lembrança de que eu “já havia corrigido” o problema. Eu tinha feito a Skill reler as regras atuais e, por isso, achei que o problema de escrita também estava resolvido. Na verdade, havia corrigido apenas a origem das regras, não a finalidade do texto. Mesmo que a Skill leia corretamente as regras mais recentes, o resultado continuará errado se elas tratarem minha experiência como material para um relatório técnico.

Quanto mais trabalho repetitivo entrego à IA, mais poderosas as Skills e as regras compartilhadas se tornam. Ao mesmo tempo, elas reproduzem com mais insistência uma perspectiva equivocada. Se uma resposta isolada é estranha, posso discutir e corrigi-la na hora. Mas, se um modelo narrativo errado entra em uma Skill, a próxima sessão também me apaga da mesma forma.

De agora em diante, a primeira coisa que vou conferir em um rascunho de blog técnico não será o quanto as frases parecem convincentes nem o nível de detalhe da explicação técnica. Vou procurar primeiro se continuam presentes o problema que reconheci e as instruções e objeções com que mudei o resultado. A IA pode fazer uma quantidade enorme de trabalho por mim, mas não posso deixar que transforme em história própria até mesmo o motivo pelo qual mandei fazer esse trabalho.