Quando o comprador roda o eval, o teatro da demo acaba

A demo de software é uma performance, e todo mundo na sala sabe disso. O vendedor dirige. Os dados estão limpos porque alguém os limpou ontem à noite. O caminho pelo produto é o único caminho que funciona, percorrido cem vezes antes de você ver. A pergunta difícil que você de fato tem, isso vai sobreviver aos meus dados bagunçados, ao meu edge case esquisito, à minha terça-feira, é a única pergunta que a demo é estruturada para nunca alcançar.

Todos concordamos em fingir o contrário. Sentamos na sala de reunião, assistimos o caminho curado acender verde, e chamamos de evidência.

Nunca foi evidência. Uma demo prova um happy path curado nos dados do fornecedor, no horário do fornecedor. Um eval prova o real, nos seus dados, com seus edge cases, na sua frente. Quando o comprador consegue rodar o eval, o teatro acaba.

Essa frase é o post inteiro. O resto é por que a demo sempre foi teatro, o que a substitui, e por que isso importa mais para software de IA do que jamais importou para o tipo antigo.

Por que a demo sempre foi um truque de mágica

Comece com o que uma demo de fato é, mecanicamente. É uma sequência de inputs que o fornecedor escolheu, rodada contra dados que o fornecedor controla, narrada pela pessoa cujo emprego depende de você dizer sim. Cada grau de liberdade nessa frase pertence ao vendedor.

A leitura ingênua é que uma demo te mostra o produto. Não mostra. Ela te mostra o melhor run possível do produto, o que o fornecedor ensaiou, nos inputs que o fornecedor sabe que ele lida, pulando os inputs que ele não lida. Uma demo é o reel de melhores momentos do produto narrado como se fosse o jogo.

E nós sabíamos. O comprador honesto sempre carregou um desconto silencioso: subtraia trinta por cento pelo brilho da demo, assuma que a coisa real é mais áspera. Mas esse desconto é um chute. Você não sabe se é trinta por cento ou noventa. Você não sabe qual trinta por cento, a parte áspera é a coisa que você vai usar diariamente ou a que você vai tocar duas vezes por ano? A demo te dá um número que você não consegue calibrar e uma confiança que você não conquistou.

Para software comum, você conseguia sobreviver a isso. Um CRM ou tem um campo ou não tem; você conseguia clicar num trial e descobrir. A demo era um auxílio de vendas, o trial era o teste real, e o gap entre eles era irritante mas limitado.

Aí o software parou de ser determinístico. E o gap parou de ser limitado.

A IA quebrou a demo, porque a IA não se comporta igual duas vezes

Aqui está a coisa que muda tudo, e vale enunciar claramente. Software antigo fazia a mesma coisa toda vez. Você clicava no botão, o formulário salvava. A demo e a sua terça rodavam o mesmo código sobre a mesma lógica; só os dados diferiam. Se salvou na demo, salvou para você.

Uma feature de IA não funciona assim. Peça a um agent para triar uma caixa de entrada, rascunhar uma resposta, reconciliar dois registros, decidir se um reembolso é justificado, e a resposta depende do fraseado, do contexto, das dez coisas ao redor da uma coisa, e de um modelo que tem permissão para ser um pouco diferente a cada vez. A demo te mostrou um run. Sua terça é um run diferente. O fato de o run da demo ter sido bom te diz quase nada sobre a distribuição de runs que você de fato vai receber.

Essa é a armadilha que mata pilots de IA. A demo deslumbra. O comprador assina. Aí a coisa encontra inputs reais, o email escrito em três línguas, o cliente que se contradiz, o registro com um erro de digitação no campo de que tudo depende, e o comportamento que a demo nunca mostrou é exatamente o comportamento de que a produção é feita. O fornecedor mostrou o único run. Você comprou a distribuição.

Uma demo te mostra um run. Você está comprando a distribuição.

Então a defesa ingênua, “deixa eu tentar eu mesmo num trial”, ajuda, mas só um pouco, e só se você por acaso tentar os inputs que o quebram. Você não vai, porque não sabe quais são. Você é um comprador cutucando um produto por uma tarde. O fornecedor passou meses aprendendo onde ele é fino e tem todo incentivo para não te apontar para lá.

O que você precisa não é uma demo mais longa ou um trial hands-on. Você precisa de um jeito de fazer ao produto a mesma pergunta difícil, do mesmo jeito, toda vez, e de fazê-la nos seus inputs, não nos dele. Você precisa da coisa que os engenheiros construindo esses sistemas já usam para mantê-los honestos. Você precisa de um eval.

O que um eval é, e por que ele acaba com o teatro

Um eval é o núcleo nada glamoroso de como qualquer um constrói IA a sério. Tire o jargão e são três coisas: um conjunto de casos reais, um jeito de rodar o produto contra todos eles, e uma regra fixa para pontuar cada resultado do mesmo jeito toda vez. É isso. Casos, runs, um scorer.

A versão ingênua de “testar IA” é conversar com ela e formar uma impressão. Você tenta algumas coisas, ela parece esperta, você concorda com a cabeça. Essa impressão é uma demo que você deu a si mesmo, mesma falha, menos ensaios. Um punhado de prompts casuais não consegue te dizer uma taxa de acerto, não consegue te dizer quais casos falham, e não consegue ser re-rodado identicamente semana que vem para ver se uma nova versão ficou melhor ou silenciosamente pior.

A versão de eval é o oposto de uma impressão. Suponha que você seja um escritório de contabilidade avaliando se um agent consegue reconciliar seu fechamento de mês. O eval não é “assista ele reconciliar um razão limpo.” É: pegue cinquenta das suas reconciliações reais, as cabeludas, as com a entrada duplicada e o pagamento com data errada e o item de linha que ninguém consegue explicar, rode o agent contra todas as cinquenta, e pontue cada uma contra a resposta que você já sabe que é certa. Sai um número. Quarenta e uma de cinquenta corretas, e aqui estão as nove que ele errou, e aqui está exatamente por que cada uma errou.

