Como automatizei a correção de mais de 1200 provas: o impacto dos resultados nas decisões pedagógicas

Atualmente atuo como coordenador de TI em uma instituição de ensino particular em Duque de Caxias, RJ. Se você já trabalhou com a área de educação alguma vez, já deve ter percebido o quão analógicas as coisas podem ser. Sei que nem todas as instituições são abertas a novas tecnologias, mas por aqui, graças a Deus, eu tenho essa possibilidade.

No início de abril a coordenação pedagógica me trouxe um desafio: "Precisamos aplicar um simulado e não sabemos como montar uma prova feita por muitos professores!" A lógica normal era cada professor enviar sua prova pronta por e-mail.

Mas num simulado multidisciplinar, como gerir contribuições separadas para uma mesma prova? Como criar versões diferentes para reduzir cola? E depois, como corrigir mais de 20 turmas, aproximadamente 1200 alunos, em dois dias de avaliação?

Decidi tentar. Fui levantando os requisitos a partir das conversas com a coordenação e aproveitei para testar pela primeira vez o desenvolvimento assistido por IA. A palavra é essa: "assistido". Digo isso porque quando você resolve um problema que vai afetar a vida de centenas de pessoas, a história do prompt mágico cai por terra rápido, e vou explicar o porque.

A solução que emergiu das conversas

A primeira decisão foi sobre como receber as questões dos professores. Usei um Google Forms. Enquanto eles enviavam as questões, já desenvolvia as primeiras features do MVP: importar as respostas do formulário e gerar a prova em múltiplas versões com os gabaritos embaralhados.

Para a geração do PDF escolhi Python com ReportLab. Minha stack padrão é Node e React, mas a escolha do Python fez sentido por dois motivos: a visão computacional seria mais simples de trabalhar nessa linguagem, e era uma boa oportunidade de aprofundar meus conhecimentos numa linguagem que já usei em outros projetos pessoais e para dar aulas, mas não é minha preferência no dia a dia.

A prova poderia ser feita de forma digital, em um sistema que bloqueasse o uso do computador para outros fins focando apenas na prova, como muitas instituições de ensino fazem país a fora. Mas não tínhamos um parque de máquinas tão grande disponível. Então o caderno impresso e o cartão resposta com bolhas foram a escolha natural, mas também por outro motivo: preparar os alunos para o formato do ENEM e de concursos públicos, os do ensino médio que já estão na reta final, e os do fundamental II que iriam vivenciar essa experiência pela primeira vez.

Como o sistema identifica cada aluno

Em vez de pedir que o aluno preenchesse a matrícula manualmente, cada cartão foi gerado com um ID único vinculado ao aluno e à avaliação no banco de dados.

Em cada um dos dias de prova, os alunos receberam um cartão e um caderno de questões. No caderno, uma tarja indicava qual a versão da prova. No cartão resposta, o cabeçalho vinha com o nome do aluno, o ID do cartão e uma área com bolhas para preencher a versão da prova, e logo abaixo a grade de questões a serem preenchidas.

Como fallback, existia a possibilidade de cartões anônimos que poderiam ser associados depois da leitura, para casos de ausência, reimpressão ou dano ao cartão original.

Pesquisando como provas de larga escala fazem a correção, encontrei o OMR (Optical Mark Recognition), a tecnologia por trás da leitura dos gabaritos do ENEM.

A partir daí, com a ajuda do Claude no navegador para explorar esse terreno novo pra mim, comecei a entender como processar imagens de PDF, TIFF e outros formatos gerados pelo scanner da escola.

O pipeline de leitura funciona assim: o cartão é digitalizado e a imagem passa por binarização Otsu (um jeito automático de transformar a imagem em apenas duas cores, preto e branco), para separar as marcações do fundo independente da iluminação.

Depois disso, o algoritmo detecta as quatro âncoras nos cantos para corrigir a perspectiva, e então lê as bolhas célula a célula.

Após a digitalização, veio a primeira dificuldade. Quando a equipe de TI começou a processar os cartões, apareceu um problema que ninguém tinha previsto: muitos alunos simplesmente não marcavam a versão da prova recebida (A, B, C ou D). Para o sistema, era esse o dado que determinava qual gabarito usar na correção.

A solução foi criar uma tela de revisão que listasse os casos sem versão, permitindo que a equipe associasse manualmente a prova correta antes de calcular a nota. Acionei a coordenação pedagógica, que verificou as versões das provas de cada aluno que não havia preenchido, e manualmente fizemos as associações.

Por que dados são tão valiosos na educação

Quando os relatórios ficaram prontos, a reação da coordenação foi diferente do que eu esperava. A surpresa não foi a velocidade da correção, como inicialmente esperavam. Foi o que os dados tornaram visível.

Organizei o sistema para gerar uma visão de desempenho por turma e por ano escolar. É possível identificar quais questões a turma errou mais, quais disciplinas puxaram a nota, e como cada turma se compara às outras do mesmo ano escolar.

A distribuição de respostas por alternativa em uma questão de matemática, por exemplo, pode revelar que boa parte da turma cometeu um erro de sinal, algo que um professor raramente vê com clareza antes de corrigir pilha por pilha.

Durante a implementação, por exemplo, o regimento escolar previa uma regra de arredondamento: qualquer nota após a vírgula era arredondada para o valor inteiro ou meio ponto mais próximo. Decidi mostrar as duas notas lado a lado no relatório final, a nota bruta e a nota já arredondada conforme o regimento.

Ver os dois números lado a lado fez a equipe pedagógica começar a estudar se a regra atual potencializa ou encobre o esforço de quem está perto de subir de nota. A coordenação não encarou isso como falha do regimento, mas como oportunidade de melhoria.

Essa discussão ainda está em aberto. E partiu de um dado que simplesmente não existia antes.

O papel do Claude Code

Trabalhei com o Claude Code ao longo de vários dias. Ele foi muito útil para estruturar o projeto desde o início: organização de módulos, separação entre geração e leitura, parâmetros centralizados em arquivo de configuração.

O plugin superpowers ajudou a manter um processo mais consistente garantindo sempre a criação de testes e fazendo um brainstorm adequado antes de cada novo procedimento.

O que a ferramenta não faz é entender o contexto escolar. Ela pode inferir o que faz diferença, mas a realidade prática e como que o sistema afeta o dia a dia da instituição, apenas um analista minucioso pode descrever e especificar as mudanças e funções necessárias.

O que ficou claro pra mim é que o valor do desenvolvedor que trabalha com IA está em ser um bom analista de sistemas: entender o contexto de verdade, definir claramente o que precisa ser feito, validar o que foi implementado, conversar com as pessoas certas para extrair corretamente as informações e no fim garantir que os requisitos foram atendidos de fato, e não "mais ou menos".

A IA executa bem quando você sabe o que quer. A dificuldade de saber o que quer é sua.

O que vem depois

O simulado ocorreu, os relatórios estão em análise pela coordenação. O conceito foi validado.

Os próximos passos da aplicação irão focar em:

• Criar uma interface para os professores cadastrarem questões sem passar pelo Google Forms
• Integração com o ERP da escola para facilitar o lançamento das notas (a API atual da empresa parceira tem limitações a explorar)
• Fluxo de revisão mais claro para os casos em que o aluno não preencheu a versão da prova
• Documentação e Onboarding para que outra pessoa opere o sistema sem meu acompanhamento

E se você leu até aqui, espero que tenha gostado. Se tiver alguma sugestão ou dúvida ( que eu possa contribuir respondendo ), fique a vontade para comentar.