Por que escrevo os termos técnicos com explicação ao lado?

Neste blog, quando escrevo um termo técnico, coloco sempre uma explicação curta logo ao lado.

Por exemplo: se menciono "separação de poderes" (aqui: a ideia de dividir as funções de execução, auditoria e aprovação entre agentes distintos, trazida ao mundo das IAs), já continuo explicando na mesma frase. Se menciono "subagent" (aqui: um agente auxiliar — uma IA que recebe uma tarefa específica dentro de um sistema maior), adiciono uma palavra para quem nunca ouviu o termo não se perder.

Essa é uma das pequenas regras deste projeto. Internamente, chamo isso de "regra da linguagem simples". Neste capítulo, vou escrever sobre a regra em si — por que me dou ao trabalho de colocar essas explicações.

Onde o leitor trava quando só aparecem termos técnicos

Experimente, e você vai notar: quando termos técnicos se sucedem sem pausa, a construção de sentido na cabeça do leitor simplesmente para.

Imagine este trecho:

"Neste projeto, o subagent Copywriter gera o texto com base no SPEC (aqui: o documento de especificações que define o que a IA deve fazer), e o Brand Voice Editor (aqui: o agente responsável por checar o tom e a voz do texto) realiza a verificação de tom antes de o texto passar pelo QA gate (aqui: o ponto de controle de qualidade)."

Para quem projeta e implementa sistemas todo dia, é uma frase normal. Mas para quem está começando a usar IA agora, já no primeiro "subagent" a leitura trava. Quando vêm "SPEC", "Brand Voice Editor" e "QA gate" em sequência — palavras desconhecidas uma atrás da outra — a estrutura da frase pode até fazer sentido, mas o que está acontecendo de verdade não se forma na cabeça.

Isso não é problema do escritor. É que o leitor não tem, ainda, as gavetas de contexto necessárias. Quando três ou mais palavras desconhecidas aparecem seguidas, o cérebro humano não pensa "vou pesquisar depois" — ele decide: "esse artigo não é pra mim". Eu mesmo fazia isso quando estava do lado de quem lê.

Por isso: coloco a explicação ao lado. Não como um parágrafo de explicação extra — só uma palavra ou expressão entre parênteses, direto depois do termo. subagent (aqui: agente auxiliar), cron (aqui: mecanismo que executa tarefas automaticamente em horários definidos), Kill Switch (aqui: interruptor de emergência para travar uma ação da IA) — algo nesse estilo. Só isso já reduz bastante o esforço de quem não conhece o termo para acompanhar o texto.

Para quem é essa explicação, afinal?

Vou ser honesto sobre a motivação por trás dessa regra: no começo, não estava pensando tanto no leitor. A razão era mais egoísta — "se eu escrever de forma mais clara, eu mesmo organizo melhor meu pensamento".

Mas enquanto escrevia, percebi algo: o ato de explicar ao lado, passo a passo, estava, como resultado, ampliando o perfil de quem conseguia acompanhar o texto.

O leitor típico que tenho em mente neste blog é alguém descrito nas minhas notas de projeto como: "tem boa fluência em tecnologia, mas o mundo de agentes de IA (aqui: sistemas onde várias IAs trabalham juntas, coordenadas) é fora da sua área". Algo como um responsável de sistemas ou analista interno em uma empresa de médio porte, na faixa dos 30 aos 40 anos, que já usa IA no dia a dia, mas trava em "quem gerencia vários agentes e como".

Quando só aparecem termos técnicos, a reação é "parece difícil" — e a pessoa para. Mas quando tem uma explicação curta ao lado, a reação vira "ah, é isso" — e ela continua lendo.

E o passo seguinte — "parece que eu também consigo fazer isso" — é onde está o ponto mais importante. Ler um texto cheio de termos técnicos termina em "uau, impressionante" — e só. Quando está escrito em palavras comuns — "tentei assim, e foi isso que aconteceu" — algo se move: "talvez eu também tente". Essa segunda reação é a que está alinhada com o objetivo deste projeto, por isso faço isso de forma intencional.

O que percebi do lado de quem escreve: vira um teste do próprio entendimento

Depois de rodar essa regra por um tempo, percebi um efeito secundário. Quando tento explicar um termo técnico com palavras simples, fico sabendo com clareza o quanto eu mesmo entendo aquele termo.

Por exemplo: existe o termo "aprovação passiva" (aqui: um mecanismo em que, se nenhum bloqueio chegar dentro de um prazo definido, a aprovação é dada automaticamente). É um mecanismo que uso neste projeto. Quando tentei explicá-lo em uma frase simples, no começo não consegui escrever bem. "Se você não disser nada, considera-se aprovado" — escrevi, mas o nuance estava errado. "Define-se um prazo de bloqueio, e ao vencer o prazo, a aprovação acontece" — assim ficou mais próximo.

Passando por esse processo, tenho a sensação de que a intenção que tive ao projetar o mecanismo, o que ele faz na prática, e a precisão com que consigo colocar isso em palavras — tudo vai se alinhando. Por outro lado, quando consigo escrever um termo técnico sem parar para pensar, às vezes é porque estou apenas me apoiando no jargão — e aí há risco de que eu não esteja entendendo de verdade.

Percebi que conseguir escrever uma palavra difícil do jeito que está pode ser uma forma de esconder uma compreensão rasa. Depois dessa percepção, passei a usar a regra da linguagem simples não como algo "para o leitor", mas como um "teste do meu próprio entendimento". Hoje, esse efeito colateral é o que mais valor gera pra mim.

Se você entende de verdade, consegue explicar até para um estudante do ensino fundamental. Se não consegue explicar, é porque o entendimento ainda não está completo — então volto ao projeto e revejo. É assim que essa regra funciona como um ciclo de feedback.