Agora compare o que você está segurando. A demo te entregou uma sensação e um desconto-chute. O eval te entregou uma taxa de acerto nos casos com que você se importa e uma lista nomeada de cada falha. Uma é teatro. A outra é uma medição.

E a assimetria se inverte. Numa demo, o fornecedor controla cada input e você controla nada. Num eval você controla os inputs, eles são seus casos, seus edge cases, sua terça, e o fornecedor controla nada exceto se o produto dele sobrevive a eles. O vendedor não pode dirigir. Os dados não podem ser limpos na noite anterior, porque são os seus dados. O único caminho que funciona não pode ser o único caminho tentado, porque você traz os caminhos.

O fornecedor pode ensaiar uma demo. O fornecedor não pode ensaiar os seus dados.

Essa única mudança, quem escolhe os inputs, é a diferença inteira entre uma performance e uma prova.

O comprador se torna quem escreve o teste

Aqui está a parte que soa como se devesse ser difícil e acaba sendo o ponto.

Por décadas, o teste que importava, o que decidia se o software de fato fazia o trabalho, vivia dentro do fornecedor. O QA deles, o staging deles, os benchmarks internos deles. Você, o comprador, recebia uma demo e um trial e um contrato, e levava o resto na fé. A prova estava do lado do vendedor da mesa, e você era pedido para confiar no relato dela.

O futuro ingênuo só move a demo para online: um sandbox mais chique, um tour self-serve, um chatbot que demonstra a si mesmo. Mesmo teatro, novo palco. O fornecedor ainda escolhe o caminho; você ainda assiste.

A mudança real é que o teste se move para o seu lado da mesa. Você chega à avaliação não com uma wish list de features mas com uma pasta de casos, as situações reais em que seu negócio roda, com as respostas que você já conhece. O trabalho do produto não é mais parecer bom por quarenta minutos. O trabalho dele é sobreviver à sua pasta. Taxa de acerto, por caso, re-rodável no próximo trimestre para provar que não regrediu. O comprador para de ser plateia e se torna o autor do teste.

Essa é a razão de comprar IA não vai parecer comprar software. A coisa que tornava a demo necessária, que você não conseguia ver como ela se comportaria na sua realidade até já ter pagado, é exatamente a coisa que um eval remove. Você vê o comportamento na sua realidade primeiro. A assinatura vem depois do número, não antes dele.

O fornecedor que teme isso está te dizendo algo

Há um sinal que vale nomear, porque é o sinal mais útil que um comprador vai receber nesta década.

Peça a um fornecedor para rodar o produto dele contra os seus casos, pontuado do seu jeito, na sua frente, e observe o que acontece. O fornecedor que construiu algo real diz sim, mande os casos. Eles já rodaram mil evals mais difíceis que o seu; mais um é uma terça-feira. O fornecedor que esteve vivendo do brilho da demo se encolhe. De repente há razões de que tem que ser o ambiente deles, os dados de amostra deles, uma prova de conceito sob medida que vamos escopar ao longo de seis semanas. O encolher é a resposta. Um produto confiante na própria distribuição não precisa controlar os inputs.

Isso não é hostilidade. É a mesma lógica que faz um bom time de engenharia confiar mais numa review do que numa reputação: a prova deveria viver no teste, não na alegação. Um fornecedor se oferecendo para ser avaliado nos seus termos está te oferecendo a coisa que a demo nunca pôde dar, um número que você não teve que descontar.

Os que construíram sobre teatro vão resistir mais, e vão resistir com processo: mais reuniões, mais ambientes curados, mais razões de que o teste honesto é “prematuro.” Os que construíram sobre algo real vão te entregar as chaves, porque o eval é onde eles vencem.

A virada: pare de ser a plateia

Aqui está a parte que não é sobre software de jeito nenhum.

Pela sua carreira inteira, comprar ferramentas te escalou como plateia. Você sentou na sala e assistiu o run ensaiado de outra pessoa e foi pedido para se sentir convencido. A decisão mais importante, isso vai de fato funcionar para nós, foi feita sobre uma sensação fabricada pela pessoa vendendo. Você era um espectador na sua própria compra, e o desconto que você carregava na cabeça era o único poder que você tinha, e era um chute.

Esse papel nunca foi um bom encaixe para você. Você é quem sabe onde seu negócio é bagunçado. Você conhece o cliente que se contradiz, a linha do razão que ninguém consegue explicar, o edge case que aparece todo trimestre e quebra tudo. Esse conhecimento é a coisa mais valiosa em qualquer avaliação, e a demo foi construída para mantê-lo fora da sala, porque no momento em que seus casos difíceis entram, o reel de melhores momentos acaba.

O eval os convida para dentro. Ele pega a única coisa que você tem que o fornecedor não tem, a verdade da sua própria realidade, e a torna o teste. Você para de aplaudir o run que outra pessoa escolheu e começa a avaliar os runs que você escolheu. A decisão se move de uma sensação que você recebeu para um número que você produziu. Isso não é um trabalho menor. É finalmente o trabalho certo.

---

Isso é parte do que estamos construindo na Apollo, software que você não tem que levar na fé, que prova a si mesmo contra a sua realidade antes de você se comprometer com ele, porque uma empresa AI-native roda em evidência, não no brilho de uma boa demo. Se você já assinou na força de uma demo linda e assistiu a coisa real chegar mais áspera, você já sabe por que a próxima era de compra pertence à pessoa que escreve o teste.