demo42
Demos de produto narradas, sem perder um dia.
Você informa uma URL e o que quer mostrar. O demo42 explora o produto num navegador real, com cursor visível, narra cada cena e devolve um MP4 pronto para compartilhar. Sem roteiro, sem gravação manual, sem editor.
Ninguém escreveu roteiro, desenhou storyboard ou abriu um editor. No fim, o tour preenche o formulário de contato por conta própria: estava ali, e era o próximo passo natural para quem assiste.
Por que existe
A GemLab toca vários projetos ao mesmo tempo, e todos mudam de uma semana para a outra. Quando alguém pergunta como está um deles, a resposta honesta é compartilhar a tela e clicar junto.
Gravar uma demo de verdade resolve isso uma vez: roteiro, take, erro no meio, regravar, cortar, subir. Um dia inteiro de alguém. No deploy seguinte, a tela mudou e a demo envelheceu. Multiplique por vários projetos e fica claro por que ninguém regrava.
- roteiro, takes e edição
- um dia inteiro de alguém
- envelhece no próximo deploy
- uma URL e uma descrição
- alguns minutos, sem horas de ninguém
- regravada quando a tela muda
Quando uma demo custa o dia de alguém, é um evento. Quando custa centavos, vira artefato de build.
A interface mudou? Regrava, como rodar a suíte de testes depois de um commit.
Como funciona
Um formulário com a URL e a descrição do que mostrar. Alguns minutos depois, um vídeo na galeria. No caminho:
- 01
Explorar
O planner navega pelo site num navegador real, lê e testa antes de prometer uma cena. Se o plano mostra a busca, é porque ele digitou nela e viu o autocomplete responder.
ia - 02
Planejar
Escreve o plano: os beats do tour, em JSON. Nunca código.
ia - 03
Aprovar
O plano para e espera uma pessoa. Planejar é rápido e barato; gravar prende um navegador e um encode do ffmpeg por vários minutos.
pessoa - 04
Compilar
Um compilador escrito pelo time transforma o JSON num script Playwright.
código - 05
Gravar
O vídeo sai do screencast do Chromium via CDP, um frame a cada pintura da página. O cursor é um elemento DOM injetado e animado: input sintético não tem ponteiro.
código - 06
Narrar e montar
A narração vira voz, o apresentador ganha rosto e lip-sync, e o ffmpeg monta o corte com trilha e marca d'água.
iacódigo - 07
Checar e publicar
Quatro gates de qualidade decidem se o vídeo vai para a galeria.
código
O plano que o demo42 escreveu para o Mother
- 01establish
- 02survey
- 03traverse
- 04demonstrate
- 05reveal
- 06traverse
- 07close
“O loop fecha no Mission Control, onde o próximo gate aparece assim que seu agente abre um pull request.”
A narração que o planner escreveu para o último beat. Ele achou o loop do produto e fez dele o loop do tour, sem que ninguém pedisse. E o card sob o cursor é o PR #1 do próprio demo42: o Mother revisa o demo42 enquanto o demo42 grava a demo do Mother.
Quatro gates antes de publicar
Um job pode terminar com sucesso e não valer nada. Cada gate nasceu de um vídeo que passou em tudo e não servia.
A validação do compilador: um plano ruim vira erro de validação, nunca erro de sintaxe.
É estruturalmente uma demo: abre estabelecendo, fecha num próximo passo e tem ao menos um demonstrate seguido de reveal.
Pelo menos 70% da gravação com algo se mexendo, medido por beat, a partir do vídeo.
Detecta tela em branco e lê o texto da tela atrás de desafios anti-bot. O reCAPTCHA do google.com passava no teste de tela vazia.
Um gate mede o que pode ser medido. Se uma tela vale a pena ser mostrada, isso ainda é julgamento humano.
Arquitetura
Propositalmente pequena: dois processos e um banco em um único arquivo. Sem broker, sem fila externa. A fila é uma tabela; um evento é uma linha.
Qualquer processo pode cair e voltar sem que o outro perceba. O servidor grava uma linha e responde; o worker pega o job com lease; a página lê os mesmos eventos do banco.
A gravação roda sobre o argo, open source. O demo42 entrega a metade que o argo supõe que uma pessoa escreveu: olhar um site nunca visto e decidir como deve ser o tour.
Decisões e trade-offs
Registradas como ADRs: o contexto, o que o time decidiu e o que isso custa.
- Contexto
- Pedir o script Playwright direto ao modelo funciona na primeira vez. Na décima, vem um arquivo com erro de sintaxe. Ou pior: um que roda e faz algo que ninguém pediu.
- Decisão
- O modelo escreve um plano em JSON e um compilador do time gera o Playwright. O arquivo gerado é uma casca fina em volta de um literal; todo o comportamento vive no tour-runtime.ts, escrito à mão e testado.
- Consequência
- Um plano ruim é erro de validação, nunca um erro de sintaxe para alguém depurar às 3h da manhã. E o modelo não consegue dizer o que não deve: um goto só alcança a origem do tour, uma tecla só vem de um conjunto fechado, e não existe verbo para "abrir outra aba e logar em outro lugar".
- Trade-off
- Expressividade. Uma nova capacidade não é ajuste de prompt: é mudança no compilador e nos testes. Aqui o domínio é fechado de propósito, e o DSL vence com folga.
const PLAN: TourPlan = { /* ... */ };
test('tour', async ({ page, narration }) => {
await runTour(page, narration, PLAN);
});- Contexto
- Planejar é rápido e barato. Gravar prende um navegador e um encode do ffmpeg por vários minutos.
- Decisão
- O roteiro é escrito primeiro e fica na fila até alguém dizer que vale a pena gravar.
- Consequência
- O tempo de navegador e de encode vai só para tours aprovados.
- Contexto
- Preencher sozinho o formulário de contato é simpático num site público. O mesmo entusiasmo aplicado a um botão de apagar, não.
- Decisão
- O beat que clica declara o próprio risco, e a validação recalcula esse risco por conta própria. Ela se recusa a clicar em apagar, comprar, checkout, cancelar assinatura, convidar ou sair, não importa o que o plano declarou.
- Consequência
- Passar o mouse sobre um botão de apagar para mostrar que ele existe, pode. Pressionar, nunca.
- Contexto
- Quase todo produto que vale uma demo vive atrás de um login. Um tour que só vê o que um estranho vê é o tour da metade errada.
- Decisão
npm run loginabre um navegador de verdade. Você entra como o app pedir (senha, SSO, 2FA, magic link, chave física) e aperta Enter.- Consequência
- Funciona com qualquer login, porque quem faz é uma pessoa, não um script chutando seletores. Nenhuma senha é digitada, guardada ou vista por um modelo.
- Contexto
- Um job de gravação leva minutos, e a página precisa acompanhar o progresso ao vivo.
- Decisão
- Dois processos e um banco em um único arquivo. O servidor grava uma linha e responde; o worker pega o job com lease e registra o progresso; a página acompanha por SSE lendo os mesmos eventos.
- Consequência
- Qualquer um dos processos pode cair e voltar sem que o outro perceba.
- Contexto
- O pipeline funcionou no primeiro dia, e o vídeo não valia nada: de 46% a 54% de cada vídeo era frame parado. A narração definia a duração do beat, e a sobra virava uma foto.
- Decisão
- Todo beat declara um shot e tem uma ação elástica que cresce para preencher a narração: drift rola a página, sweep leva o ponteiro por vários alvos, push move a câmera no ffmpeg. O hold continua existindo, limitado a 800 ms.
- Consequência
- O vídeo se move quase o tempo todo e parece um tour gravado por alguém, não um slideshow narrado. A alocação é decidida ao vivo: se uma navegação demora, as ações seguintes encolhem.
IA no processo
O único ponto com um modelo grande é o planejamento. O resto do pipeline é máquina, com nome na etiqueta, e cada peça foi escolhida por experimento, não por palpite.
Num dos primeiros tours, o planner fez 18 chamadas de exploração para sete beats que passaram na validação de primeira.
O time GemLab fez a pesquisa como trabalha no laboratório: com Claude Code.
Com ele, o time levantou modelos abertos e comerciais, escreveu os relatórios que basearam a escolha e rodou os experimentos que geraram os números ao lado. Cada experimento virou um caderno de laboratório no repositório, com custos e medições.
O WAN 2.6 não se cala: segue "mastigando ar" nas pausas. O InfiniteTalk é guiado pelo áudio, então a boca para quando a voz para, em qualquer idioma.
Fora antes do teste: Wav2Lip, MuseTalk e LatentSync, que dublam vídeo existente. Aqui só existe um retrato parado.
Um tour em outro idioma não é tradução: o plano é refeito do zero no idioma de destino. Em português, o planner achou um caminho pelo site que o tour em inglês nunca tocou.
Método e próximos passos
O velho conselho de Kent Beck: make it work, make it right, make it fast. Fazer funcionar foi o primeiro passo; o demo42 está no meio da lista.
make it work
O caminho ponta a ponta funciona desde o primeiro dia: URL e descrição entram, um MP4 narrado sai.
make it right
Qualidade: gates antes de publicar, movimento em todo beat e limites que o modelo não atravessa.
make it fast
Regravar e trocar partes do vídeo (uma cena, uma narração, uma marca) sem pagar o caminho todo de novo. E tours mais longos: hoje o teto é de um minuto.
Time
100% GemLab.
Do produto à pesquisa de modelos, o demo42 foi construído de ponta a ponta pelo time da GemLab, o laboratório AI-first da Codeminer42.
Pronto para construir software de verdade?
Conte em que estágio está sua ideia ou produto. A GemLab avalia o contexto e indica a melhor rota para transformar potencial em produto operacional.
Levar meu produto para a bancada