A diferença entre uma demo de IA e um produto de IA

Uma demo prova que algo é possível. Um produto precisa provar que é possível continuar fazendo aquilo amanhã.

Salve, galera!

Nos últimos tempos, tive a oportunidade de fazer algumas palestras sobre inteligência artificial e várias outras sobre temas diferentes que incluíam IA em alguma parte. Em todas elas acontece uma coisa parecida: a aplicação sobe, alguém faz uma pergunta, o modelo responde e, por alguns segundos, parece que ficou tudo fácil.

Esse é o momento em que a IA parece mágica. O pessoal assistindo começa a imaginar que o departamento acaba de ser aposentado. Com direito a festa de despedida e tudo.

O problema é que uma palestra precisa mostrar o caminho feliz. E o caminho feliz é ótimo. Pena que o mundo real seja feito de perguntas mal formuladas, documentos desatualizados, serviço fora do ar, limite de uso, dado sensível, usuário impaciente e que muitas vezes já está na versão 40 dos requisitos de uma solicitação, e uma conta que precisa fechar no fim do mês.

Nada disso invalida as demos. Elas são úteis. Tornam uma ideia visível e ajudam a explicar uma tecnologia nova. Mas existe uma distância enorme entre mostrar que algo é possível e operar aquilo com responsabilidade. Uma distância que costuma desaparecer convenientemente no slide seguinte, justamente quando aparece a previsão de reduzir 80% do custo do time.

É sobre essa distância que quero falar.

A promessa não é a demonstração

Só que existe uma segunda distância: a diferença entre o que a tecnologia faz e o que as empresas prometem que ela fará. E, nesse mercado, a imaginação do marketing parece ter recebido mais orçamento que a engenharia.

Nos últimos anos, saímos de “a IA pode ajudar a escrever código” para promessas bem mais ambiciosas: times inteiros substituídos por agentes, desenvolvimento sem programadores e software produzido sem ninguém precisar escrever ou revisar código. Na keynote de abertura do Rails World 2026, DHH apresenta uma visão especialmente provocadora dessa tendência: a de que o desenvolvimento pode se afastar cada vez mais da escrita manual e da revisão tradicional de código.

Discordar da opinião não é o problema. O problema é perceber o salto lógico. E notar que ele quase sempre termina em um slide com uma seta apontando para cima.

Uma ferramenta gerar código não significa que escrever código deixou de ser importante. Um agente abrir um pull request não significa que revisão virou perda de tempo. E uma empresa anunciar que automatizou uma tarefa não faz a responsabilidade evaporar. Seria conveniente, mas ainda não chegamos nesse nível de ficção científica.

Às vezes, a promessa é apresentada como inovação, mas funciona também como estratégia de marketing. Quanto mais radical a previsão, como “ninguém mais fará isso”, “o desenvolvedor será substituído” ou “o time inteiro será automatizado”, maior a atenção gerada. É uma ótima forma de vender o futuro, principalmente quando ninguém ainda pediu para demonstrar a manutenção desse futuro numa terça-feira chuvosa. Só que sistemas reais não são avaliados pela força da frase de lançamento. Eles são avaliados pelas consequências das decisões que tomam.

Automatizar a produção não elimina a necessidade de julgamento. Apenas muda o lugar onde ele é necessário.

O código pode ser escrito por uma pessoa, sugerido por um modelo ou produzido por um agente. Ainda precisamos decidir se ele expressa a regra certa, se é seguro, se dá para manter e se deveria entrar no sistema. Essa parte não é burocracia que a IA veio remover. É o trabalho, a parte menos cinematográfica e mais parecida com produção.

A demo é uma promessa

Uma demo de IA normalmente tem algumas características:

• usa um conjunto pequeno e conhecido de dados;
• tem um fluxo cuidadosamente preparado;
• apresenta uma ou duas perguntas que sabemos que funcionarão;
• esconde detalhes de infraestrutura;
• não precisa explicar o que acontece quando algo falha;
• não tem um usuário real esperando uma resposta em três segundos.

