Vibe Analysis: Decisões baseadas em dados sem saber programar

Tem um cenário que se repete em organizações de todos os tamanhos: dados disponíveis, decisão urgente — e a sensação de que algo importante está escondido nas planilhas, mas não há tempo, nem ferramenta, nem especialista disponível para encontrá-lo. A saída mais honesta seria admitir: a decisão vai ser tomada no achismo, como sempre.

Essa não é uma história incomum. É a rotina de gestores, líderes de equipe e profissionais que operam com dados todos os dias — mas sem autonomia real para conversar com eles. A estatística fica com o analista. O insight fica represado. A decisão não espera.

Eu vivi essa frustração em dois contextos completamente diferentes. No SaaS, analisando dados de uso de produto na Jetbov — eventos de relatório, padrões de acesso, indicadores de churn silencioso — e percebendo que a maioria das decisões de produto era tomada sobre impressões, não sobre evidência. E na pesquisa de mestrado, cruzando dados de depleção de ozônio da NASA com registros de internação por glaucoma do DataSUS, onde o rigor metodológico era exigência, mas o acesso a especialistas era limitado.

Em ambos os casos, o problema não era falta de dados. Era falta de método para conversar com eles.

Foi dentro dessa tensão que surgiu o Vibe Analysis.

A origem do nome — e o que ele não significa

Em 2023, Andrej Karpathy cunhou o termo vibe coding para descrever uma forma de programar guiada pela intenção e pelo diálogo com a IA — sem necessariamente entender cada linha do que está sendo produzido. O objetivo era produtividade; o efeito colateral era abrir mão do entendimento. O programador virava curador de outputs que não conseguia mais rastrear.

Vibe Analysis herda o nome e inverte o vetor.

A ideia central é a mesma: usar IA como parceiro de trabalho, guiado pela intenção e pelo contexto. Mas o objetivo é o oposto: em vez de abdicar do entendimento em nome da velocidade, o método existe para aprofundar o entendimento usando a IA como ferramenta operacional — mantendo o raciocínio sempre nas mãos de quem analisa.

O “vibe” é o ponto de partida. Você traz a intuição, o incômodo, a suspeita sobre os dados. O método transforma isso em análise com estrutura — sem exigir que você saiba programar ou dominar estatística.

Isso importa porque define quem o método serve: não apenas analistas e engenheiros de dados, mas qualquer profissional que precisa tomar decisões baseadas em dados e não tem background técnico para conduzir análises sozinho.

O que é Vibe Analysis — e o que não é

Vibe Analysis é um método estruturado de construção de conhecimento a partir de dados, orientado por curiosidade genuína e executado em parceria com IA — sem exigir conhecimento técnico do operador.

O ponto de partida não é o dado — é o contexto e a pergunta que você traz. A decisão emerge do processo, não o inicia.

O que o VA é:

• Um método estruturado para conduzir análises de dados com IA como ferramenta operacional
• Um framework de raciocínio investigativo que qualquer profissional pode aprender e aplicar
• Uma forma de transformar perguntas de negócio em decisões baseadas em evidência
• Um processo que começa pelo problema, não pela técnica

O que o VA não é:

• Não é um curso de estatística ou programação
• Não é uma ferramenta, software ou plataforma — funciona com qualquer IA de mercado
• Não é substituto para análises complexas que exigem modelagem avançada
• Não é um atalho para terceirizar o raciocínio para a IA — o julgamento é sempre do operador

A distinção mais importante: o VA não ensina a analisar dados. Ele ensina a fazer as perguntas certas para que a análise aconteça. A técnica é da IA; o raciocínio é do operador.

O que diferencia de outras abordagens

Quando você joga um CSV no ChatGPT e pede “analisa esses dados pra mim”, você recebe uma resposta. Frequentemente bem formatada, com insights aparentemente sólidos. O problema é que o modelo responde à pergunta que você fez — não necessariamente à pergunta que você deveria ter feito. Sem estrutura, sem diagnóstico do dado, sem camadas progressivas de questionamento, você tem um analista muito articulado confirmando o que você quer ouvir.

Dimensão	IA sem método	Vibe Analysis
Ponto de partida	A pergunta literal	O contexto + a pergunta + o briefing
Diagnóstico dos dados	Raramente explícito	Etapa obrigatória antes de qualquer análise
Profundidade	Camada descritiva na maioria dos casos	Três camadas progressivas: descritiva, diagnóstica, preditiva
Causalidade	Frequentemente afirmada sem evidência	O operador é instruído a questionar toda conclusão
Quando voltar atrás	Nunca — a análise segue linear	5 pontos de retorno formalizados na metodologia
Produto final	Insights e gráficos	Narrativa de Decisão em 3 frases acionáveis

O elemento que mais diferencia na prática é o último: toda sessão de Vibe Analysis termina com uma Narrativa de Decisão — não necessariamente um relatório ou um dashboard, mas três frases que qualquer pessoa na sala consegue entender e agir em cima.

Os 4 pilares do método

