I criteri erano nella testa dell’insegnante. Era quello il problema.

Un centro di formazione gestiva la correzione dei compiti con tre bot Telegram. Gli studenti consegnavano il lavoro, i bot lo inoltravano da qualche parte, un insegnante lo controllava a mano, i voti finivano in un file di Google Sheets. In qualche modo funzionava.

Il brief era sostituire i bot con qualcosa di meglio.

Prima di scrivere una riga di codice, abbiamo letto l’intero corso.

Non c’era un elenco dei compiti. Non c’erano criteri di valutazione scritti. I requisiti di ogni consegna esistevano dentro i contenuti del corso e nell’esperienza dell’insegnante, ma da nessun’altra parte. L’insegnante sapeva com’era fatta una buona presentazione. I bot no. Ecco perché la correzione richiedeva così tanto lavoro manuale: senza criteri espliciti, l’unica persona in grado di valutare una consegna era quella che sapeva già cosa cercare.

Abbiamo estratto dal corso 14 compiti e trasformato ciascuno in una specifica strutturata. Ogni criterio è stato marcato come obbligatorio o facoltativo. Ogni motivo di rifiuto è stato scritto in un linguaggio semplice, su cui uno studente può agire. Le specifiche sono state salvate in JSON: con versioni, riutilizzabili, senza ambiguità. Solo dopo questo lavoro abbiamo costruito qualcosa.

Un’app ha sostituito tutti e tre i bot.

Uno studente apre l’app e vede il compito attivo, la scadenza e un pulsante. Consegna il lavoro in qualsiasi formato: testo, foto, video, presentazione, documento. Può scattare direttamente dalla fotocamera dentro l’app. I file vanno su Google Drive. Lo studente è libero subito, mentre la correzione procede in background.

La correzione confronta la consegna con i criteri strutturati di quel compito. Se il lavoro viene rifiutato, lo studente riceve un elenco numerato di cose precise da correggere, con il riferimento al criterio esatto che ogni punto non soddisfa. Non un punteggio vago, non un commento generico: un elenco concreto. Punto uno, punto due, punto tre. Lo studente corregge e consegna di nuovo.

L’insegnante vede un flusso dei lavori in arrivo con il risultato della correzione già allegato. Accettato, rifiutato o segnalato per un controllo manuale. L’insegnante esamina il risultato, guarda la consegna e dà il voto finale. Il lavoro che non richiede il giudizio di uno specialista non arriva all’insegnante. Quello che lo richiede, arriva con il contesto già preparato.

L’insegnante può restituire il lavoro allo studente per una revisione, con un commento scritto. Può scavalcare la correzione automatica e dare il voto a mano. Per i compiti che non si prestano a un controllo automatico, il passaggio di correzione viene saltato del tutto.

La classifica mostra a ogni studente la sua posizione nella classe, il suo punteggio e la distanza dal primo. Gli altri studenti appaiono come animali: un panda, un riccio, una volpe. La maschera animale che ogni studente vede per i compagni è unica per lui, così la classe non può capire collettivamente chi sta restando indietro confrontando ciò che vede. La distanza in numeri resta visibile. I nomi no.

Due volte al giorno il sistema pubblica su Telegram un riepilogo della classe: quanti studenti hanno consegnato, quanti sono in revisione, quanti non hanno iniziato. L’insegnante lo riceve senza aprire l’app.

Come lo abbiamo costruito

Abbiamo scritto il backend da zero su Express e TypeScript, con SQL puro su PostgreSQL. La logica di dominio dei bot è stata portata direttamente: stesso modello di dati, stesse regole di business, infrastruttura diversa. I bot sono stati spenti.

Tutto il sistema gira sul nostro VPS. Nessun limite di terze parti. Nessun rallentamento da piano gratuito. Le credenziali di tutti i servizi esterni stanno solo sul server; il client parla con la nostra API e con nient’altro.

Tre aspetti hanno richiesto soluzioni non ovvie.

Il primo era la concorrenza. Se uno studente consegna cinque file in rapida successione, deve essere elaborato solo il primo. Lo gestiamo con un unico aggiornamento atomico del database che riserva la consegna prima dell’inizio dell’elaborazione. Uno studente non può bruciare i propri tentativi o il budget di correzione consegnando troppo in fretta.

Il secondo era il carico. Sotto un picco di consegne simultanee, il servizio di correzione raggiungeva i limiti di frequenza e restituiva errori agli studenti. Abbiamo costruito una coda persistente basata sul database: lo studente viene liberato subito, un worker elabora le consegne una alla volta, riprova in caso di errore e, dopo diversi tentativi falliti, inoltra la consegna all’insegnante per una correzione manuale. La coda sopravvive a un riavvio del server.

Il terzo era la geografia. Il servizio di correzione non funziona da alcune località dei server. Il sistema in produzione restituiva errori che sembravano un problema di ricezione. Abbiamo spostato il backend su un VPS a Tashkent e trasformato il server originale in un reverse proxy. Gli studenti che avevano già installato l’app non hanno dovuto aggiornare nulla.

L’app funziona su Android, iOS e web da un’unica base di codice. Due settimane dalla prima conversazione a un sistema funzionante in produzione.

3 bot Telegram sostituiti da 1 app. 34 studenti in produzione. 14 compiti estratti dal corso e strutturati, tra cui 11 esercitazioni, 2 esami e un progetto. 0 credenziali nel bundle del client. Circa 2 settimane dall’idea alla produzione.

La versione web attiva è su alfahw.alfakom.uz.