8
jpierreribeiro
5 min de leitura ·

[PITCH] Foi o aluno ou foi a IA? Criei um "replay" para atividades de programação

O problema

Na minha universidade, vi vários professores enfrentando o mesmo problema: os alunos entregavam códigos cada vez melhores, mas as entregas diziam cada vez menos sobre o que eles realmente haviam aprendido.

Uma vez ouvi um professor dizer: "Estamos avaliando alunos ou o ChatGPT?"

O aluno e o professor acabam presos em uma espécie de teatro acadêmico. O aluno finge que fez, o professor finge que acredita, e a avaliação continua como se nada tivesse mudado.

Todo professor conhece um código feito pelo ChatGPT, comentários explicando o óbvio, nomes perfeitinhos para tudo, abstrações que ninguém pediu, tratamento de casos que nem existiam no enunciado e, às vezes, até uns emojis para enfeitar.

texto

Então me surgiu uma dúvida:

Como provar a autoria do código?

Olhando apenas para o código final, não dá.

texto

Podemos analisar o estilo, procurar padrões e comparar soluções, mas tudo isso continua sendo uma tentativa de adivinhar. Um aluno pode escrever um código com “cara de IA”, assim como uma IA pode gerar um código perfeitamente comum.

Então eu decidi parar de olhar apenas para o resultado. E cheguei na conclusão: se o código final já não conta a história inteira, precisamos preservar o caminho até ele.

E como fazer isso?

Foi daí que nasceu minha primeira ideia. Onde passei a chamar de Dalivim.

Criar um ambiente de desenvolvimento virtual onde a atividade deixa de ser apenas um arquivo e passa a ser uma linha do tempo.

texto

Cada alteração relevante no editor gera um evento. O código inserido ou removido, as execuções, os erros, as colagens, as pausas e as mudanças de contexto são organizados na ordem em que aconteceram.

As execuções também ficam vinculadas ao estado exato do código naquele momento. Assim, não sabemos apenas que o aluno executou o programa: conseguimos saber qual versão ele executou, qual foi o resultado e o que mudou depois.

Ao final, o código entregue não está mais isolado. Ele é o último estado de uma sequência que pode ser reconstruída.

Essa escolha de arquitetura possibilita reconstruir a sessão com precisão.

A caixa-preta dos professores

texto

No mundo da aviação, quando algo dá errado, os investigadores não tentam descobrir o que aconteceu olhando apenas para os destroços. Eles recorrem à caixa-preta, que preserva uma linha do tempo do voo: comandos, condições, alertas e decisões tomadas ao longo do percurso.

A caixa-preta não julga o piloto e não aponta culpados. Ela registra fatos para que o acontecimento possa ser reconstruído com contexto.

Na programação, porém, ainda avaliamos como se apenas os destroços existissem. Recebemos o código final, observamos o resultado e tentamos imaginar tudo o que aconteceu antes dele.

O Dalivim parte de uma ideia parecida: criar uma espécie de caixa-preta da atividade de programação. Não para vigiar o aluno ou declarar automaticamente quem escreveu o código, mas para preservar o processo que normalmente desaparece no momento da entrega.

Quando o professor aperta o play

Vê o aluno começar do zero, testar uma ideia, encontrar um erro e voltar para corrigir. Ou vê 150 linhas surgirem de uma vez, depois de uma saída da página, sem nenhuma construção anterior.

Colagens, pausas, execuções, mudanças de aba e ritmo de digitação deixam de ser informações perdidas. Tudo passa a fazer parte da revisão.

texto

Cada alteração no código passa a fazer parte de uma linha do tempo.

É possível ver quando o aluno começou, o que escreveu, o que apagou, quais erros encontrou, quantas vezes executou o programa e como chegou à solução final.

Colagens, saídas da página, períodos de inatividade, mudanças bruscas no código ou variações no ritmo de edição, sozinho, nenhum desses sinais prova fraude.

Colar código não significa necessariamente usar IA. Sair da página não significa necessariamente procurar uma resposta. Digitar rápido não transforma ninguém em suspeito.

Mas, quando esses acontecimentos são colocados na ordem em que ocorreram, o professor recupera algo que havia perdido: contexto.

A decisão continua sendo humana. A diferença é que ela não precisa mais ser tomada olhando apenas para o resultado final.

texto

Crie. Compartilhe. Revise.

O Dalivim foi pensado para não criar mais trabalho para o professor.

O fluxo é simples:

Crie uma atividade de programação e defina as instruções.