Antes das etapas, quatro princípios atravessam toda a metodologia:

Contexto antes de código. A pergunta certa vale mais que a análise perfeita. O VA começa pelo problema, não pelos dados. Antes de qualquer análise, o método exige a construção explícita do contexto: o que esse dado representa no mundo real? O que você já sabe? O que mudaria sua decisão se fosse verdade?

Perguntas em camadas. O raciocínio analítico segue três níveis progressivos: o que aconteceu (descritivo), por que aconteceu (diagnóstico) e o que isso significa para o futuro (preditivo). A maioria das análises para na primeira camada e chama isso de conclusão. O método ensina a descer as três.

A IA como espelho, não como oráculo. A IA vai dar respostas com a mesma confiança quando está certa e quando está errada. O VA define com clareza o papel de cada um: a IA organiza, calcula, cruza e sugere. O operador questiona, contextualiza e decide. A autonomia analítica nunca sai das mãos de quem analisa.

Da análise à Narrativa de Decisão. O último passo não é o gráfico — é a frase. A conclusão que você consegue dizer numa reunião, defender para um investidor, comunicar para um time. O método só termina quando você responde: o que aprendi, o que isso muda, e qual é o próximo passo.

As 10 etapas — as três fases do método

O Vibe Analysis tem dez etapas organizadas em três fases sequenciais. A ordem importa: não se pula etapas, e há cinco pontos de retorno formalizados onde a análise pode — e deve — voltar atrás quando necessário.

---

FASE 1 — PREPARAÇÃO

O trabalho que acontece antes de abrir a IA

A maioria dos erros numa sessão de VA não acontece durante a análise. Acontece antes — quando o operador pula direto para a IA sem ter definido o contexto nem formulado uma pergunta real.

Etapa 1 — Contexto e pergunta

Ninguém chega para uma análise com uma decisão pronta na cabeça. O que existe no início é um incômodo, uma dúvida, uma suspeita ou uma necessidade. O VA começa exatamente aí.

A decisão não é o ponto de partida — é o que emerge do processo. Forçar uma conclusão antes da análise é o caminho mais curto para o viés de confirmação: você vai usar os dados para confirmar o que já acredita, não para descobrir o que ainda não sabe.

Uma boa pergunta de partida tem três características: é genuína (existe uma dúvida real, não uma conclusão a confirmar), está ancorada em dados (existe informação disponível que pode iluminá-la), e é relevante para uma ação (o que você descobrir vai mudar alguma coisa no que você faz).

Veja abaixo alguns exemplos destes conceitos:

Ponto de partida vago	Pergunta analisável
”Quero entender minhas vendas"	"Por que as vendas de março caíram e o que isso indica para o próximo trimestre?"
"Quero ver o desempenho da equipe"	"Existe padrão nos resultados que diferencie os colaboradores que superam metas dos que não superam?"
"Quero analisar os custos"	"Existe alguma categoria de custo crescendo acima da receita que mereça atenção imediata?”

Etapa 2 — Captura de dados

Com o contexto e a pergunta definidos, a próxima pergunta a fazer ao agente é: quais dados preciso para começar a respondê-la?

Sabendo quais dados preciso para começar a respondê-la, você irá avaliar: eu tenho esses dados? Onde estão? Em que formato? É neste momento que você vai verificar ou com alguém do seu time ou você mesmo irá obter os dados necessários. Porém, você irá obter os dados de forma mais eficaz do que ficar pegando uma série de dados sem necessidade real.

Esta etapa existe para evitar o erro de chegar à análise com os dados errados — e perceber isso no meio da sessão.

Um prompt útil para mapear o que você precisa antes de buscar os dados:

Para a decisão que defini, complete as frases:
Para tomar essa decisão com mais segurança, eu precisaria saber…
Os números que mais influenciariam minha escolha são…
O período de tempo relevante para essa análise é…
As comparações que fariam sentido aqui são…

Claro, que durante a sessão você e o agente sintam a necesside de adicionar mais dados, e tá tudo bem isso também.

Etapa 3 — Conhecer os dados

Você tem os dados em mãos. Antes de fazer qualquer pergunta analítica, é preciso entender o que está diante de você. Esta etapa tem dois momentos distintos.

Momento 3A — Reconhecimento humano (antes de enviar para a IA): Dois minutos olhando para os dados sem análise. Quantas colunas existem e se os nomes fazem sentido imediato. Quantas linhas — para ter dimensão de escala. Se há algo visivelmente estranho: colunas vazias, linhas duplicadas à vista, formatos inconsistentes.

Este momento existe por um motivo crítico: você não pode questionar o que a IA encontrou se nunca tocou nos dados. O Pilar 3 — a IA como espelho, não como oráculo — exige que o operador tenha uma referência própria para avaliar o que a IA vai entregar.

Momento 3B — Diagnóstico pela IA: Agora você abre a IA e conduz um diagnóstico estruturado com prompts sequenciais:

