Senza un solo sensore: stimare la portata delle fognature con il radar meteo in tempo reale

Ho costruito un prototipo che guarda il radar meteo della Protezione Civile ogni 5 minuti e dice, comune per comune della mia Provincia, se la portata in fognatura è tale da rendere normale che gli sfioratori scarichino. Senza un solo sensore in campo. Lo trovate qui: radar.danielesturla.it.

Prima di cominciare: fognature nere, bianche e miste

Per chi non conosce l'argomento: le fognature possono essere nere, bianche o miste.

• Nere: raccolgono solo le acque di scarico di abitazioni e industrie e le convogliano al depuratore.
• Bianche: raccolgono solo le acque meteoriche e le inviano ai corpi idrici ricettori (fiumi, torrenti, canali, suolo); in alcuni casi le acque di prima pioggia vengono mandate al depuratore.
• Miste: raccolgono nello stesso tubo sia le acque nere sia quelle meteoriche.

In Italia la maggior parte delle fognature è mista, anche se le reti nuove sono sempre più spesso separate.

Uno svantaggio delle miste è questo: in tempo asciutto tutta l'acqua va al depuratore, ma quando piove la portata può diventare anche 100 o 1.000 volte quella nera. Portarla tutta al depuratore danneggerebbe il sistema di depurazione e comporterebbe consumi energetici esagerati. Per questo l'acqua in eccesso va "sfiorata", cioè scaricata nel ricettore prima che arrivi all'impianto. Lo fanno gli sfioratori di piena: una soglia, un muretto, oltre il quale l'acqua in eccesso viene scaricata nel corso d'acqua più vicino. Sono una valvola di sicurezza.

Quando può sfiorare? La soglia è fissata da norme tecniche, ma il concetto è semplice: finché la portata (nera più pioggia) è piccola, l'acqua è ancora troppo inquinata e va al depuratore; superata la soglia è abbastanza diluita da portare in ambiente un carico di inquinanti accettabile, e può essere sfiorata.

Ne deriva una regola di buona condotta: uno sfioratore non deve sfiorare quando non piove o piove poco. Per questo si mettono allarmi di livello che segnalano che lo sfioratore è attivo. Ma se piove e la portata supera la soglia, è normale che sfiori: non è un'anomalia del sistema.

Comincio da una scena che chi lavora in un gestore del servizio idrico conosce bene.

Piove. Non tanto, forse. Sul telecontrollo cominciano ad accendersi gli allarmi degli sfioratori: uno, cinque, venti. Un gestore ne monitora migliaia, sparsi su decine di comuni. La domanda che ci si pone è sempre la stessa: questo sfioro è giusto?

Cioè: ha piovuto abbastanza, lì, in quel momento, da giustificarlo? Oppure quello sfioratore si è attivato per un altro motivo, un'ostruzione, un'infiltrazione, un guasto? Il telecontrollo ti dice che sta sfiorando. Non ti dice se è normale.

Questo articolo racconta come ho provato a rispondere a quella domanda con un radar meteo, un po' di idraulica e, come ormai è abitudine, Claude come socio tecnico. La prima parte è per tutti; la seconda, più sotto, è per chi vuole le formule.

Il problema: uno sfioro non è né buono né cattivo

Come abbiamo visto, uno sfioratore può scaricare solo quando la portata in arrivo supera la sua soglia, che è un multiplo della portata nera. Se sfiora prima, qualcosa non va.

Il punto è che un allarme da solo non distingue i due casi. Per farlo servirebbe sapere, sfioratore per sfioratore, quanta acqua sta arrivando. Cioè un misuratore di portata in ogni manufatto. Si puo' fare in certi a costi accettabili in certi casi (stazioni di sollevamento) ma non su tutti i punti.

E allora la domanda diventa un'altra: posso stimare quella portata, in tempo reale, partendo dalla pioggia?

L'idea: il radar come pluviometro diffuso

La Protezione Civile pubblica gratuitamente, ogni 5 minuti, una mappa dell'intensità di pioggia stimata dal radar su tutta Italia, con celle da 1 km per 1 km. È un dato aperto, e quasi nessuno lo usa per la fognatura.

Il ragionamento è semplice::