Compartilhe o acesso com a turma para que os alunos desenvolvam a solução em um ambiente controlado.

Revise as entregas com o código final, as execuções e o histórico completo da sessão no mesmo lugar.

O professor não precisa assistir a todas as sessões do começo ao fim. O Dalivim organiza os principais acontecimentos da atividade e permite ir diretamente aos momentos que merecem atenção: grandes colagens, mudanças bruscas, períodos fora da página, execuções e alterações relevantes.

Minha visão como Founder

Construir a tecnologia é apenas uma parte do trabalho. A outra é descobrir como ela se comporta diante de uma turma real, com limitações, exceções e rotinas que nenhum ambiente de testes consegue reproduzir.

Não se trata de vigiar cada tecla nem de transformar todo aluno em suspeito.

Trata-se de devolver significado à avaliação de programação em uma época em que gerar uma resposta pronta se tornou fácil, mas demonstrar aprendizado continua sendo essencial.

Se você ensina programação e também acredita que precisamos repensar a forma como avaliamos programação, quero convidá-lo.

Quero testar o Dalivim com minha turma

O plano para professores custará R$ 49 por mês, com até cinco turmas e sem limite de alunos. Não importa se sua turma tem 10, 40 ou 100 estudantes: você poderá usar a plataforma com todos eles.

Mas, durante esta fase inicial, quero fazer uma proposta diferente.

Você poderá usar o Dalivim gratuitamente durante este semestre, com uma turma real e sem compromisso de contratação.

Em troca, quero ouvir sua experiência: onde a ferramenta ajuda, onde atrapalha, o que funciona em sala de aula e o que ainda precisa ser melhorado.

E, caso o Dalivim faça sentido para você depois desse período, seu plano ficará por R$ 29 por mês, como preço de fundador, para sempre.

Clique aqui para conhecer a plataforma. Ou entre diretamente no formulário para solicitar o seu acesso: Quero testar o Dalivim com minha turma.

Carregando publicação patrocinada...
4

De founder para founder:

Legal demais. Talvez seja o projeto com maior potencial real que já vi em pitches aqui no TabNews.

Primeiro o choque de realidade. Construir a tecnologia é a parte fácil. O verdadeiro desafio do Dalivim vai ser distribuição, vendas e modelo de negócios. Se você ficar preso no plano de R$ 49/mês para professores de computação, você terá um excelente projeto de estimação, mas nunca uma empresa de verdade.

Alguns pontos para você refletir:

  1. Internacionalização desde o dia 1: Esse problema não é local, é global. Universidades do mundo inteiro estão lidando exatamente com o mesmo "teatro acadêmico". Não limite seu mercado ao Brasil. Traduza o produto e a comunicação para o inglês imediatamente.

  2. Fuja da armadilha do B2C: Professor universitário não tem orçamento próprio relevante. Se você cobrar R$ 49/mês, precisará de milhares de clientes para pagar suas contas. O caminho é o B2B Enterprise: vender licenças anuais de milhares de dinheiros diretamente para os diretores de departamentos de tecnologia ou reitorias das faculdades.

  3. O Pitch para a Y Combinator e afins (A "Turnitin da era da IA"): Para atrair grandes aceleradoras você não pode se apresentar apenas como "um replay de código para aulas de computação" (mercado muito pequeno). O pitch precisa ser "Infraestrutura de integridade acadêmica na era da IA".

    • Expanda para validar qualquer produção de texto digital. Lembre-se: a Turnitin (ferramenta de plágio tradicional) foi adquirida por US$ 1,75 bilhão porque ela valida a autoria em qualquer disciplina. O Dalivim pode ser a Turnitin da era generativa?!

  4. O calcanhar de Aquiles dos gigantes: A Turnitin e todos os outros incumbentes estão correndo desesperadamente para criar "detectores de IA", mas eles estão caindo na armadilha óbvia de tentar analisar o resultado final. O diferencial do Dalivim é real. Mudar a infraestrutura de gigantes que foram construídas em cima de upload de arquivos para monitoramento de sessão em tempo real é um pesadelo para eles. A lentidão dos incumbentes é a sua janela de oportunidade. Não demore. Um programa de aceleração é questão de sobrevivência.

  5. Open-Core e Self-Hosted é obrigatorio: Instituições de ensino são extremamente burocráticas com privacidade de dados de alunos (como a LGPD/GDPR). Oferecer uma versão community gratuita e self-hosted (que o próprio professor possa rodar no servidor da faculdade) é a única forma de driblar a burocracia de TI, conseguir adoção orgânica rápida e criar defensores da sua marca lá dentro.

  6. Foco comercial e Sociedade: O ambiente acadêmico é notoriamente difícil de penetrar, lento e político. Produto bom não se vende sozinho. Busque o quanto antes um sócio comercial forte, com experiência comprovada em vender tecnologia para instituições de ensino. E não tenha medo de oferecer uma fatia generosa da empresa, no mínimo uns 30% de equity, estruturado com cláusulas de vesting. É muito melhor ter 70% de um negócio real do que 100% de um projeto que ninguém usa.