Vou te enviar um arquivo de dados. Antes de qualquer análise, preciso que você faça um diagnóstico completo do que está aqui. Para cada coluna: diga o nome exato, infira o que ela provavelmente representa no mundo real, identifique o tipo de dado, aponte qualquer anomalia já visível. Para as colunas cujo significado você não consegue inferir com segurança, faça uma pergunta direta. Não suponha — pergunte.

Qual é o intervalo de tempo coberto por estes dados? Qual é a granularidade temporal? Há lacunas no período? Minha pergunta principal é: [repita sua pergunta]. O período coberto é suficiente para respondê-la com confiança?

Faça um diagnóstico de qualidade completo: valores ausentes por coluna com percentual, duplicatas, inconsistências, outliers visíveis. Para cada problema encontrado, avalie: isso compromete a análise ou é gerenciável?

Com base em tudo que você diagnosticou, me entregue um resumo: o que os dados contêm, período e granularidade, problemas de qualidade e nível de impacto, e sua avaliação: estes dados estão prontos para análise?

Ponto de retorno B — Dados insuficientes: Se o diagnóstico revelar problemas graves — período curto demais, colunas-chave com alta proporção de nulos, granularidade incompatível com a pergunta — não avance para a Etapa 4. Volte à Etapa 2 com um pedido mais preciso. Construir um briefing sobre dados inadequados é construir sobre areia.

Etapa 4 — Construir o briefing

O briefing é o contexto que você entrega à IA antes de qualquer pergunta de análise. É o investimento de cinco minutos que economiza trinta minutos de resultados inúteis. Um briefing bem construído transforma a qualidade de toda a sessão.

Contexto: [quem você é, o que sua operação faz, qual é o momento atual]. Dados: [o que cada coluna representa, o que cada linha representa, qual período está coberto]. Decisão: [a ação concreta que você precisa tomar]. O que já sei: [hipóteses prévias, eventos relevantes do período, contexto que os dados não mostram]. O que não quero: [análises genéricas, conclusões óbvias, sugestões fora do contexto].

O critério de um bom briefing é simples: depois de ler isso, a IA consegue me fazer uma pergunta inteligente de volta?

---

FASE 2 — EXECUÇÃO

A sessão em si — onde a conversa com os dados acontece

Você chegou aqui com contexto e pergunta definidos, dados diagnosticados, território reconhecido e briefing construído. São quatro etapas — três camadas progressivas de perguntas e uma postura permanente que deve atravessar toda a execução.

Regra de ouro: resista à tentação de pular direto para a conclusão. A qualidade da análise é proporcional à profundidade com que você percorreu as camadas.

Etapa 5 — Camada descritiva: o que aconteceu?

A camada descritiva é o ponto de partida obrigatório. Antes de interpretar, antes de diagnosticar — você precisa saber o que está acontecendo nos dados. O objetivo não é revelar algo surpreendente — é construir o chão firme sobre o qual as próximas camadas vão se apoiar.

Com base nos dados que enviei e no contexto do briefing, me dê uma visão geral do que está nos dados. Quais são os principais números? Qual é a escala do que estou analisando? Não interprete ainda — me mostre o que está aqui.

Analisando o período coberto pelos dados, qual é a tendência geral? Houve crescimento, queda ou estabilidade? Em que momento a tendência mudou, se mudou?

Como os dados estão distribuídos? Existe alguma concentração relevante — um período, um grupo ou uma categoria que representa a maior parte do resultado? Existe algo que destoa claramente do restante?

“Compare [grupo A] com [grupo B] nos dados. Quais são as diferenças mais relevantes em termos absolutos e em termos percentuais?”

Etapa 6 — Camada diagnóstica: por que aconteceu?

A camada diagnóstica é onde a maioria das análises para — e não deveria. Ver o que aconteceu é o começo. Entender por que aconteceu é o que transforma observação em conhecimento.

Correlação não é causa. A IA vai identificar padrões e relações entre variáveis. Mas a conclusão de que A causou B exige o julgamento do operador sobre o contexto real.

Com base no padrão que identificamos, quais fatores nos dados podem estar relacionados a esse resultado? Não afirme causalidade — aponte correlações e relações que merecem investigação.

Tenho uma hipótese: [descreva sua suspeita]. Os dados suportam ou contradizem essa hipótese? O que você vê nos dados que confirma ou contradiz isso?

Em que momento os dados mudam de comportamento? Existe um ponto de inflexão claro? O que mudou antes e depois desse ponto?

Você identificou [padrão X]. Quero acrescentar um contexto que os dados não mostram: [descreva o evento ou decisão real]. Considerando isso, como você revisaria a interpretação anterior?

Ponto de retorno C — Nova dúvida descritiva: A camada diagnóstica frequentemente revela perguntas que a camada descritiva não respondeu. Se durante a investigação de causa surgir uma dúvida sobre o que aconteceu — um número não explorado, um período não analisado — volte à Etapa 5 antes de avançar. Diagnósticos construídos sobre base descritiva incompleta produzem explicações frágeis.