Isso não é uma crítica. É o formato da demonstração. Ninguém quer assistir a uma palestra de 45 minutos sobre uma variável de ambiente escrita errada. Bom, quase ninguém.

Em uma palestra, eu quero que meu público entenda a ideia principal. Se estou mostrando RAG, quero que fique claro que o modelo consegue responder usando uma base de conhecimento própria. Se estou mostrando um agente, quero mostrar que ele consegue chamar uma ferramenta. Se estou mostrando geração de código, quero destacar como a interação muda. Não quero gastar metade do tempo explicando por que o container não subiu ou por que a chave da API expirou no intervalo, embora isso seja uma representação bem mais honesta de uma manhã comum.

Uma demo reduz o ruído para revelar a possibilidade.

O problema aparece quando confundimos essa possibilidade com uma solução pronta. O modelo respondeu uma pergunta corretamente? Ótimo. Isso não significa que vai responder as próximas mil corretamente. O agente chamou uma ferramenta? Legal. Isso não significa que ele deveria poder executar qualquer operação. A aplicação funcionou no meu computador? Parabéns para o meu computador. Ainda não significa que está pronta para usuários reais.

A demo controla as condições. O produto precisa sobreviver a elas.

O primeiro teste é fácil. O centésimo é o produto

Vamos imaginar uma aplicação simples em .NET que recebe uma pergunta e pede para o modelo classificá-la:

var response = await chatClient.GetResponseAsync(
    $"Classifique esta solicitação como urgente, normal ou baixa: {request.Text}");

return Results.Ok(new { classification = response.Text });

Em uma demo, isso pode ser suficiente. A resposta aparece na tela, a ideia fica clara e ninguém pergunta quem vai pagar essa conta quando a aplicação estiver rodando alguns milhões de vezes.

Em um produto, surgem perguntas imediatamente:

• O que acontece se request.Text estiver vazio?
• E se o modelo responder algo diferente de urgente, normal ou baixa?
• O que acontece quando o provedor estiver indisponível?
• Quanto custa cada classificação?
• O texto enviado contém dados pessoais?
• Podemos registrar o prompt e a resposta nos logs?
• O que impede um usuário de enviar um texto gigantesco?
• A operação pode ser repetida sem gerar efeitos duplicados?
• Quem revisa uma classificação errada?

O código não ficou necessariamente mais sofisticado porque adicionamos IA. Ele ficou mais imprevisível. E imprevisibilidade exige que o sistema ao redor seja mais explícito. É exatamente o oposto da promessa de que bastaria adicionar um prompt e remover algumas pessoas do fluxograma.

Uma versão mais próxima de um produto teria um contrato fechado, validação e um tratamento claro para respostas inesperadas:

public sealed record ClassificationResult(
    string Category,
    double Confidence);

var result = await classifier.ClassifyAsync(request.Text, cancellationToken);

if (!AllowedCategories.Contains(result.Category))
{
    return Results.Problem(
        title: "Não foi possível classificar a solicitação",
        statusCode: StatusCodes.Status503ServiceUnavailable);
}

return Results.Ok(result);

Ainda não temos um produto completo. Mas já começamos a transformar uma resposta probabilística em um comportamento que o restante do sistema consegue entender.

O produto precisa de limites

Em uma demo, o modelo recebe acesso direto a uma ferramenta porque sabemos exatamente o que será perguntado. Em produção, isso é perigoso. Funciona até o primeiro usuário descobrir que “cancelar pedido” também está disponível para o modelo.

Um agente pode consultar pedidos, criar tickets ou sugerir alterações. Essas ações não têm o mesmo nível de permissão. Consultar um pedido é uma coisa. Cancelar é outra. Sugerir uma alteração é diferente de publicá-la. Parece óbvio — até alguém esconder tudo atrás de uma função chamada executeTool.

Uma aplicação real precisa definir:

• quais ferramentas o agente pode chamar;
• quais parâmetros são válidos;
• quais ações exigem aprovação humana;
• quais operações são somente leitura;
• quanto tempo uma execução pode durar;
• quantas chamadas podem ser feitas;
• o que acontece quando o agente entra em um loop.

