Como validar uma automação antes de colocar no ar: as checagens que usamos na Cordexo
Como validar uma automação antes de colocar no ar: as checagens que usamos na Cordexo
A esteira de conteúdo da Cordexo roda desde o fim de junho com um agente de IA executando o ciclo inteiro: blog, post de LinkedIn, carrossel de Instagram, legenda e roteiros de vídeo, tudo numa execução só, sem etapa de rascunho. O post sai publicado direto. Este é o décimo quinto ciclo.
Publicar direto, sem revisão humana peça por peça, só é viável por causa de uma camada que quase ninguém comenta quando fala de automação: as checagens automáticas que rodam antes de qualquer entrega ser considerada pronta. Este texto mostra quais são as nossas, de onde cada uma veio e como o mesmo raciocínio se aplica a qualquer automação de PME, de confirmação de pedido a resposta de WhatsApp.
Toda checagem nossa nasceu de um defeito publicado
Nos cinco primeiros ciclos, a esteira entregou defeito real. Slides de carrossel saíram com texto cortado na miniatura do grid do Instagram. Os títulos renderizaram numa fonte genérica porque a biblioteca de renderização ignorava silenciosamente a fonte da marca, e ninguém percebeu por cinco ciclos seguidos. Os blogs saíram com até 13 travessões por texto, o sinal de pontuação que mais denuncia texto escrito por IA.
Em cada um desses casos a tentação era a mesma: colocar um humano para revisar tudo antes de publicar. Seria o fim da automação, porque revisar seis peças por ciclo custa quase o mesmo tempo que produzi-las. A decisão foi outra: cada defeito virou uma checagem de código que roda em todo ciclo, para sempre.
Hoje, antes de um ciclo ser dado como concluído, o próprio agente executa cinco verificações.
A primeira é a medição de largura de texto. Cada linha de cada slide é renderizada e medida em pixels antes de virar imagem. Se uma frase mede 750 pixels num espaço de 720, ela é barrada e reescrita antes de existir como arquivo. No ciclo passado, essa trava segurou um subtítulo de capa que teria saído cortado.
A segunda é a varredura de borda. Depois de renderizar, um script abre cada PNG e verifica pixel a pixel se há conteúdo nas faixas laterais que a miniatura do Instagram corta. A capa tem zona de segurança reforçada, porque descobrimos no perfil real que capas antigas apareciam com o título amputado no grid.
A terceira é a checagem de fonte. Um comando confirma que a fonte da marca está de fato instalada no ambiente antes de renderizar. Existe porque a falha foi silenciosa: a imagem saía bonita, só que com a fonte errada, e a olho nu no meio do fluxo ninguém notou.
A quarta é a busca de travessão. Todo arquivo de texto passa por uma busca literal pelo caractere antes de ser fechado. O resultado precisa ser zero. É uma checagem boba de escrever e impossível de esquecer, que é exatamente o ponto.
A quinta é a validação estrutural: quantidade de slides dentro do limite, dimensão exata de 1080 por 1350, imagem de capa do blog conferida contra a tabela de URLs já usadas, para nunca repetir.
O princípio: automação que confere automação
O padrão por trás das cinco checagens é um só. Quando a automação erra, existem três respostas possíveis. Ignorar, e o erro se repete. Colocar um humano revisando tudo, e a automação deixa de compensar. Ou transformar aquele erro específico numa verificação automática, e ele nunca mais passa.
A terceira resposta tem uma propriedade que as outras não têm: ela acumula. Cada ciclo herda todas as travas dos ciclos anteriores. O sistema de hoje é mais confiável que o de junho não porque o modelo de IA melhorou, mas porque a lista de verificações cresceu.
Isso muda também o papel do humano. O Leandro não revisa mais se o slide está cortado ou se a fonte está certa: código faz isso melhor e sem cansaço. A revisão humana subiu de nível e ficou concentrada no que código não pega: o ângulo do conteúdo faz sentido? O exemplo é bom? A opinião é defensável? Menos tempo conferindo pixel, mais tempo conferindo ideia.
Como aplicar isso na sua operação
O mesmo desenho vale para automações muito mais comuns que uma esteira de conteúdo. Alguns exemplos de checagens baratas que uma PME pode acoplar às suas automações:
Num fluxo de confirmação de pedido de e-commerce, antes de disparar a mensagem: o valor total bate com a soma dos itens? O nome do cliente veio preenchido ou vai sair "Olá, {nome}"? O link de rastreio responde?
Numa automação de atendimento por WhatsApp, uma rotina que roda todo dia sobre as conversas do dia anterior: quantas respostas citaram preço? Esse preço bate com a tabela vigente? Quantas conversas terminaram sem resposta?
Numa rotina de emissão de boletos ou cobranças: o vencimento gerado é uma data futura? O valor está dentro da faixa esperada para aquele tipo de cliente? Valores fora do padrão entram numa fila de conferência humana em vez de sair sozinhos.
Nenhuma dessas verificações exige projeto grande. A maioria é uma condição de poucas linhas dentro do fluxo que já existe. O que exige método é o hábito: toda vez que a automação errar em produção, a pergunta não é "quem deixou passar", é "qual checagem impediria isso de passar de novo". Se a resposta virar código, o erro morreu ali.
Uma automação sem checagens não é mais barata, ela só empurra o custo da conferência para o cliente que recebeu a mensagem errada. As nossas cinco travas custaram algumas horas para escrever, distribuídas ao longo de quinze ciclos. O que elas seguram todo ciclo, texto cortado, fonte errada, imagem repetida, custaria a credibilidade que o conteúdo existe para construir.