Etapa 7 — Camada preditiva: o que isso significa daqui pra frente?

A camada preditiva é onde o dado vira decisão. Você entendeu o que aconteceu e por que aconteceu — agora a pergunta é: o que isso implica para o que você vai fazer?

Com base na tendência identificada, se os fatores atuais se mantiverem, qual seria o resultado esperado para os próximos [período]? Não precisa ser preciso — quero entender a direção e a magnitude possível.

Se a causa que identificamos for [endereçada / mantida / agravada], qual seria o impacto esperado? Me apresente dois cenários: um com intervenção e um sem intervenção.

Com base nos padrões dos dados, o que representa um risco que merece atenção? Existe alguma tendência negativa que, se não endereçada, pode se tornar um problema maior?

Minha pergunta original era: [repita a pergunta]. Com base em tudo que analisamos, o que os dados dizem sobre ela? Que decisão ou ação eles indicam?

Ponto de retorno D — Hipótese nova surge: A camada preditiva é onde causas não investigadas frequentemente aparecem. Se ao projetar consequências surgir uma hipótese causal que não foi explorada na camada diagnóstica, volte à Etapa 6 antes de concluir. Projeções construídas sobre diagnósticos incompletos geram cenários enganosos.

Etapa 8 — O operador questiona a IA

Esta não é uma etapa que acontece depois das outras três. É uma postura permanente que deve estar presente em cada resposta recebida. O raciocínio analítico é sempre responsabilidade do operador.

Exigir evidência, não apenas conclusão:

Você afirmou que [repita a conclusão]. Quais dados específicos nos meus dados suportam essa afirmação? Me mostre os números que levam a essa conclusão.

Questionar o que não foi dito:

O que você não consegue analisar com os dados que tenho? Quais informações adicionais tornariam essa análise mais sólida?

Testar a robustez das conclusões:

Essa conclusão depende de quais premissas? Se [premissa X] não for verdadeira no meu contexto, a conclusão muda? Qual seria o argumento contrário mais forte?

Aplicar o advogado do diabo:

Minha hipótese inicial era [descreva]. Os dados confirmam isso. Quero que você atue como advogado do diabo: qual é o argumento mais forte de que estou errado?

Ponto de retorno A — Evidência frágil: Se ao questionar a IA você perceber que uma conclusão não tem dados específicos que a sustentem — só uma narrativa coerente — não avance. Volte à camada descritiva e peça explicitamente os números que justificam a afirmação. Conclusões sem evidência não informam decisões: criam a ilusão de que informam.

---

FASE 3 — SÍNTESE

Transformar o que foi descoberto em algo acionável

A análise está feita. Agora vem a etapa que a maioria ignora — e que é a razão de tudo que veio antes: transformar o que você descobriu em uma decisão clara e comunicável.

Uma análise que não termina em ação é um exercício intelectual. Interessante, talvez. Útil para o negócio, não.

Etapa 9 — Narrativa de Decisão

A Narrativa de Decisão é o produto final de uma sessão de VA. Não é um relatório, não é um dashboard. É uma estrutura de três frases que qualquer pessoa na sala precisa conseguir entender e agir em cima.

O que aprendi: a descoberta central da análise — o fato ou padrão mais relevante que os dados revelaram. Uma frase. Sem rodeios.

O que isso muda: o impacto da descoberta na sua visão anterior. O que você acreditava antes que agora precisa ser revisto, confirmado ou descartado.

Qual é o próximo passo: a ação concreta decorrente da análise. Específica, com responsável e prazo se possível. É aqui que o dado vira decisão.

Com base em tudo que analisamos, me ajude a construir uma síntese em três partes:
O que aprendi: qual é a descoberta mais importante e mais bem suportada pelos dados?
O que isso muda: o que eu acreditava antes que precisa ser revisto?
Qual é o próximo passo: qual ação concreta decorre dessa análise?
Seja direto. Uma frase para cada item.

Um exemplo concreto de como essa estrutura funciona na prática — usando dados de uma pesquisa científica sobre impacto ambiental:

Decisão em análise: Devo publicar a descoberta sobre microplásticos no estuário local?

O que aprendi: Encontramos uma concentração 3x maior de polímeros do que o 
esperado, porém a amostragem foi feita logo após um evento de enchente atípico.

O que isso muda: A conclusão de que o ecossistema está permanentemente degradado 
pode ser precipitada — os dados refletem um pico sazonal (outlier) e não a 
linha de base estável da região.

Próximo passo: Coletar novas amostras em período de seca para isolar o 
efeito do escoamento urbano pluvial. 
Responsável: Lab. Oceanografia. 
Prazo: Outubro/2026.

Ponto de retorno E — Pergunta errada: Os limites honestos às vezes revelam algo mais profundo: que a pergunta com que você começou não era a pergunta certa. Isso não é fracasso — é um resultado valioso. Se os limites mostram que sua pergunta original estava mal formulada, o processo recomeça do início com uma pergunta mais precisa. Uma sessão que termina com uma pergunta melhor é tão valiosa quanto uma que termina com uma resposta.