Autonomia não é um botão de ligar e desligar. Não precisamos escolher entre “chatbot que não faz nada” e “agente com acesso irrestrito”. Dá para construir graus de autonomia e aumentá-los conforme reunimos evidências de que o comportamento é seguro.

Esse é um ponto que costuma sumir na palestra: a parte divertida é fazer o agente agir. A parte difícil é decidir onde ele não pode agir. A primeira rende aplausos. A segunda rende reunião com segurança, jurídico e operações — ou deveria render.

O produto precisa ser observado

Quando uma demo falha, normalmente reiniciamos a aplicação e tentamos de novo. Quando um produto falha, precisamos descobrir o que aconteceu, sem pedir para a plateia fingir que não viu.

Uma resposta lenta pode ter sido culpa do nosso código, do banco, do serviço de embeddings, do provedor do modelo ou de uma sequência de retries. Sem telemetria, tudo vira suspeita e opinião. Normalmente com alguém dizendo “aqui está rápido”.

Para uma funcionalidade com IA, observar apenas o status 200 OK não é suficiente. Precisamos saber, pelo menos:

• duração total da operação;
• duração de cada chamada externa;
• modelo utilizado;
• quantidade de tokens de entrada e saída;
• número de retries;
• taxa de respostas inválidas;
• custo estimado;
• versão do prompt;
• identificador da execução.

Aqui o .NET Aspire pode ajudar durante o desenvolvimento, especialmente ao reunir serviços, dependências e telemetria no mesmo ambiente. Mas ele não elimina a responsabilidade de decidir o que medir. Um dashboard bonito não responde se a funcionalidade entrega valor, embora fique ótimo na captura de tela do anúncio.

Observabilidade não é decorar a aplicação com métricas. É conseguir responder perguntas difíceis quando o comportamento sair do caminho feliz.

O produto precisa ser avaliado

Uma diferença enorme entre demo e produto é que a demo costuma ser avaliada por uma pergunta:

“Funcionou?”

Para um produto de IA, essa pergunta é pequena demais. Até aplicação quebrada consegue responder “funcionou” uma vez.

Precisamos perguntar:

• Funcionou com que frequência?
• Funcionou para quais tipos de entrada?
• Qual foi a taxa de alucinação?
• As respostas foram fundamentadas nos dados corretos?
• O usuário conseguiu perceber quando a resposta era incerta?
• Quanto custou gerar esse resultado?
• O comportamento piorou depois de uma mudança no prompt?

Isso nos leva a uma prática que ainda está amadurecendo: criar um conjunto de casos representativos e rodar esse conjunto sempre que mudamos o prompt, o modelo ou a estratégia de recuperação.

Não precisa começar com uma plataforma complexa. Uma coleção versionada de entradas e resultados esperados já pode revelar regressões que passariam batidas em testes manuais.

O importante é parar de tratar qualidade como uma impressão subjetiva produzida por duas perguntas bem escolhidas. Se o benchmark tem apenas os exemplos escolhidos para a palestra, ele não é benchmark. É fã-clube.

O fator humano não é o gargalo a ser eliminado

É tentador tratar a participação humana como o obstáculo entre a IA e a velocidade máxima. Se o modelo gera o código, por que alguém deveria escrevê-lo? Se o agente abriu o pull request, por que alguém deveria revisá-lo? Se uma ferramenta consegue executar o fluxo inteiro, por que manter um desenvolvedor no processo? Afinal, nada representa mais eficiência do que remover justamente a pessoa que será chamada quando tudo der errado.

Porque software não é apenas texto para produzir. Software é comportamento que será confiado a alguém. E esse alguém provavelmente não é o agente que escreveu o código.

O fator humano continua necessário para:

• entender o problema que o código deveria resolver;
• reconhecer requisitos que não foram escritos no prompt;
• perceber quando uma solução tecnicamente elegante viola uma regra do negócio;
• avaliar riscos que não aparecem no caminho feliz;
• decidir qual complexidade é aceitável;
• assumir responsabilidade quando o sistema causa um efeito inesperado.

