Platea di sviluppatori a PyCon Italia 2026, con lo speaker al podio e la slide di apertura sullo schermo.

PyCon Italia 2026: i trend e le novità che abbiamo intercettato

Siamo sponsor di PyCon Italia dal 2015, a supporto di una delle community in cui ci sentiamo più a casa. Quest'anno eravamo presenti come bronze sponsor, come speaker e come parte della crew organizzativa che ha lavorato alla realizzazione dell'evento.

PyCon Italia è ogni anno un'esperienza totalizzante: un'occasione per imparare, contribuire e accogliere alcuni tra gli aggiornamenti più interessanti dal mondo Python. In questo articolo condividiamo i quattro trend e insight che hanno suscitato più discussione in Nephila.

1. Dallo stupore alla riflessione matura: l'AI diventa un problema di ingegneria

Quest'anno la conversazione sull'AI si è spostata su un piano più maturo. L'intelligenza artificiale viene trattata sempre meno come magia e sempre più come uno strumento che richiede testing, osservabilità e buona architettura. Diversi talk hanno reso concreto questo passaggio, ciascuno da un'angolazione diversa.

Giunio De Luca ha mostrato come costruire un sistema RAG applicando l'architettura esagonale, per isolare la logica di business dai singoli provider AI: la frase con cui ha riassunto il talk, "RAG is the new CRUD", segnala che questo pattern sta diventando lo standard, non più un caso particolare. Sullo stesso fronte, Pythia (presentato da Riboni e Paladini) porta al prompt engineering pratiche che l'ingegneria del software usa da anni: versioning, testing automatico, CI/CD, un registry centralizzato e cost tracking per team e progetto. Il talk di Silvano Cerza, "AI Frameworks Are Making You Worse", arriva da una direzione quasi opposta ma converge sulla stessa idea: molti framework introducono astrazioni opache che complicano il debugging, mentre quasi ogni pattern "avanzato" si riduce in realtà a poche righe di Python semplice.

C'è anche una componente di responsabilità in questa maturazione. Nel talk "Don't do anything (A)I wouldn't do", Luca Corbucci ha ricordato come l'AI non risponda delle conseguenze pratiche dei task che esegue, un tema che tocca allucinazioni, sicurezza ed autonomia degli agenti. 

Ecco perché vale la pena parlarne: non ragioniamo più su "cosa può fare l'AI", ma su "come si progetta un sistema AI che si possa mantenere, testare e correggere nel tempo". È un cambiamento di prospettiva che stiamo attraversando anche noi: stiamo strutturando un flusso di lavoro interno in cui l'AI è uno strumento integrato nel processo di sviluppo software, con ruoli e limiti definiti, non una scorciatoia da applicare caso per caso.

2. Meno modelli giganti, più modelli piccoli e specializzati

l tema è emerso in modo indipendente da almeno quattro prospettive diverse, il che lo rende uno dei segnali più solidi raccolti quest'anno. Stefano segnala tra i trend l'uso di piccoli LLM locali e open per compiti specifici, insieme al fine tuning di modelli di dimensioni ridotte. Il keynote di Merve Noyan (Hugging Face) va nella stessa direzione con un messaggio esplicito: il futuro dell'AI sarà sempre più multimodale, locale e costruito su modelli open source specializzati, anziché su un singolo modello generalista ad ampia copertura, come invece riporta Sergey.

Andrea osserva un aspetto complementare: nota "un interesse maggiore ai modelli AI più piccoli in locale", accompagnato però da "una qualche disillusione riguardo l'AI" più in generale. Emanuela allarga il quadro parlando di una maturazione dell'intero settore: le applicazioni più immediate del generativo sono ormai presidiate da molta ricerca, e la community si sta spostando verso ambiti più specialistici e "deep tech", con meno interesse per le dimostrazioni generiche.

Un caso pratico che rende tangibile questo spostamento, segnalato da Sergey, è il talk di Maxim Danilov su agenti locali offline, capaci di funzionare senza cloud integrando STT, TTS, OCR e modelli open source: privacy e controllo dei dati migliorano, ma restano limiti tecnici e di licensing per un'adozione su larga scala. 

Vale la pena discuterne perché il trend racconta più di una moda tecnica: segnala che la community sta iniziando a valutare i modelli AI in base a costo, controllo e adattamento al contesto, non solo alla loro potenza generale. È una logica che chi lavora con una filosofia open source riconosce bene, ed è quella che stiamo applicando anche internamente: preferire strumenti su cui si ha controllo reale, costruire competenza invece di acquistare dipendenza, scegliere il modello giusto per il compito invece di affidarsi a un unico fornitore che fa tutto.

