Il coding a scuola non coincide con l’uso occasionale di un’app né con una sequenza di istruzioni eseguita senza comprenderne la logica. Programmare significa rappresentare un problema, costruire una soluzione in un linguaggio eseguibile, verificarla e correggerla. È proprio questa alternanza tra previsione, prova ed errore a rendere il codice interessante sul piano educativo.
L’obiettivo non è trasformare ogni studente in uno sviluppatore. È creare situazioni nelle quali ragazze e ragazzi possano progettare un artefatto digitale, osservare gli effetti delle proprie decisioni e spiegare il percorso seguito. Il prodotto finale conta, ma da solo non dimostra che sia avvenuto un apprendimento.
Che cosa significa coding a scuola
La parola inglese coding indica la scrittura di codice: istruzioni formulate in modo che un sistema informatico possa eseguirle. In classe queste istruzioni possono essere composte con blocchi visuali, testo, comandi per un robot, schede programmabili o ambienti di simulazione. Cambia l’interfaccia, non il nucleo dell’attività: occorre formalizzare una soluzione e renderla eseguibile.
Il quadro europeo DigComp 3.0 colloca la programmazione nell’area della creazione di contenuti digitali. La competenza non consiste soltanto nel conoscere comandi: comprende la capacità di applicare tecniche di pensiero computazionale e di programmazione per dare istruzioni a un sistema. Questa prospettiva è coerente con la Raccomandazione europea sulle competenze chiave, che associa la competenza digitale a un uso sicuro, critico e responsabile delle tecnologie.
Una lezione, quindi, non diventa coding solo perché prevede un tablet, un robot o blocchi colorati. Deve esserci almeno un problema da tradurre, una rappresentazione formale, un’esecuzione osservabile e la possibilità di rivedere le istruzioni.
Coding, programmazione e pensiero computazionale: le differenze
Nel linguaggio educativo, coding e programmazione sono spesso usati come sinonimi. Il primo termine richiama soprattutto la pratica di scrivere istruzioni; il secondo può comprendere anche analisi dei requisiti, progettazione, test, documentazione e manutenzione. Non serve costruire una distinzione rigida: è più utile chiarire quale processo viene richiesto agli studenti.
Il pensiero computazionale è invece più ampio. Riguarda modi di affrontare i problemi — decomporli, riconoscere regolarità, astrarre, formulare algoritmi, verificare e generalizzare — che possono essere esercitati anche senza scrivere un programma. Il codice offre un ambiente particolarmente trasparente per metterli alla prova, perché il sistema restituisce un risultato che può essere confrontato con quello atteso.
| Concetto | Domanda guida | Evidenza osservabile |
|---|---|---|
| Coding | Quali istruzioni deve eseguire il sistema? | Un programma funzionante o almeno testabile |
| Programmazione | Come progetto, verifico e mantengo la soluzione? | Codice, test, versioni e documentazione |
| Pensiero computazionale | Come posso rappresentare e risolvere il problema? | Decomposizione, modello, algoritmo e revisione |
Le attività unplugged possono allenare concetti preziosi, ma non sono automaticamente codice. Ordinare azioni, descrivere un percorso o simulare un algoritmo con il corpo sviluppa il ragionamento; si passa al coding quando la soluzione viene espressa in una forma eseguibile da una macchina o da un ambiente programmabile.
Perché il valore educativo non è automatico
Un progetto digitale può essere coinvolgente e produrre un risultato piacevole senza rendere visibile ciò che gli studenti hanno compreso. Copiare blocchi da un tutorial, procedere per tentativi casuali o affidare tutto al compagno più esperto può portare a un prodotto corretto ma a un apprendimento fragile.
La ricerca di Karen Brennan e Mitchel Resnick sul lavoro con Scratch propone di osservare tre dimensioni: i concetti computazionali impiegati, le pratiche di progettazione e le prospettive sviluppate da chi crea. Il loro quadro per studiare e valutare il pensiero computazionale invita a guardare non soltanto al progetto, ma anche a come lo studente sperimenta, corregge, riutilizza, astrae e descrive il proprio processo.
Un buon percorso di coding a scuola crea perciò un ciclo intenzionale:
- prevedere che cosa dovrebbe accadere;
- costruire una prima soluzione;
- eseguire e raccogliere evidenze;
- individuare la distanza tra risultato atteso e reale;
- correggere il programma;
- spiegare le decisioni e ciò che è cambiato.
In questo ciclo il bug non è una penalità da nascondere: è un’informazione. Diventa formativo quando l’insegnante chiede di formulare un’ipotesi sulla causa, progettare un test e motivare la modifica. È una logica vicina alle metodologie didattiche attive, ma conserva un oggetto specifico: un sistema di istruzioni che produce effetti verificabili.
Come progettare un’attività: obiettivo prima dello strumento
La scelta della piattaforma viene dopo la decisione didattica. Prima di aprire un ambiente visuale o distribuire un robot, conviene compilare una breve mappa di progettazione.
| Passaggio | Domanda operativa | Esempio |
|---|---|---|
| Obiettivo | Che cosa dovranno saper fare? | Usare una condizione per gestire due casi |
| Compito | Quale problema richiede quella competenza? | Creare un quiz che reagisca alle risposte |
| Vincoli | Quali elementi devono comparire? | Una variabile, due condizioni e un ciclo |
| Evidenze | Che cosa raccoglieremo? | Versione iniziale, test, revisione e spiegazione |
| Criteri | Come riconosceremo la qualità? | Correttezza, chiarezza, test e autonomia |
Questo impianto evita che la programmazione (o coding), a scuola si riduca alla riproduzione di una procedura. Un tutorial può essere utile per apprendere l’interfaccia; subito dopo, però, occorre modificare una condizione, cambiare i dati, introdurre un vincolo o risolvere un problema nuovo. È il trasferimento a mostrare se l’alunno sa usare il concetto.
Una struttura semplice per una lezione di 60–90 minuti può prevedere:
- una sfida breve e un risultato atteso condiviso;
- una dimostrazione essenziale del concetto, non dell’intera soluzione;
- lavoro individuale o a coppie con ruoli alternati;
- una pausa di previsione prima di eseguire il programma;
- test con casi normali e casi limite;
- confronto tra due soluzioni possibili;
- riflessione finale scritta o orale.
La spiegazione iniziale resta utile quando introduce pochi concetti e prepara l’azione. Come mostra l’approfondimento sulla didattica frontale resa attiva, esposizione e applicazione non sono alternative: funzionano quando sono collegate da domande, verifiche e feedback.
Tre esempi per livelli diversi
Scuola primaria: raccontare una storia interattiva
Gli alunni progettano una breve storia con due personaggi. Devono usare una sequenza, un evento e almeno una ripetizione. Prima disegnano lo storyboard; poi costruiscono il progetto in un ambiente a blocchi; infine scambiano il lavoro con un compagno che verifica se i comandi producono l’effetto previsto. L’evidenza non è solo l’animazione: comprende lo storyboard, un errore corretto e la spiegazione del ciclo.
Scuola secondaria di primo grado: simulare un fenomeno
La classe realizza una simulazione semplice, per esempio la crescita di una popolazione al variare di una risorsa. Gli studenti definiscono le variabili, esplicitano le regole e confrontano i risultati con le ipotesi iniziali. L’attività integra matematica, scienze e cittadinanza digitale, ma la valutazione distingue la correttezza del modello dalla qualità grafica.
Secondaria di secondo grado e formazione professionale: automatizzare un processo
Il compito può riguardare il controllo di un sensore, la validazione di dati o la gestione di un piccolo flusso operativo. Gli studenti descrivono requisiti e rischi, costruiscono un prototipo, preparano casi di test e documentano le decisioni. La complessità tecnica cresce, mentre resta invariato il ciclo progettare–eseguire–verificare–migliorare.
La raccolta di risorse di EU Code Week offre attività e materiali per pubblici differenti; la sezione di ricerca su Scratch consente invece di approfondire le basi educative dell’ambiente. Sono punti di partenza, non curricoli pronti: vanno selezionati in funzione di età, prerequisiti, obiettivi e accessibilità.
Strumenti, inclusione e organizzazione della classe
Non esiste uno strumento migliore in assoluto. Un ambiente a blocchi riduce il carico legato alla sintassi e rende immediatamente visibili strutture come eventi, condizioni e cicli. Un linguaggio testuale permette di affrontare sintassi, librerie e pratiche più vicine allo sviluppo software. Robot e schede programmabili aggiungono un comportamento fisico, ma richiedono gestione dei dispositivi, tempi di configurazione e alternative in caso di guasto.
Per scegliere, il docente può verificare cinque aspetti:
- coerenza tra funzioni disponibili e obiettivo di apprendimento;
- possibilità di salvare, esportare e confrontare le versioni;
- accessibilità da tastiera e compatibilità con tecnologie assistive;
- requisiti di account, trattamento dei dati e condizioni d’uso;
- disponibilità di una soluzione alternativa offline o a bassa connettività.
L’articolo sugli strumenti digitali a scuola aiuta a inquadrare privacy, accessibilità e scelta delle applicazioni. Per i contenuti pubblicati sul web, le WCAG 2.2 sono il riferimento tecnico internazionale: contrasto, uso della tastiera, alternative testuali e chiarezza delle interazioni non sono dettagli da aggiungere alla fine.
Anche l’organizzazione dei gruppi incide. Nelle coppie si possono alternare chi guida la soluzione e chi controlla previsioni e test. I ruoli devono cambiare: assegnare stabilmente la tastiera alla persona più esperta consolida le differenze. È utile raccogliere brevi tracce individuali, perché un prodotto di gruppo non consente da solo di attribuire gli apprendimenti.
Valutare il coding a scuola
Valutare soltanto se il programma “funziona” premia il risultato e nasconde il processo. Un artefatto incompleto può mostrare un ragionamento solido; uno perfetto può essere stato copiato o prodotto quasi interamente da un’altra persona. La valutazione dovrebbe incrociare il progetto con osservazioni, versioni intermedie e spiegazioni.
Una rubrica essenziale può usare quattro dimensioni:
- rappresentazione del problema: individua dati, vincoli e risultato atteso;
- costruzione della soluzione: usa in modo pertinente sequenze, condizioni, cicli, variabili o funzioni;
- test e debugging: prepara casi di prova, interpreta gli errori e modifica la soluzione con criterio;
- spiegazione e trasferimento: motiva le scelte e riutilizza il concetto in un compito diverso.
Per ogni dimensione bastano tre o quattro livelli descritti con comportamenti osservabili. “Eccellente” o “insufficiente” dicono poco; formule come “prevede il risultato prima dell’esecuzione”, “isola la causa dell’errore” o “confronta due soluzioni” orientano sia il giudizio sia il feedback.
Il portfolio può includere la prima versione, uno screenshot o una copia del codice, l’elenco dei test, una revisione commentata e una nota finale. In questo modo l’attività di coding lascia una traccia leggibile anche dopo la lezione e consente allo studente di riconoscere che cosa ha imparato.
Coding e intelligenza artificiale generativa
Gli strumenti generativi possono spiegare un errore, proporre esempi o produrre porzioni di codice. Questo non elimina la programmazione a scuola, ma rende ancora più importante valutare previsione, verifica e comprensione. Se lo studente incolla una soluzione che non sa leggere, il risultato non costituisce una prova di competenza.
Un uso didattico sensato può chiedere di:
- prevedere l’output prima di eseguire il codice generato;
- individuare un errore o un’assunzione nascosta;
- costruire test che mettano in crisi la soluzione;
- confrontare due proposte e motivare la scelta;
- riscrivere una parte e documentare le modifiche.
DigComp 3.0 integra l’intelligenza artificiale in modo trasversale nelle competenze digitali, ma conserva la programmazione tra le capacità di creazione. Il punto non è competere con una macchina nella velocità di scrittura: è saper formulare il problema, controllare ciò che viene prodotto e assumersi la responsabilità del risultato.
Checklist per progettare il percorso di coding a scuola
- L’obiettivo descrive una competenza osservabile e non il semplice uso di uno strumento.
- Il compito richiede decisioni, non soltanto la copia di passaggi.
- Il risultato atteso e i vincoli sono comprensibili.
- Gli studenti formulano almeno una previsione prima dell’esecuzione.
- Sono previsti casi di test e tempo per il debugging.
- I ruoli nei gruppi ruotano e restano evidenze individuali.
- Lo strumento è accessibile e adeguato all’età e ai dati trattati.
- La rubrica osserva problema, soluzione, test e spiegazione.
- È prevista una variante che richieda trasferimento.
- L’eventuale uso dell’IA è dichiarato, verificato e discusso.
In sintesi
Quando il coding a scuola è progettato con obiettivi, vincoli, test e criteri di valutazione, il codice diventa un laboratorio nel quale il ragionamento lascia tracce. L’elemento decisivo non è il programma perfetto, ma la capacità di prevedere, costruire, verificare, correggere e spiegare.
Per questo conviene partire da ciò che si vuole osservare e solo dopo scegliere linguaggio, piattaforma o dispositivo. Il percorso è riuscito se lo studente non si limita a mostrare che il progetto funziona, ma sa ricostruire perché funziona, dove ha sbagliato e come trasferire la strategia a un problema nuovo.
Domande frequenti
Che cosa si intende per coding?
È la scrittura di istruzioni in un linguaggio che un sistema informatico può eseguire. In educazione comprende anche la progettazione della soluzione, le prove, la correzione degli errori e la spiegazione delle scelte.
Qual è la differenza tra coding e pensiero computazionale?
Il coding produce un programma eseguibile. Il pensiero computazionale è un insieme più ampio di processi per rappresentare e risolvere problemi, come decomposizione, astrazione, algoritmi e verifica. Si può esercitare anche senza computer; il codice è uno dei contesti in cui diventa osservabile.
Da quale età si può iniziare?
Si può iniziare nella scuola primaria con compiti brevi, ambienti visuali e obiettivi semplici. La difficoltà deve dipendere dai prerequisiti e dai concetti richiesti, non dall’età indicata dal software. Prima dello strumento vengono chiarezza del compito, accessibilità e accompagnamento docente.
Come si valuta un progetto di coding a scuola?
Occorre osservare sia il prodotto sia il processo: comprensione del problema, uso dei costrutti, qualità dei test, debugging, autonomia e capacità di spiegare o trasferire la soluzione. Versioni intermedie, brevi colloqui e portfolio rendono queste evidenze più affidabili.
Pubblicato originariamente il 6 dicembre 2022 · Aggiornato il 15 settembre 2026
A cura della redazione di Diario della Formazione
