Uma verificação de rotina virou 5 investigações — e provou que eu estava errado

Publicado em 27 de setembro de 2026 · Por Brian Reis, corretor de imóveis CRECI/SC 52.398

Toda sessão de trabalho eu passo por uma verificação de rotina antes de considerar o dia fechado: bater o que foi publicado contra o que deveria ter sido publicado. Numa dessas verificações recentes, um número não bateu — parecia que uma cidade estava exibindo dado de outra, o tipo de erro que classifico como grave porque quebra a confiança do leitor na hora em que ele percebe.

Esse tipo de checagem, na prática, é chato. É repetitivo, não produz nada novo por si só, e é justamente por isso que muita gente pula essa etapa quando o prazo aperta. Eu não pulo, e esta matéria é sobre o que aconteceu numa das vezes em que essa disciplina evitou um erro que eu mesmo teria causado.

A primeira reação não foi corrigir — foi investigar

O reflexo mais comum diante de algo que parece bug é corrigir na hora, antes que alguém perceba. Eu fiz o oposto: parei para confirmar se era mesmo um bug antes de mexer em qualquer coisa. Essa checagem abriu, no total, cinco investigações na mesma sessão — cinco pontos que mereciam confirmação antes de qualquer correção.

A investigação que provou que eu estava errado

A primeira delas — o "dado vazado" entre cidades — acabou não sendo bug nenhum. Rastreei a origem do dado até o commit que o gerou e descobri que era um tratamento de deduplicação cross-domain aplicado de propósito em julho de 2026, para evitar que o mesmo empreendimento aparecesse duplicado em dois portais da rede. O sistema estava certo. Eu que quase corrigi algo que não precisava de correção nenhuma.

Esse é, sem exagero, o melhor exemplo que tenho de por que verifico antes de aceitar meu próprio diagnóstico. Se eu tivesse corrigido de primeira, teria introduzido uma duplicata real onde antes não havia nenhuma — o erro seria meu, criado em cima de um sistema que já funcionava direito antes de eu mexer. E o pior tipo de erro é exatamente esse: o que a gente cria tentando corrigir algo que nunca esteve errado.

As outras quatro — essas sim, reais

• Matérias publicadas sem card correspondente no índice do blog — invisíveis para quem navega, mesmo estando no ar
• Entradas faltando no arquivo de descoberta por IA de um dos portais — o equivalente ao llms.txt, que passou a existir sem ser atualizado por completo
• Dado desatualizado em duas páginas específicas
• Matérias fracas duplicando o mesmo tema, sem necessidade

As quatro foram confirmadas rápido, porque o processo de confirmação é o mesmo, independente do resultado esperado: rastrear até a fonte, comparar com o que deveria estar lá, e só então decidir se corrige. Nenhuma delas exigiu debate — bastou confirmar e corrigir assim que a causa ficou clara.

O critério que ficou dessa sessão

Uma suspeita de bug não vira correção antes de eu rastrear a causa até a fonte. Rastrear custa alguns minutos a mais; corrigir algo que já estava certo custa muito mais — porque cria um problema novo em cima de um que nunca existiu, e esse problema novo é mais difícil de detectar depois, porque ninguém vai suspeitar de uma "correção" que na verdade introduziu o erro. Prefiro o primeiro custo, sempre.

Se existe uma lição que eu levaria para qualquer outra área de trabalho, não só conteúdo imobiliário, é essa: o instinto de corrigir rápido é bom quando o diagnóstico está certo e péssimo quando não está. A única forma de saber qual dos dois casos você está vivendo é investigar antes de agir — mesmo quando a pressão do prazo empurra na direção contrária.

Como eu monto essa verificação de rotina, na prática

Não é uma auditoria gigante todo dia — seria inviável de sustentar. É uma checagem objetiva contra critérios fixos: o número de matérias publicadas bate com o número esperado? Toda matéria nova tem card no índice? O arquivo de descoberta por IA lista tudo que existe? Alguma página com dado que muda com frequência não é revisada há muito tempo? Cada resposta "não" vira uma investigação — não uma correção automática.

A distinção entre "investigação" e "correção automática" é o ponto central desta matéria. Uma investigação tem uma pergunta clara ("por que este dado está assim?") e só termina quando essa pergunta tem resposta confirmada, não quando o sintoma some de vista. Uma correção automática apaga o sintoma sem necessariamente responder a pergunta — e é exatamente esse atalho que quase me fez estragar um sistema que já estava certo.

O que eu faria diferente da próxima vez

Nada, na verdade — e isso é o ponto. O processo funcionou como deveria: encontrou uma anomalia, não presumiu a causa, investigou, e só corrigiu o que de fato precisava de correção. A única mudança que fiz depois foi documentar o caso da deduplicação cross-domain de julho de forma mais visível, para que uma futura verificação de rotina não precise refazer a mesma investigação do zero se o mesmo padrão aparecer de novo.

Há uma tentação de tratar esse tipo de verificação como desperdício de tempo em dias corridos — afinal, na maioria das vezes ela não encontra nada. Mas o valor dela não está na frequência com que encontra problema, está em ser a única coisa que separa um erro publicado de um erro pego a tempo. Cinco investigações numa única sessão, com quatro confirmadas e uma refutada, é exatamente o tipo de proporção que justifica manter a rotina mesmo nos dias em que ela parece só confirmar que está tudo certo.

Uma pergunta que me fazem quando conto esse caso é se eu não fico paranoico, desconfiando de tudo o tempo todo. Não é bem isso. A investigação só entra quando algo sai do padrão esperado — a maior parte do cadastro segue o padrão, e essas partes não geram investigação nenhuma. O que muda é que, quando algo sai do padrão, o próximo passo nunca é corrigir de primeira: é sempre confirmar antes. É uma regra estreita, aplicada só ao que já chamou atenção — não uma vigilância constante sobre tudo.

Guardo os dois tipos de caso — o que confirma erro real e o que refuta a suspeita — com o mesmo cuidado, porque os dois ensinam algo diferente. O caso confirmado ensina onde o processo ainda tem um ponto fraco a corrigir. O caso refutado ensina que uma parte do sistema, que eu poderia ter mexido sem necessidade, já estava funcionando como deveria. As duas informações valem a pena documentar, mesmo que só a primeira pareça, à primeira vista, digna de virar aprendizado registrado.

No fim, o que essa sessão me deixou não foi só a memória de um caso curioso — foi a confirmação, com evidência concreta, de que a disciplina de investigar antes de corrigir vale o tempo que consome, mesmo nos dias em que parece exagero.