3. Django introduce i GeneratedField: meno codice per gestire dati calcolati

Tra i quattro trend, questo è quello con il riscontro tecnico più preciso e circostanziato. Il talk di Paolo Melchiorre ha spiegato come i GeneratedField permettano di calcolare colonne direttamente a livello di database, a partire da altri campi del modello, in modo trasparente e automatico. Prima della loro introduzione, ottenere lo stesso risultato richiedeva segnali, hook o l'override del metodo save(), con tutte le complicazioni di manutenzione che questi approcci comportavano nel tempo.

Sergey riporta alcuni dettagli tecnici utili: l'espressione che definisce il campo generato, il tipo dichiarato tramite output_field, e il parametro db_persist=False, che evita di ricalcolare il valore a ogni scrittura quando le letture sono occasionali. Leonardo aggiunge un caso concreto dal punto di vista di chi lavora già con Django in azienda: i GeneratedField "avrebbero fatto comodissimo" sul progetto di un cliente, anche se resta da capire come si comporta l'aggiornamento del campo dopo un save. Lo stesso Leonardo lo inserisce tra le cose da testare nel prossimo periodo.

Questa è una novità che semplifica un problema molto comune: gestire dati derivati da altri campi spostando la logica dal codice applicativo al database, riducendo superficie di bug.

4. Con l'AI che scrive codice, il TDD cambia ruolo (o forse sparisce)

Il talk di Lorenzo Spinelli, "TDD in the AI era", è stato raccontato da due prospettive diverse che in parte convergono.

Iacopo lo interpreta come uno spostamento di responsabilità: il TDD aiuta a evitare bug "creativi" generati dall'AI e permette allo sviluppatore di guidare l'agente invece di subirne le scelte. Il valore professionale si sposta verso la capacità di definire vincoli chiari e verificabili, mentre la scrittura materiale del codice viene delegata. Sergey riporta invece l'insight in termini più netti: il TDD non servirebbe più in senso tradizionale, oggi conta di più definire con chiarezza il comportamento atteso, aggiungere controlli di sicurezza (guardrail), lasciare che sia l'AI a generare il codice e concentrarsi sulla revisione.

Le due letture spostano l'attenzione dalla scrittura del codice alla definizione del comportamento atteso. Cambia però il peso che danno alla pratica del testing in sé, da strumento ancora centrale (Iacopo) a pratica quasi superata da un nuovo modo di lavorare (Sergey). È proprio questa tensione, irrisolta anche all'interno della stessa conferenza, a rendere il tema utile da segnalare: il ruolo dello sviluppatore nell'era dell'AI è ancora in discussione, non c'è consenso su come cambierà.

Tool da provare

django-tasks / django-tasks-db. Il backport ufficiale del framework per i background tasks che arriverà nel core di Django 6.0, già utilizzabile su Django 5.2 LTS. Per chi gestisce task asincroni con Celery o soluzioni simili, vale la pena capire come si posiziona questa alternativa nativa prima che diventi lo standard. Se vuoi approfondire, Juliana, backend developer del nostro team, ha tenuto un talk a PyCon sul tema.

GeneratedField (Django 5.0+). Se il terzo trend ti ha incuriosito, la documentazione ufficiale, aggiornata fino a Django 6.0, è il punto di partenza più diretto per un test sul proprio progetto.

Playwright. Test E2E per Django con auto-waiting, isolamento dei test e un inspector integrato che semplifica il debugging. Leonardo, full stack developer e tech lead del nostro team, ne ha parlato a PyCon: il repository di riferimento del talk è disponibile per chi vuole partire da un esempio concreto.

connexion. Routing e mocking di API a partire da una specifica OpenAPI, con un approccio contract-first. Per chi vuole esplorarlo in modo guidato, connexion-101 è un corso pratico open source pensato esattamente per questo.

just / justfile. Un'alternativa ai Makefile per la gestione dei task di progetto: sintassi più leggibile, meno sorprese. Per chi già usa Makefile come collante operativo nei propri repository, il confronto vale qualche ora.

***

Questo articolo nasce dai contributi raccolti con il nostro team: Iacopo Spalletti, Emanuela Dal Mas, Leonardo Cavallucci, Stefano Ravagnan, Sergey Fedoruk, Mark Caglienzi, Juliana Nicacio, Paola Bianconi, Andrea Bravetti.