Revisar não é só procurar erro de sintaxe ou conferir se os testes passaram. Revisar é comparar a implementação com a intenção. E a intenção quase nunca está inteira no código, no ticket ou no prompt, por mais que o ticket tenha sido escrito com a confiança de quem acredita que “implementar fluxo X” é uma especificação.

Isso não significa defender que alguém precise digitar cada linha para provar que participou. Existe muito trabalho mecânico que pode e deve ser automatizado. Também não significa transformar revisão em um ritual lento, em que alguém lê cada linha sem contexto. A questão é outra: a velocidade da geração não pode ser usada como desculpa para remover o julgamento de quem conhece o problema e vai responder por ele.

Uma revisão pode mudar de formato. Pode ter ajuda de IA, começar antes do pull request, usar testes gerados, verificar invariantes ou comparar decisões arquiteturais. Mas não deixa de existir só porque a máquina produziu o primeiro rascunho.

O humano não precisa ser o digitador de tudo. Precisa continuar sendo o responsável por decidir o que merece existir.

A palestra não está errada. Ela está incompleta.

Depois das palestras, ouço bastante um feedback: “Legal a demo, mas eu queria ver mais detalhes. E os cenários do mundo real?” É uma cobrança justa. Eu também gostaria de mostrar o que acontece quando o provedor cai, o dado está errado ou o agente resolve ser criativo demais. Só que a palestra tem tempo limitado. Se eu tentar cobrir cada falha, permissão e custo, a demo vira um incidente de produção de duas horas, com direito a post-mortem e plano de ação.

Por isso escolho um caminho feliz para apresentar a ideia e deixo claro onde ele termina. O problema não é simplificar a demonstração. É vender essa simplificação como se fosse o produto inteiro. Quem pede mais detalhes está fazendo a pergunta certa, e é justamente essa conversa que deveria continuar depois que a aplicação responde no palco.

Talvez a responsabilidade esteja em fazer uma segunda pergunta depois da demonstração:

O que precisaria ser verdade para essa ideia funcionar em produção?

Essa pergunta muda a conversa. Ela nos força a sair da mágica e entrar na engenharia:

• quais são os limites?
• quais são os contratos?
• como medimos qualidade?
• como lidamos com falhas?
• quem pode autorizar uma ação?
• quanto custa operar?
• como explicamos uma decisão?

Essas perguntas não tornam a IA menos interessante. Elas tornam a solução mais honesta.

A distância é o trabalho

Em uma palestra, o momento mágico acontece quando o modelo responde corretamente.

Em um produto, o valor está no que acontece depois: quando o usuário faz uma pergunta diferente, quando o serviço cai, quando o documento está desatualizado, quando a resposta custa dez vezes mais que o esperado ou quando alguém precisa entender por que uma decisão foi tomada.

A demo mostra o potencial da tecnologia.

O produto é o conjunto de decisões que permite usar esse potencial sem depender da sorte. E essas decisões continuam precisando de pessoas para formular o problema, questionar a resposta, revisar o resultado e assumir as consequências. A IA pode até ficar com o teclado. A culpa, por enquanto, continua sendo nossa.

E talvez essa seja a parte mais importante para quem trabalha com IA hoje: não basta aprender a chamar modelos. Precisamos aprender a construir sistemas que saibam conviver com respostas probabilísticas sem fingir que elas são determinísticas.

Fazer a IA funcionar uma vez é uma demonstração.

Fazer com que ela continue funcionando, dentro de limites conhecidos, com custo controlado e consequências compreensíveis, é engenharia de software. A parte que não cabe no slide de “antes e depois”.

Bônus: como assistir à próxima palestra técnica

Na maioria das palestras, a plateia assiste à demo; ninguém entrega o teclado para a primeira pessoa da fila e pede para ela tentar quebrar a aplicação. Ainda bem, porque eu também gosto de terminar minha apresentação no horário.