Etapa 10 — Limites honestos

Toda análise tem um alcance. Declarar os limites não é fraqueza — é o que garante que a decisão está baseada em evidência real, não em lacunas preenchidas por suposição disfarçada de conclusão.

Antes de encerrarmos, quero mapear os limites honestos do que concluímos. Seja rigoroso! Para cada conclusão principal:

1. O que os dados suportam com solidez?
2. O que é hipótese que os dados sugerem mas não confirmam?
3. O que está completamente fora do alcance desta análise?

O que os dados DIZEM	O que os dados NÃO DIZEM
As vendas caíram 18% em março comparado à média dos 3 meses anteriores	Por que as vendas caíram — isso exige contexto qualitativo que os dados não têm
Clientes com 2+ compras têm taxa de reativação 5x maior que clientes com 1 compra	Se uma campanha vai funcionar — isso depende do canal, da oferta e do timing
O custo operacional cresceu 23% enquanto a receita cresceu 11% no mesmo período	Qual categoria de custo é responsável pelo crescimento — isso exige dado mais granular

Uma sessão está completa quando você consegue preencher cinco linhas de memória, sem consultar a análise: a pergunta original era… / o que aprendi… / o que isso muda… / o próximo passo é… / o limite desta análise é…

---

Vibe Analysis na prática: walkthrough completo

Para tornar concreto tudo que foi descrito, vou deixar como exemplo (resumido) como poderia ser um cenário de uma análise usando o dataset público Brazilian E-Commerce Public Dataset da Olist do Kaggle — ~100 mil pedidos reais de uma plataforma de e-commerce brasileira, entre 2016 e 2018. Dataset público, com sujeira real e relações não óbvias.

A pergunta de entrada: “Quero entender o que afeta a avaliação dos pedidos — o que faz um cliente dar nota 1 ou nota 5?”

Parece direta. Não é.

Fase 1 na prática — Preparação

Etapa 1: A pergunta está bem formulada — é genuína, está ancorada em dados disponíveis, e a resposta vai informar uma decisão concreta de operação ou logística.

Etapa 2: Os dados necessários são claros: pedidos (com datas e status), avaliações (com nota), itens (com valor e frete) e pagamentos. Todos disponíveis no dataset.

Etapa 3A — Reconhecimento humano: Antes de abrir a IA, dois minutos nos arquivos. Quatro CSVs. O de avaliações tem uma coluna de comentário de texto que parece estar muito vazia. O de pedidos tem múltiplas colunas de data. Há algo a investigar antes de começar.

Etapa 3B — Diagnóstico pela IA:

Usuário: Vou te enviar quatro arquivos CSV do dataset Olist. Antes de qualquer análise, preciso de um diagnóstico completo: para cada coluna de cada arquivo, diga o nome, o que provavelmente representa, o tipo de dado e qualquer anomalia. Para colunas ambíguas, faça perguntas diretas.

Agente: Diagnóstico concluído. Reporto três pontos antes de prosseguir:

RED FLAG 1: O arquivo reviews tem 58,7% de valores ausentes na coluna review_comment_message. A coluna review_score — que é nossa variável central — está 100% preenchida. Recomendo seguir sem análise de texto por ora.

RED FLAG 2: Calculei o atraso em dias entre order_estimated_delivery_date e order_delivered_customer_date. O valor máximo é 188 dias. Investiguei: são 7 pedidos com entrega confirmada, não erros de dado — todos com nota 1. Manterei na análise e documentarei como casos extremos.

RED FLAG 3: As datas de compra cobrem 2016 a 2018, com concentração em 2017-2018. O período é suficiente para análise de padrão, mas sazonalidade (Black Friday, Natal) pode ser fator de confusão — precisaremos controlar isso nas camadas diagnóstica e preditiva.

Os dados estão prontos para análise com as ressalvas documentadas. Posso prosseguir?

Etapa 4 — Briefing:

Usuário: Contexto: sou analista de operações de uma plataforma de e-commerce. Dados: quatro arquivos do dataset Olist — pedidos, avaliações, itens, pagamentos, cobrindo ~100k pedidos entre 2016-2018. Decisão: quero entender o que afeta a nota do cliente para priorizar melhorias operacionais. O que já sei: intuitivamente atraso na entrega deve impactar a nota, mas não sei se é o único fator. O que não quero: análises genéricas sobre “experiência do cliente” — quero os fatores mensuráveis nos dados que se correlacionam com a nota.

Fase 2 na prática — Execução

Camada descritiva — o que aconteceu?

Usuário: Com base nos dados e no briefing, me dê uma visão geral. Não interprete ainda — me mostre o que está aqui.

Agente: Visão geral do dataset consolidado (96.353 pedidos após merge):

Distribuição de notas:

Nota	Pedidos	% do total
★☆☆☆☆ (1)	11.308	11,7%
★★☆☆☆ (2)	3.151	3,3%
★★★☆☆ (3)	8.132	8,4%
★★★★☆ (4)	19.021	19,7%
★★★★★ (5)	57.145	59,2%