1. so quanta pioggia cade su ogni comune, ogni 5 minuti (radar);
2. so quanta superficie scarica in fognatura e quanta pioggia se ne perde (tetti e strade da una parte, giardini dall'altra);
3. trasformo la pioggia in portata con un modello semplice, che tiene conto del tempo che l'acqua impiega ad arrivare;
4. aggiungo la nera (gli scarichi di casa, che cambiano con l'ora del giorno);
5. confronto il totale con la soglia di sfioro.

Se la portata stimata è sopra la soglia, uno sfioro in quel momento è regolare. Se è sotto e lo sfioratore scarica lo stesso, vale la pena andare a vedere sul posto cosa sta succedendo.

Una precisazione onesta, subito: nel prototipo la pioggia è vera, i bacini no. Non ho caricato gli sfioratori reali di nessuna rete. Ho costruito un bacino fognario ipotetico ma verosimile per ognuno dei 185 comuni della mia provincia, una specie di "sfioratore equivalente" che rappresenta tutta la rete del comune. Serve a vedere se il metodo sta in piedi, non a dire quanto sfiora davvero un comune in particolare.

Cosa si vede: un giro nell'app

Aprendo la pagina, la prima cosa è una barra colorata che riassume la situazione della provincia in questo istante: verde se è asciutto, blu se piove, arancione se qualche comune è vicino alla soglia, rosso se qualcuno è sopra.

Sotto c'è la tabella dei 185 comuni, ordinata per criticità: in cima chi è sopra soglia, poi la probabilità di sfioro, poi l'intensità di pioggia. Per ogni comune vedo i millimetri caduti negli ultimi 5, 10, 15, 30 e 60 minuti e lo stato dello sfioro.

Poi la mappa. Qui si capisce al volo dove sta piovendo e dove i bacini "vanno in crisi". La vista che preferisco è quella doppia: a sinistra l'immagine del radar, a destra quanto la portata di pioggia si avvicina alla soglia. Si vede il temporale che arriva e, qualche minuto dopo, i comuni che si accendono.

Gli eventi di pioggia importanti vengono archiviati da soli, e si possono rivedere sulla mappa come un filmato, a passi di 5 minuti. L'8 ottobre 2026, per esempio, in poco più di otto ore la pioggia (tarata, vedi più avanti) ha portato 175 comuni su 185 sopra soglia almeno una volta, con un massimo di 151 contemporaneamente. Da leggere con cautela: le soglie sono generiche, non quelle dei manufatti reali, e un evento così esteso le supera quasi ovunque. Il banco di prova vero sono gli eventi deboli, dove la differenza tra «sfioro giustificato» e «sfioro sospetto» diventa significativa.

Infine il cuore del prototipo: il grafico di un singolo comune. Prendo Montebello della Battaglia, collina, circa 1.450 abitanti. In alto, a barre rovesciate, la pioggia ogni 5 minuti; in basso la portata stimata, la fascia di incertezza, la portata nera e la linea rossa della soglia. Dove la curva supera la linea, l'area colorata è il volume oltre la soglia.

I numeri di quella sera: 8,9 mm di pioggia, intensità massima 5,8 mm/h, una soglia di appena 12,6 l/s (la nera media è 2,7 l/s) e un picco stimato di circa 360 l/s. Il bacino è rimasto sopra soglia per 210 minuti, con circa 1.800 m³ oltre la soglia (tra 1.200 e 2.400 con l'incertezza del radar). Tradotto: se quella sera uno sfioratore di Montebello ha scaricato tra le 19:50 e le 23:15, era tutto in regola.

C'è anche una funzione : "Segui la goccia". Accende il grafico un pezzo alla volta, dalla pioggia alla pioggia netta, alla portata, alla soglia, e racconta ogni passaggio. E poi i cursori "E se…": cosa succede se il suolo fosse più impermeabile, se la rete fosse più lenta, se la soglia fosse più alta?

Il radar va tarato: come ho fatto

È risaputo che i dati radar vanno tarati con i pluviometri a terra: il radar misura la pioggia in quota, non quella che arriva al suolo. Il primo passo è stato quindi confrontare il radar con i pluviometri.

Ho una piccola stazione meteo in collina, nell'Oltrepò. Dal 3 al 13 ottobre ha misurato 10,2 mm. Il radar, sulla stessa cella da 1 km, ne dava 65,9. Gli orari della pioggia coincidevano perfettamente; le quantità no.

Ho ripetuto il confronto con i pluviometri di ARPA Lombardia, che sono dati aperti: Pavia 17,4 mm misurati contro 73,6 del radar, Voghera 7,4 contro 55,9, Broni 7,8 contro 43,7. In collina andava meglio (Varzi 11,4 contro 15,5), in pianura peggio.

Il file radar era letto bene, la posizione era giusta (ho provato a spostare la griglia fino a 40 km in ogni direzione: la corrispondenza migliore era senza spostamenti), gli orari pure. Semplicemente, in quei giorni, il radar sovrastimava di un fattore 4 in media, di più con la pioggia debole e in pianura (fino a 8-9 volte), meno in collina (a Varzi 1,4). La mia ipotesi, non dimostrata, è che il fascio sopra la pianura veda la pioggia in quota, una parte della quale evapora prima di arrivare a terra.

Per un sistema che deve dire "sfioro giustificato sì o no" la sovrastima conta: con il radar grezzo ogni sfioro risulta giustificato.

Ho quindi applicato la correzione classica: tarare il radar con i pluviometri. Ogni giorno l'app scarica i dati di 15 pluviometri ARPA della provincia (più la mia stazione), calcola per ogni evento di pioggia il rapporto tra quanto hanno misurato a terra e quanto ha visto il radar sopra di loro, e lo interpola comune per comune. Per l'8 ottobre il fattore va da 0,11 a 0,38: in pratica il radar viene ridotto a un terzo, fino a un nono.

Quindi nell'app "pioggia" vuol dire pioggia tarata. Il radar grezzo si vede solo nella scheda dedicata alla taratura.

Ed è l'occasione per una cosa che mi piace molto: siccome la correzione ha un errore misurabile (lo si vede escludendo un pluviometro alla volta e prevedendolo con gli altri), posso trasformare il semaforo in una probabilità di sfioro. Non più solo "sopra" o "sotto", ma "al 70% sopra soglia".

Va detto che, per ora, 16/10/2026, questa taratura vale poco: si basa su pochi eventi, e per una correzione robusta ne servono di piu' e che tiene conto anche della stagionalità. Tra qualche mese, con più eventi alle spalle, il modello si autotarerà a ogni nuova pioggia, e con più dati si potranno cercare altri parametri che spiegano la sovrastima del radar (stagione, temperatura, tipo di pioggia, distanza dal radar). Il tutto poi sarà validato dopo diversi mesi. Ci sono inoltre altri metodi di taratura che non ho approfondito.

Cosa è reale e cosa no (onesto)

È un prototipo, e voglio essere chiaro su cosa dimostra e cosa no.

Reale:

• la pioggia: radar della Protezione Civile, ogni 5 minuti, ragguagliata sull'area di ogni comune;
• la correzione con i pluviometri ARPA, ricalcolata ogni giorno;
• l'uso del suolo (dalla carta regionale DUSAF) e il tipo di terreno, da cui escono le superfici impermeabili e permeabili;
• la fisica: metodi idrologici classici, da manuale.

Ipotetico:

• i bacini: uno per comune, "sfioratore equivalente" di tutta la rete, con parametri plausibili ma non verificati né tarati ;
• le soglie, calcolate con le regole generali ;
• la taratura del radar è fatta su pochi eventi: per una correzione robusta ne servono molto di piu' per vere un senso statistico maggiore.

Cosa non fa: non legge gli allarmi del telecontrollo, quindi non può dire "questo sfioro è anomalo". Può solo dire "in questo momento uno sfioro sarebbe giustificato".

Il passo successivo è chiaro: calare il metodo su un bacino vero, con la rete nel GIS, le soglie reali e gli allarmi di sfioro accanto. Lì si vedrà se l'idea regge. Raccogliere i dati, tarare e verificare richiede tempo; il prototipo serviva a capire se valeva la pena spenderlo.

Se il metodo regge, un sistema di questo tipo non sostituirebbe i sensori: si affiancherebbe alla rete di misura e al monitoraggio che già esistono. Potrebbe contribuire alla stima della pioggia sul territorio, anche dove non c'è un pluviometro, e ad altro: dire se un allarme è coerente con il meteo, stimare i volumi sfiorati, aiutare a decidere dove mandare per prima una squadra.

Ma la parte che trovo più interessante è un'altra: oggi ce lo si può fare in casa. Esistono tanti dati gratuiti e aperti (radar e pluviometri di Protezione Civile e ARPA, cartografia delle Regioni), disponibili online in tempo reale o quasi. Il lavoro vero è tarare i modelli: richiede tempo, ma non molto, ed è un tempo che serve comunque come formazione specifica per le persone che ci lavorano e che gestiranno le reti.

Qualche anno fa una cosa del genere sarebbe stata un progetto costoso, da affidare a fornitori esterni, con il rischio che a fine lavori in azienda nessuno sapesse più come modificarlo. Qualche anno fa non ci sarebbero nemmeno i dati disponibili. Oggi l'idea può nascere e crescere dentro un gestore del servizio idrico. Non perché l'AI prenda il posto degli informatici, ma perché si possono formare competenze trasversali: ingegneri idraulici con competenze informatiche e di AI, non necessariamente informatici specializzati. Chi conosce l'idraulica sa cosa chiedere e quali numeri hanno senso; gli strumenti di oggi gli permettono di trasformare quella conoscenza in codice. Gli informatici restano indispensabili, per esempio per la sicurezza, le infrastrutture e i sistemi aziendali, e il risultato migliore nasce dalla collaborazione tra le due competenze.

Resta una distinzione: un prototipo non è un servizio. Per portarlo in esercizio servono sicurezza informatica, manutenzione e documentazione. Ma il primo passo, capire se l'idea vale la pena, costa poco.

La mia risposta, per ora, è sì.

👉 Provatelo: radar.danielesturla.it. Se piove, ancora meglio.

Fonti dei dati, tutti aperti: Radar-DPC della Protezione Civile (licenza CC-BY-SA), pluviometri e termometri di ARPA Lombardia, DUSAF 7 e carta pedologica di Regione Lombardia.

Da qui in poi l'appendice tecnica, per chi vuole sapere come funziona sotto il cofano.

Premessa. I parametri e i valori usati nei calcoli che seguono (superfici impermeabili, Curve Number, tempi di corrivazione, dotazioni idriche, coefficienti di punta, soglie di sfioro) sono assunzioni di partenza. Non li ho approfonditi nel dettaglio perché questo è un prototipo, e serve a capire se il metodo sta in piedi. Per calcolare lo sfioro su bacini veri il discorso è diverso: servono il rilievo della rete, le soglie lette sui manufatti, studio dei bacini, misure di portata temporanei per la taratura e parametri verificati caso per caso.

Appendice tecnica 1 — Il dato radar

Prodotto. SRI (Surface Rainfall Intensity) della piattaforma Radar-DPC della Protezione Civile: intensità di pioggia al suolo in mm/h, griglia 1.400 × 1.200 celle da 1 km, un GeoTIFF ogni 5 minuti, pubblicato con circa 10 minuti di ritardo, 14 giorni di storia, licenza CC-BY-SA. Si interroga con due chiamate: findLastProductByType?type=SRI per l'ultimo istante e POST /downloadProduct per l'URL firmato del file.

Pioggia ragguagliata. Per ogni comune uso la media delle celle il cui centro cade dentro il confine comunale (da 2 a 80 celle, mediana 13). Sulla provincia il totale non cambia, ma sul singolo comune sì: l'8 ottobre a Vigevano 15 mm sulla cella centrale contro 32 di media.

SRT1, scartato. Speravo che il prodotto cumulato orario SRT1 fosse più accurato e servisse a correggere l'SRI. Verificato su 240 file orari per 185 comuni: rapporto 0,99, correlazione 0,998. È l'SRI sommato sull'ora, con la stessa sovrastima.

Archivio. SQLite con finestra scorrevole di 10 giorni (circa 2.900 istanti per 185 comuni). Al riavvio l'app recupera solo il buco mancante. Gli eventi di pioggia (almeno 5 comuni bagnati, chiusi da 6 ore asciutte, media provinciale di almeno 1 mm) vengono archiviati e non escono dalla finestra: si tengono gli ultimi 15 più i tre più piovosi e i tre più intensi.

Appendice tecnica 2 — Dalla pioggia alla portata

Ogni comune ha un bacino ipotetico, uno "sfioratore equivalente" che somma tutta la rete. Il calcolo gira a passi di 5 minuti.

1. Superficie servita dal DUSAF. Dalla carta d'uso del suolo DUSAF 7 di Regione Lombardia prendo le classi urbanizzate che scaricano in fognatura (escluse cascine, strade extraurbane, ferrovie, cave, fotovoltaico…) e assegno a ciascuna una quota impermeabile. Il tessuto rado e sparso conta come tutto permeabile: case isolate spesso non allacciate. Il gruppo idrologico del suolo (A–D) viene dalla tessitura della carta pedologica 1:250.000.

2. Pioggia netta, separata per le due parti. Sull'impermeabile perdita iniziale e coefficiente:

Pₑ = 0,9 · (P − 1,5 mm)

dove P_e è la pioggia netta cumulata (mm), cioè quella che finisce davvero in fognatura, P è la pioggia cumulata dell'evento (mm, già tarata), 1,5 mm è la perdita iniziale (bagnatura delle superfici e piccoli invasi) e 0,9 è il coefficiente di deflusso, cioè la quota di pioggia che scorre via.

Sul permeabile SCS-CN con il CN del suolo (49/69/79/84 per i gruppi A/B/C/D):

S = 25400/CN − 254

Pₑ = (P − 0,2S)² / (P − 0,2S + S)

dove CN (Curve Number, adimensionale) descrive quanto il suolo trattiene l'acqua (più è alto, meno ne trattiene), S è la ritenzione massima potenziale del suolo (mm), 0,2·S è la perdita iniziale, P è la pioggia cumulata e P_e la pioggia netta cumulata (mm). La formula vale per P > 0,2·S; altrimenti P_e = 0.

La pioggia cumulata P viene azzerata dopo 6 ore asciutte; la pioggia netta di ogni passo di 5 minuti è l'incremento di P_e. Valori radar sotto 0,2 mm/h sono rumore e valgono zero. La netta del bacino è la media delle due, pesata con le aree..

3. Trasformazione in portata: metodo cinematico. Filtro a 3 punti sulla netta, poi media mobile sugli ultimi tc minuti (convoluzione con un idrogramma unitario rettangolare):

Qₘₑₜ(t) = A · 1000/3,6 · media della pioggia netta su [t − tc, t] [l/s]

dove Q_met è la portata meteorica (l/s), A la superficie servita (km²), ī_netta l'intensità di pioggia netta (mm/h) mediata sugli ultimi t_c minuti, t_c il tempo di corrivazione, cioè il tempo che l'acqua impiega ad arrivare alla sezione di chiusura dal punto più lontano del bacino, e 1000/3,6 il fattore che converte km²·mm/h in l/s. Il tempo di corrivazione è 10 minuti di accesso alla rete più il tempo per percorrere la lunghezza L = 1,155√A (L in km, A in km²) alla velocità di 1,2 m/s in pianura, 2 in collina, 2,5 in montagna: da 14 a 76 minuti, mediana 22.

In alternativa, solo nel grafico, il metodo dell'invaso (serbatoio lineare, Q(t) = Q(t−1)·e^(−5/K) + A·i·(1 − e^(−5/K))) dove K è la costante di invaso (minuti), 5 il passo di calcolo (minuti) e A·i la portata in ingresso, cioè la superficie per l'intensità di pioggia netta, con K ricavato da un "tubo equivalente" dimensionato sulla pioggia di progetto con tempo di ritorno a 10 anni. Si ottengono picchi più bassi e più lunghi, volumi quasi uguali.

4. Portata nera. Media (l/s) = 0,8 × abitanti × dotazione / 86.400, dove 0,8 è la quota della dotazione idrica che finisce in fognatura, la dotazione è in litri per abitante al giorno e 86.400 è il numero di secondi in un giorno, con un andamento orario tipo . Punta con il coefficiente di Harmon 1 + 14/(4 + √P), minimo notturno con Gifft 0,2·P^(1/6) (qui P è la popolazione servita, in migliaia di abitanti; entrambi i coefficienti moltiplicano la portata media).

5. Soglia e stato. La soglia di sfioro è il massimo tra 3 volte la nera media e 750 l/ab/giorno. L'incertezza del radar (±50% a 5 minuti, ±15% a 60, interpolata sul tc) dà una fascia di portata, tra un valore minimo Q_min e uno massimo Q_max, sulla sola parte meteorica. Quattro stati: sopra soglia (anche Q_min la supera), vicino alla soglia (la soglia è dentro la fascia), appena rientrata (sotto, ma sopra nell'ultima ora), sotto soglia. Il volume oltre la soglia è Σ max(0, Q − Q_soglia) × 300 s, dove Q è la portata stimata a ogni passo (nera più pioggia), Q_soglia la soglia di sfioro, 300 s la durata del passo e la somma è estesa a tutti i passi dell'evento.

Appendice tecnica 3 — Taratura con i pluviometri e probabilità

Dati a terra. 15 pluviometri ARPA Lombardia della provincia (dataset aperti su dati.lombardia.it, valori a 10 minuti) più la mia stazione Ecowitt (5 minuti). Lo scarico avviene una volta al giorno, per non pesare sul servizio ARPA.

Fattore per evento. Per ogni evento, allargato di un'ora prima e dopo, confronto i totali dei pluviometri con il radar nella loro cella:

f = Σ pluviometri / Σ radar nelle stesse celle, 0,05 ≤ f ≤ 2

dove f è il fattore di correzione (adimensionale): per esempio f = 0,2 significa che a terra è caduto un quinto di quanto indicato dal radar. Il valore viene limitato tra 0,05 e 2.

Servono almeno 3 pluviometri. Valori ottenuti: 0,16 il 5 ottobre, 0,48 il 7, 0,22 l'8. Fuori dagli eventi vale il fattore degli ultimi 10 eventi.

Interpolazione per comune. Il fattore non è uniforme (in pianura il radar sbaglia di più), quindi lo calcolo nel centro di ogni comune pesando i pluviometri con la distanza:

f(x) = Σ wₖ·Gₖ / Σ wₖ·Rₖ, wₖ = 1 / (dₖ² + (8 km)²)

dove f(x) è il fattore di correzione nel punto x (il centro del comune), G_k è il totale misurato dal pluviometro k, R_k il totale del radar nella cella sopra quel pluviometro, w_k il peso del pluviometro k e d_k la sua distanza da x. Il termine di 8 km evita che un pluviometro vicinissimo comandi da solo. L'8 ottobre il fattore va da 0,11 a 0,38 (Pavia 0,22, Voghera 0,15, Vigevano 0,29, Montebello 0,17).

Probabilità di sfioro. Valido la correzione "lasciandone fuori uno": ogni pluviometro viene previsto con il fattore interpolato dagli altri. La dispersione dello scarto in logaritmo è σ = 0,65 su 32 confronti (un fattore ×/÷ 1,9). Allora:

p_sfioro = Φ( ln( Q_pioggia / (Q_soglia − Q_nera) ) / σ )

Qui Φ è la funzione di ripartizione della distribuzione normale standard, Q_pioggia la portata meteorica stimata, Q_soglia − Q_nera il margine disponibile prima dello sfioro (soglia meno portata nera) e σ la dispersione dell'errore della correzione, in logaritmo naturale. Se la portata di pioggia è esattamente pari al margine prima dello sfioro, la probabilità è 50%; al doppio del margine sale all'86%.

Cosa manca. Tre eventi (al 16/10/2026) non bastano. Registro già temperatura e giorno dell'anno per provare, con qualche mese di eventi, una regressione del fattore per capire se la sovrastima cambia con la stagione e la temperatura.

Appendice tecnica 4 — Architettura e come l'ho costruita

Stack.

• Backend: Python, Flask, rasterio per i GeoTIFF, SQLite; un thread in background scarica il radar ogni 5 minuti, ricalcola eventi e taratura.
• Frontend: una sola pagina HTML con JavaScript puro, Leaflet per le mappe, Chart.js per i grafici.
• Infrastruttura: un container Docker su un VPS, dietro Caddy come reverse proxy con HTTPS automatico.
• Dati: Radar-DPC (Protezione Civile), pluviometri e termometri ARPA Lombardia, DUSAF 7 e carta pedologica di Regione Lombardia, confini comunali openpolis, LSPP di ARPA per la pioggia di progetto. Tutti aperti.

Tutto sta in due file: app.py e index.html. Nessun framework, nessun database server, nessun costo oltre al VPS.

Come l'ho fatto. Come negli altri progetti, Claude ha scritto il codice e io ho fatto l'ingegnere idraulico. Il prototipo è nato in una quindicina di ore, spalmate su un paio di settimana alla sera dopo cena, a volte con una birra in mano. Non lo dico per vantarmi: lo dico perché è proprio questo il punto. Qualche anno fa una cosa del genere avrebbe richiesto settimane e un programmatore. Oggi basta sapere bene cosa si vuole calcolare, e un po' di pazienza.

Una parola su Claude Code. È fantastico, e nel giro di pochi mesi è diventato sempre più potente: nella programmazione fa passi avanti continui ed è preciso, e nel mio uso non ho riscontrato allucinazioni. Per questo progetto ho usato un modello di fascia media, Sonnet 5.5, non il più potente disponibile, e costa sempre meno (senza esaurire token). Il controllo che i numeri abbiano senso dal punto di vista idraulico resta comunque compito mio.