Sendo bem pragmático, a estatística diz que a maioria desses projetos de faculdade acaba virando apenas uma ferramenta interna da própria universidade do criador. Mas se você conseguir olhar além do código, estruturar um modelo B2B agressivo e mirar no mercado global, o potencial de escala e de um eventual exit bem gordo é real.

O jogo agora é sobre negócios, não sobre código. Muito sucesso na jornada!

2

Adorei seu comentário e os pontos citados. Vou responder por tópicos.

  1. A ideia principal sempre foi expandir internacionalmente, mas queria validar localmente num ambiente real, como estou fazendo agora.

  2. O modelo B2C atual parte da mesma premissa da resposta anterior, atrair professores para validar em suas universidades locais. O correto é realmente como você orientou, vender para B2B.

  3. É o caminho correto a seguir, validando a ferramenta primeiro. Especificamente sobre o mercado de recrutamento técnico, a arquitetura do Dalivim foi construída para lidar com diferentes cenários, é desacoplada e dividida em três serviços com responsabilidades bem definidas. O backend educacional (BFF) é a única camada que conhece professor, aluno e turma: ele cuida de autenticação, permissões e traduz esse vocabulário para conceitos neutros antes de falar com o resto do sistema. O engine é um serviço separado, com API e banco de dados próprios, que faz o trabalho pesado: ingestão de telemetria, análise de rastreabilidade, replay e geração de evidências, tudo em termos genéricos (sujeito, item de trabalho, sessão rastreada), multi-tenant desde a primeira migração e sem uma linha de vocabulário educacional. O processamento assíncrono roda num worker com outbox transacional, então nenhuma submissão se perde entre serviços. O produto de educação é um cliente do engine, não o engine em si. Um vertical de recrutamento técnico seria um segundo cliente da mesma API: outro tenant, outro vocabulário (candidato, desafio, entrevista), mesma análise, mesmo replay, mesma execução segura. Nada precisa ser reescrito; precisa ser conectado.

  4. Especificamente sobre o Turnitin e outras empresas, é verdade que nenhuma delas fez algo desse nível. Se concentram em avaliar o arquivo pronto, que é simplesmente adivinhação.

  5. Dalivim é self-hosted, nenhum dado é enviado para ferramentas ou empresas externas, o code runner principal do dalivim é uma sandbox particular, construído em Go, baseada em nsjail e csgroup. Exceto os códigos que rodam React e afins, esses dependem de outra biblioteca chamada Sandpack, que também é self-hosted. Esses códigos obviamente rodam numa instância particular, longe do servidor principal. Dalivim também segue a LGPD desde o primeiro dia. Alguns dados têm prazos de exclusão obrigatória, telemetria bruta e snapshots de código expiram sozinhos em janelas configuráveis (90 a 365 dias, conforme a sensibilidade), e o sistema se recusa a subir em produção com essa limpeza desligada. Antes de qualquer coleta, o aluno vê um aviso claro do que será registrado e por quê, e a versão exata do texto que ele aceitou fica guardada com hash e data, dá para provar depois o que foi mostrado. E o mais importante: o que nunca entra no sistema. Conteúdo da área de transferência, teclas digitadas, webcam, gravação de tela nada disso é coletado, e não por promessa: o servidor descarta na entrada qualquer coisa fora de uma lista fechada de métricas numéricas. A instituição é a controladora dos dados e tem à disposição exclusão e anonimização por aluno, registradas em trilha auditável. Mas confesso que falta revisão jurídica formal, contrato de operador, política publicada, o rito todo.

  6. É atualmente meu ponto fraco, não sou experiente com isso. Principalmente nesse mercado de edtech. Vou ter que buscar um parceiro comercial se quiser levar essa ideia verdadeiramente longe.

3

Rapaz, vou te falar. Que ideia original e genial! Sou da geração passada, onde tudo era feito à mão. Sempre fiquei me perguntando como os professores iam garantir o aprendizado dos alunos na era da IA. Sua solução vem pra sanar isso. Parabéns!