Observação descritiva: a distribuição é fortemente bimodal — maioria absoluta em 5, segundo maior grupo em 1. O meio da escala é sub-representado. Isso sugere que o cliente ou está muito satisfeito ou muito insatisfeito. Antes de interpretar causas, você quer que eu explore a tendência temporal das notas ou sigo para a distribuição por variáveis operacionais?

Usuário: Segue para as variáveis operacionais. Hipótese principal: atraso na entrega.

Agente: Nota média por faixa de atraso na entrega:

Faixa de atraso	Nota média	N pedidos
30+ dias antes do prazo	4,41	8.203
14–30 dias antes	4,38	21.847
7–14 dias antes	4,21	24.611
0–7 dias antes	3,98	17.429
0–7 dias de atraso	2,63	4.102
7–30 dias de atraso	1,89	1.412
30+ dias de atraso	1,31	377

O padrão é claro e consistente: quanto antes a entrega, maior a nota. Mas antes de avançar para o diagnóstico, identifiquei algo que merece atenção: há um volume relevante de pedidos entregues no prazo ou antes com nota 1. Se o atraso fosse o único fator, isso não deveria acontecer nessa proporção. Investigo?

Usuário: Sim.

Agente: Comparação entre pedidos com nota 1 e nota 5, ambos entregues no prazo:

Variável	Mediana nota 1	Mediana nota 5	Diferença
Dias reais de entrega	14,0 dias	7,0 dias	2× mais lento
Valor do frete	R$ 19,20	R$ 14,10	36% mais caro
Valor do pedido	R$ 89,90	R$ 79,80	13% mais caro
Itens no pedido	1	1	igual
Parcelas	1	1	igual

Achado relevante: pedidos com nota 1 entregues no prazo levaram o dobro de dias que os com nota 5 — mesmo ambos dentro do prazo prometido. O prazo estimado pode estar sendo usado como teto operacional, mas o cliente está comparando com uma expectativa própria, não com o prazo declarado.

Camada diagnóstica — por que aconteceu?

Usuário: Quais fatores nos dados podem estar relacionados às notas baixas? Não afirme causalidade — aponte correlações que merecem investigação.

Agente: Três correlações identificadas para investigação:

1. Tempo real de entrega (independente do prazo): correlação negativa com a nota — quanto mais dias, menor a nota, mesmo quando dentro do prazo.
2. Valor do frete: correlação negativa com a nota em pedidos entregues no prazo. Mas atenção: frete alto tende a estar correlacionado com tempo de entrega longo (produto pesado, região distante). Os dois fatores estão correlacionados entre si, não apenas com a nota.
3. Proporção atraso/prazo: pedidos onde o prazo prometido era longo e foi cumprido têm nota menor que pedidos onde o prazo era curto e foi cumprido. Isso sugere que o cliente não avalia apenas o cumprimento do prazo — avalia a duração total da espera.

Usuário: Então posso concluir que frete caro causa nota baixa?

Agente: Não ainda. O frete mais alto e a entrega mais lenta aparecem juntos nos pedidos com nota 1 — mas não é possível separar os dois efeitos com a análise que fizemos até aqui. Um pedido com frete caro tende a ser de produto pesado ou de região distante, o que também explica a entrega mais lenta. Os dois fatores estão correlacionados entre si, não apenas com a nota. Para isolar o efeito do frete seria necessária uma regressão multivariada controlando pelo tempo de entrega. Posso indicar esse próximo passo nos limites honestos. Prefere confirmar a hipótese principal primeiro com evidência mais sólida?

Usuário: Sim. Confirma a hipótese do atraso.

Camada preditiva — o que isso significa daqui pra frente?

Usuário: Se o padrão de atraso se mantiver, qual seria o impacto nas avaliações no próximo trimestre? E qual seria o impacto de uma intervenção que reduzisse o tempo médio de entrega em 3 dias?

Agente: Com base nos padrões identificados:

Cenário sem intervenção: mantendo o mix atual de pedidos no prazo e atrasados, a nota média permanecerá próxima de 4,1. O risco está concentrado nos períodos de alta demanda — Black Friday e Natal — onde historicamente o volume de atrasos aumenta, o que pode derrubar a nota média para próximo de 3,6 temporariamente.

Cenário com intervenção (-3 dias no tempo médio): baseado na tabela de nota por faixa de tempo, deslocar pedidos da faixa “0–7 dias antes” para “7–14 dias antes” representa uma melhora de ~0,23 pontos na nota média. O impacto maior seria em reputação acumulada ao longo de 6+ meses.

Risco que merece atenção: a categoria de pedidos no prazo com nota baixa (dias de entrega longos mas dentro do SLA) não melhora com redução de atrasos — exige revisão do prazo prometido, não da operação logística.

Etapa 8 — O operador questiona

Usuário: A conclusão de que atraso causa nota baixa — quais dados específicos a sustentam?

