Bastidores: centenas de matérias em 5 cidades numa sessão só
205 matérias ao vivo, 21 em staging, e duas quase-falhas que o processo pegou antes de ir ao ar
205 matérias ao vivo, 21 em staging, e duas quase-falhas que o processo pegou antes de ir ao ar
Publicado em 27 de setembro de 2026 · Por Brian Reis, corretor de imóveis CRECI/SC 52.398
Esta é a sessão de trabalho que melhor resume como eu opero hoje: uma única rodada gerou centenas de matérias novas em cinco cidades diferentes, e no meio do caminho quase deu errado de duas formas distintas — nenhuma delas chegou a ir ao ar errada, mas as duas mostram por que processo importa mais do que boa intenção. Não escrevo isso como vitória sem ressalva. Escrevo como registro honesto de um dia de trabalho real, com o que funcionou e com o que quase não funcionou, porque é isso que diferencia bastidor de material publicitário.
A meta era 250 matérias novas distribuídas pelos cinco portais que opero — lancamentosportobelo.com.br, lancamentosembalneario.com.br, lancamentositapema.com.br, lancamentocamboriu.com.br e lancamentopraiabrava.com.br. O resultado real foi 205 matérias publicadas ao vivo em quatro portais, mais 21 em staging aguardando a minha aplicação num quinto. Não bati a meta, e vou explicar exatamente por quê, porque é mais fácil esconder isso do que admitir. Um dos mercados regionais simplesmente saturou o que dava para escrever com qualidade e ainda ser original — depois de um certo número de matérias sobre bairro, construtora e faixa de preço do mesmo lugar, o ângulo novo começa a rarear, e forçar mais um artigo naquele tema é produzir conteúdo fraco só para preencher espaço. Ao mesmo tempo, o orçamento de busca que uso para levantar ângulo e dado real — as consultas que faço para confirmar cada número antes de publicar — esgotou antes do fim do dia. As duas coisas juntas fecharam a conta em 205 mais 21, não em 250. Essa é parte da lição desta matéria, não um detalhe para esconder: prefiro entregar 205 matérias das quais eu confio no dado de cada uma, do que forçar as 45 que faltavam com conteúdo raso só para bater um número redondo.
Rodei múltiplos agentes de IA em paralelo, um fluxo dedicado por cidade, todos trabalhando ao mesmo tempo sobre a mesma base de dados consolidada. A regra que evita corrupção nesse tipo de operação é simples de enunciar e rígida de cumprir: cada agente só cria arquivo novo, nunca edita um arquivo que outro agente também possa estar tocando — sitemap, índice do blog, arquivo de descoberta por IA. Se dois agentes escrevessem no mesmo arquivo compartilhado ao mesmo tempo, um corromperia o trabalho do outro sem aviso nenhum — o segundo salvamento simplesmente sobrescreveria o primeiro, e eu só descobriria o estrago horas depois, numa auditoria. Por isso a aplicação dos arquivos compartilhados ficou deliberadamente para depois de todos os agentes terminarem, feita por mim, uma pessoa só, um arquivo de cada vez, em sequência — é mais lento do que deixar cada agente aplicar direto, mas é a diferença entre terminar o dia com cinco portais intactos ou com um deles corrompido silenciosamente.
Uma verificação de rotina no meio da sessão encontrou algo que parecia, à primeira vista, um erro grave: dado de uma cidade aparecendo onde deveria estar o dado de outra. Antes de corrigir qualquer coisa, parei e investiguei a origem daquele dado até o commit exato que o gerou — e descobri que era um tratamento de deduplicação cross-domain aplicado de propósito em julho de 2026, para impedir que o mesmo empreendimento fosse contado duas vezes em portais diferentes da rede. O sistema estava certo. Se eu tivesse corrigido de primeira, sem investigar, teria introduzido uma duplicata real onde antes não havia nenhuma — o erro teria sido meu, criado em cima de um sistema que já funcionava.
As outras quatro investigações da mesma sessão eram reais e foram corrigidas assim que confirmadas: matérias publicadas sem o card correspondente no índice do blog — invisíveis para quem navega, mesmo estando tecnicamente no ar; entradas faltando no arquivo de descoberta por IA de um dos portais, o que reduz a chance de um agente de IA externo encontrar e citar aquele conteúdo; dado desatualizado em duas páginas específicas, que precisava ser corrigido antes que um leitor notasse a divergência; e matérias fracas duplicando o mesmo tema sem necessidade, produzidas antes de eu apertar o critério de originalidade. Nenhuma dessas quatro exigiu debate — bastou confirmar e corrigir.
Mais cedo no mesmo dia, corrigi o favicon desatualizado de cinco sites com um único script automatizado, em vez de repetir a correção manualmente cinco vezes. Esse mesmo script, sem que eu percebesse na hora, tocou também em dois arquivos que não deveriam ter sido tocados: dois documentos legais assinados — termos de intermediação contendo dado de cliente — em um dos cinco sites. Não foi uma alteração de conteúdo intencional da minha parte; foi um efeito colateral de um padrão de arquivo mais amplo do que eu havia planejado ao escrever o script. O sistema de segurança de deploy, que baixa o que já está em produção e compara arquivo por arquivo com o que está prestes a subir antes de qualquer publicação, travou sozinho por causa disso — ele não sabia exatamente o que tinha dado errado, apenas que dois documentos sensíveis haviam mudado sem uma explicação que batesse com a tarefa declarada (corrigir favicon). Investiguei os dois arquivos, confirmei que nenhum dado de cliente havia de fato sido alterado — o conteúdo sensível permaneceu intacto, apenas o arquivo tinha sido reescrito por um padrão de busca amplo demais —, revertive os dois arquivos ao estado original, e só então o deploy passou.
Na mesma sessão, medi 203 casos de uma mesma inconsistência estrutural espalhados por um dos portais da rede. Corrigi apenas 1, como piloto — decisão deliberada, não falta de tempo ou de prioridade. Validar que a correção funciona corretamente num caso isolado antes de aplicá-la nos outros 202 de uma vez evita espalhar um erro em massa por um portal inteiro; se o piloto revelar um problema que eu não previ, o custo de corrigir é de 1 arquivo, não de 203.
Nenhuma das duas quase-falhas chegou a virar erro público, e isso não foi sorte — foi o processo funcionando exatamente como desenhado: barreira automática antes do deploy, investigação antes de qualquer correção, piloto antes de escala. Uma sessão que gera centenas de matérias em cinco cidades diferentes, com múltiplos agentes de IA rodando ao mesmo tempo, só é segura de fazer porque cada uma dessas barreiras existe antes que a velocidade de produção vire risco de publicação. Tirar qualquer uma delas — a regra de arquivo compartilhado, a barreira de deploy, o hábito de investigar antes de corrigir — teria transformado pelo menos um dos dois quase-incidentes de hoje num erro real, visível, e mais caro de consertar depois do que foi de prevenir antes.
Nenhum desses números é motivo de orgulho isolado — o que importa é que cada um deles passou por uma barreira antes de virar problema real. É esse conjunto de barreiras, não a quantidade de matérias publicadas, que eu mostraria para qualquer imobiliária que perguntasse como replicar essa operação.
Quer essa mesma engrenagem de produção de conteúdo rodando pra você?
Isto é o tipo de conteúdo que sua imobiliária, construtora ou escritório poderia estar publicando toda semana — com dado real, não achismo. Eu ensino como montar essa operação (dados + IA + conteúdo) dentro da sua empresa.
Falar com Brian Reis no WhatsApp