Também estou nessa de construir um SaaS sendo solo founder. Criei o Ebookr - um gerador de Ebooks com IA.

Documentei parte da jornada aqui no TabNews também: https://www.tabnews.com.br/ViniciusRamos/build-in-public-criando-um-saas-na-forca-do-odio

Boa sorte meu caro 🚀

0
2

Interessante a sua ideia, vou olhar com mais calma. Mas acredito que, ao longo do tempo, as avaliações precisarão de ajustes. Vou deixar meus 0,01 centavos de contribuição.

Não estou dizendo que seu projeto não é válido, pelo contrário: achei muito massa, porque ajuda os professores a identificar e direcionar os alunos.

Porém, no contexto atual, é praticamente fora de cogitação não usar IA para código. O problema de verdade, na minha humilde opinião, é conseguir explicar e fazer os devs atuais entenderem que um problema antigo, com a IA, só tende a aumentar: escrever código ruim.

Nem sempre isso acontece porque o dev é ruim, mas porque é preguiçoso. Para quem é da área, fica fácil entender. Quantas vezes você ouviu que era preciso documentar o sistema e isso não foi feito? Quantas vezes viu dev começando a escrever código sem ter especificado bem o sistema que está desenvolvendo? E assim por diante...

Desenvolvimento de software vai muito além de escrever código. E hoje ainda enfrentamos os mesmos problemas que existiam antes do surgimento da IA. A diferença é que, com a velocidade de acesso e propagação da informação, isso fica cada vez mais gritante.

2

Olá, Dalmo. Sua preocupação é válida, afinal é inevitável não usar IA, mesmo que seja para consulta como muito de nós fizemos por livros, StackOverflow e agora LLMs generativas.

As LLMs hoje em dia funcionam como um motor de busca. Os alunos vão utilizar e não tem como coibir isso. Agora, as atividades no Dalivim são personalizáveis, se permite ou não utilizar IA é do gosto do professor.

O fato é, se um aluno copiar e colar diretamente do ChatGPT ou de fontes externas ele não vai ser "punido" por isso. Os registros são imutáveis e vão continuar apontando o que foi feito e da maneira que foi feito, mas a decisão final é humana.

Existem boas ideias, como por exemplo permitir agregar um modelo de IA diretamente na atividade e registrar a maneira que os alunos constroem o código com esse auxílio. Assim como algumas empresas que oferecem ferramentas de recrutamento e livecoding fazem.

1
2

Perspectiva de professor (hoje ensino inglês; antes, muitos anos de negócios) — e vou discordar do próprio pressuposto do produto, com respeito pelo que você construiu, que tecnicamente é impressionante.

Se a IA faz a tarefa, o problema não é descobrir quem fez. É que a tarefa passou a medir a coisa errada. Vigiar a autoria é entrar numa corrida armamentista que o professor perde sempre — a cada semestre a IA fica melhor em parecer aluno, e o aluno fica melhor em usar a IA. A energia que a instituição gastaria auditando, na minha opinião, rende mais redesenhando a avaliação: cobrar o que não dá para delegar.

No meu campo isso ficou binário: a IA escreve uma redação em inglês melhor que qualquer aluno meu, então redação como dever de casa morreu como instrumento de avaliação — e não faz sentido eu "ensinar" o que a máquina já faz pelo aluno. O que sobrou de valioso é justamente o que não tem como terceirizar: entender e se expressar ao vivo, na reunião, na conversa. É nisso que passei a concentrar aula e avaliação. Imagino que em programação exista um equivalente (defender o código ao vivo? explicar a decisão?), mas aí vocês conhecem melhor que eu.

Fica a pergunta sincera, porque é ela que decide o futuro do produto: a universidade quer pagar para policiar o mundo antigo ou para migrar para o novo? Meu palpite é que o segundo mercado é maior e briga menos com o aluno.

2

Discordo, não é somente sobre auditoria. É sobre devolver aos professores a autonomia e controle sobre o ensino.

Infelizmente no Brasil o ensino é nivelado por baixo, quando um professor entrega uma atividade e turma fica dependente de ferramentas externas para concluir até coisas básicas eles não aprendem, e o professor fica a mercê da situação, tendo que gastar sua energia e sanidade mental repassando o mesmo conteúdo, repetindo os mesmos assuntos e preso naquilo, enquanto poderia avançar na ementa.

E no fim, quem acaba se prejudicando são os próprios alunos.

0