Agente: Os dados que sustentam a afirmação de correlação: pedidos atrasados têm mediana de nota 1 (n=5.891); pedidos no prazo têm mediana de nota 5 (n=82.847). A diferença foi verificada com Mann-Whitney U — teste adequado para dados ordinais, que não assume distribuição normal. O p-valor é menor que 0,001 e o tamanho de efeito (r=0,41) indica efeito moderado-alto, não apenas significância estatística por volume amostral.

O que os dados não sustentam: que atraso causa nota baixa no sentido causal estrito. Correlação forte com tamanho de efeito relevante — sim. Causalidade — não, porque o dataset não tem design experimental. Um cliente que recebe tarde pode avaliar mal por outros motivos que coincidiram com o atraso.

Usuário: Argumento do advogado do diabo: qual o argumento mais forte contra essa conclusão?

Agente: O argumento mais forte: os dados cobrem 2016-2018, período de expansão acelerada do e-commerce no Brasil. Pedidos com atraso podem estar concentrados em regiões com infraestrutura logística precária — onde o cliente já tem expectativa calibrada para prazos longos. Se for esse o caso, o atraso per se não é o fator — é a diferença entre expectativa e realidade, que pode ser zero mesmo com 30 dias de entrega. Os dados não têm variável de expectativa declarada pelo cliente, então esse efeito não pode ser testado com o dataset atual.

Fase 3 na prática — Síntese

Etapa 9 — Narrativa de Decisão

Usuário: Me ajude a construir a Narrativa de Decisão. Uma frase para cada item.

Agente:

O que aprendi: Atraso na entrega é o fator com maior correlação com nota baixa, mas pedidos entregues no prazo com tempo real longo também acumulam avaliações ruins — o cliente avalia a duração da espera, não apenas o cumprimento do SLA.

O que isso muda: Reduzir atrasos é necessário mas insuficiente — o prazo prometido precisa ser revisto para se aproximar da expectativa real do cliente, não apenas do teto operacional.

Próximo passo: Mapear as categorias de produto com maior proporção de pedidos “no prazo, nota baixa” e avaliar se o prazo prometido está sistematicamente acima do tempo que o cliente tolera.

Etapa 10 — Limites honestos

Agente:

O que os dados suportam com solidez: a correlação entre tempo de entrega e nota, com tamanho de efeito verificado.

O que é hipótese não confirmada: que reduzir o prazo prometido vai melhorar as notas — isso depende de como a plataforma comunica o prazo e de como o cliente forma sua expectativa.

O que está fora do alcance desta análise: o efeito isolado do frete (exige regressão multivariada), o impacto por categoria de produto, e qualquer efeito de sazonalidade (exige controle por período).

---

Um Skill para utilizar no Claude e facilitar sua vida

Agora que você já entendeu como funciona a metodologia e como criar uma narrativa de decisão, vou disponibilizar um skill para você usar no Claude e facilitar sua vida.

O que ele lhe oferece é um conhecimento amplo e bem organizado da aplicação da estatística, matemática e programação para análise de dados, com foco em análise descritiva, diagnóstica, preditiva e prescritiva, além de ferramentas para análise exploratória de dados. Isso vai agilizar muito seu andamento, dado que você não terá que se preocupar em como fazer as coisas, e sim em obter os resultados que deseja.

O skill para Claude nada mais é que um bloco de instruções que calibra o comportamento do agente para seguir a metodologia, fazer as perguntas certas, recusar conclusões sem evidência e estruturar a síntese em Narrativa de Decisão.

Para obter o skill: acesse berlotto.me/especiais/vibe_analysis_skill e faça o download do arquivo.

Para instalar no Claude:

1. Abra o Claude.ai
2. No menu lateral - vá em Personalizar
3. Depois em Habilidades (Skills)
4. no lado do texto de Habilidades, clique em “Criar Habilidades”->“Fazer upload de uma habilidade”
5. Selecione o arquivo zip que você baixou da pagina expecial aqui.

Agora, para utilizar o skill em um novo chat, basta você chamá-lo pelo comando / (barra) no inicio da sua frase. Exemplo /vibe-analysis [sua pergunta inicial].

Um bom formato para trazer os dados: CSV, Excel ou texto colado diretamente no chat. Para datasets muito grandes, faça uma amostra representativa antes. Para dados sensíveis, anonimize antes — substitua IDs reais por hashes, remova CPFs e e-mails.

A orientação mais importante: comece sempre com uma pergunta de negócio, não com uma instrução técnica. “Quero entender por que meu churn aumentou em março” é um ponto de partida melhor do que “calcule a correlação entre uso de feature e churn”. A segunda já pressupõe o método — e pode estar pressupondo o errado.

OpenAI GPTs

Para usar o Vibe Analysis no ChatGPT, também foi criada uma ferramenta que se chama “GTP”, entitulada “Vibe Analysis”. Com ela você terá as mesmas funcionalidades da versão para Claude.