Isso não impede ninguém de sair com um olhar mais crítico. A ideia é aproveitar o que foi mostrado sem esperar que 40 minutos de palco cubram seis meses de engenharia. A demo mostra uma possibilidade sob certas condições. Vale prestar atenção nessas condições antes de transformar o slide em item de backlog.

Ajuste a expectativa antes de avaliar

Tente identificar qual pergunta a palestra se propôs a responder. “Um agente consegue consultar uma API interna?” é bem diferente de “esse agente pode operar com segurança a API da minha empresa?”. Se a apresentação prometeu a primeira coisa, cobre clareza na demonstração. Se prometeu a segunda, aí faz sentido perguntar sobre permissões, auditoria e falhas.

Também vale separar o que você viu do que inferiu. O modelo respondeu usando três documentos escolhidos pelo palestrante? Isso demonstra o fluxo de recuperação e resposta. Ainda não diz como ele se sai com dez mil documentos, versões conflitantes e aquele PDF escaneado que alguém insiste em chamar de base de conhecimento.

Faça perguntas que revelem as escolhas

Quando abrir espaço para perguntas, uma questão específica costuma render mais do que “mas e em produção?”. Algumas que eu gostaria de ouvir:

• Sobre dados: “Esses documentos foram selecionados para a demo? Como vocês lidariam com conteúdo desatualizado ou contraditório?”
• Sobre qualidade: “Que casos vocês testaram além dos exemplos apresentados? Como perceberiam uma regressão depois de trocar o modelo?”
• Sobre agentes: “Quais ferramentas ele pode usar sozinho? Em que ponto uma pessoa precisa aprovar a ação?”
• Sobre operação: “O que acontece quando o provedor demora ou fica indisponível? O usuário recebe erro, espera ou recebe uma alternativa?”
• Sobre custo: “Vocês mediram custo e latência por solicitação? Qual volume de uso mudaria a escolha dessa arquitetura?”

Não precisa disparar o questionário inteiro nos últimos cinco minutos. Escolha o ponto que mais afeta o seu contexto. Uma pergunta boa ajuda o palestrante a explicar um limite ou uma decisão; pedir um plano completo de produção ali, entre o coffee break e a próxima palestra, ajuda menos.

Se houver interatividade, aproveite com propósito

Algumas apresentações abrem espaço para a plateia sugerir uma pergunta ou escolher um cenário. Quando isso acontecer, prefira uma variação pequena e relevante do exemplo mostrado: um documento com informação conflitante, uma solicitação ambígua ou uma ação que deveria exigir aprovação. Assim dá para observar como a solução lida com a incerteza sem transformar o momento numa competição para derrubar a demo.

Se não houver interatividade, tudo bem. Anote a hipótese que você gostaria de testar e faça a pergunta no Q&A ou depois da palestra. O palco não é o único lugar onde uma conversa técnica acontece.

Leve a curiosidade para o seu contexto

Depois, experimente a ideia com os seus dados, seus limites de segurança e um volume que faça sentido para o seu time. Registre o que funcionou, o que falhou e quanto custou. Essa é uma forma bem melhor de decidir se a solução cabe no produto do que confiar apenas no aplauso quando o modelo acerta a pergunta preparada.

O aplauso é para a demo. A decisão de colocar aquilo em produção merece suas próprias perguntas.

Para fechar

Sempre que eu subo ao palco com uma demo de IA ou qualquer outra coisa, eu vou mostrar um cenário preparado, isso é um fato. Vou torcer para a internet colaborar e para o modelo não resolver improvisar justo naquele minuto. Faz parte. O que eu não quero é que alguém saia dali achando que viu um produto pronto porque a resposta apareceu bonita na tela.

Se você estiver na plateia, aproveite a ideia e pergunte o que ficou de fora. E se alguém aparecer na segunda-feira querendo substituir o time inteiro ou refatorar todo o sistema com uma biblioteca nova com base naquela palestra de 40 minutos, talvez seja hora de abrir uma conversa sobre dados, falhas, custos e quem vai atender o chamado quando a mágica parar e principalmente sobre valor agregado ao negócio.