O link para acessar diretamente é este: https://chatgpt.com/g/g-69c534f65f748191b039577c908db75e-vibe-analysis ou procurando diretamente nos GPT da OpenAi por “Vibe Analysis”.

Os 5 anti-padrões que comprometem a sessão

Todo operador comete pelo menos um desses erros nas primeiras sessões:

Anti-padrão 1 — O passeio sem destino: “Vou explorar os dados e ver o que aparece.” Sem uma pergunta real, a análise não tem critério de relevância. Tudo parece interessante. Nada ilumina nenhuma ação. Correção: volte à Etapa 1 e formule uma pergunta genuína antes de abrir qualquer dado.

Anti-padrão 2 — O oráculo obediente: “A IA disse que o problema é X, então o problema é X.” O operador aceita conclusões sem questionamento. A IA vira autoridade em vez de ferramenta. Correção: aplique sempre os prompts da Etapa 8. Toda conclusão relevante precisa passar pelo filtro de contexto do operador.

Anti-padrão 3 — A conclusão que veio antes: “Já sei o que os dados vão mostrar — só preciso confirmar.” O briefing já carrega a conclusão embutida. A IA entrega a confirmação solicitada. Correção: use o prompt do advogado do diabo sempre que a análise estiver confirmando demais o que você já acreditava.

Anti-padrão 4 — A parada no primeiro andar: “Vendi 20% a menos em março. Análise concluída.” O operador percorre só a camada descritiva. Sabe o que aconteceu, mas não sabe por que — e a decisão é tomada no mesmo achismo de antes. Correção: não encerre uma sessão sem percorrer as três camadas.

Anti-padrão 5 — A análise sem síntese: “Tenho 40 minutos de conversa com a IA e muita coisa interessante.” A sessão gerou material, mas não gerou decisão. Correção: antes de encerrar, construa a Narrativa de Decisão. Se não consegue preencher as três frases de memória, a sessão ainda não acabou.

Limitações honestas

Metodologia sem lista de limitações é marketing, não técnica. Estas são as fronteiras reais do Vibe Analysis:

Tamanho de dataset. O contexto do Claude comporta arquivos de até alguns megabytes com conforto. Datasets acima de 50MB precisam de amostragem ou pré-processamento local antes de entrar no chat. Para análises de dezenas de milhões de linhas, o caminho certo é Python/R local com o Vibe Analysis guiando a estratégia — não executando.

Reprodutibilidade. Uma análise conduzida em conversa não é automaticamente reproduzível. Se o resultado precisa ser auditável — pesquisa científica, decisão regulatória, laudo técnico — o código gerado pelo agente deve ser extraído, versionado e executado em ambiente controlado. A conversa não substitui o pipeline.

Decisões de alto risco. Vibe Analysis é adequado para análise exploratória, geração de hipóteses e suporte a decisões de produto e operação. Não é adequado como única fonte de evidência para decisões clínicas, financeiras de grande porte ou com implicações legais. Nesses contextos, a análise do agente deve ser validada por um especialista humano com responsabilidade sobre o resultado.

Viés de confirmação assistido. Este é o risco mais sutil — e o mais importante de nomear. Se o usuário chega com uma conclusão já formada e conduz a conversa para confirmá-la, o agente pode ser levado nessa direção mesmo com o skill ativo. A metodologia tem mecanismos para resistir a isso — questionar premissas, recusar causalidade sem evidência — mas não é imune. A qualidade da análise depende também da qualidade das perguntas de quem analisa.

O skill não substitui conhecimento de domínio. O agente seleciona o método estatístico adequado ao tipo de dado e à pergunta. Mas interpretar se o resultado faz sentido no contexto do negócio, da ciência ou da operação é responsabilidade de quem tem o conhecimento de domínio. “Estatisticamente significativo” e “relevante para a decisão” são coisas diferentes — e só quem conhece o contexto consegue separar as duas.

Manual da metodologia

E, por fim, você poderá encontrar o manual completo da metodologia neste repositório git.

https://github.com/berlotto/vibe-analysis-tools-and-methodology

E claro, a metodologia deve ser viva e em constante manutenção, então sinta-se a vontade em contribuir também ! Comente aqui ou interaja no repositório.

Conclusão

O problema que o Vibe Analysis resolve não é técnico. É epistêmico.

Dados sem análise são custo. Dados analisados sem método são análises que parecem sólidas porque os números estão lá, calculados, visíveis. O erro não está no cálculo — está na sequência: pular o diagnóstico, parar na camada descritiva, afirmar causalidade onde existe correlação, não declarar o que ainda não se sabe.

O VA não resolve isso com mais tecnologia. Resolve com estrutura: dez etapas com critério de saída em cada uma, cinco pontos de retorno quando algo sai do trilho, e um produto final que não é um gráfico — é uma decisão que você consegue defender numa reunião, comunicar para o seu time e agir em cima ainda hoje.

O skill é o veículo. A curiosidade é o combustível. O método é o que transforma a conversa em conhecimento confiável — e garante que você sabe exatamente até onde confiar nele.