PostgreSQL 19: l’AI trova i bug, la review paga il conto

C’è una promessa ricorrente attorno agli strumenti di intelligenza artificiale per programmare: fare più cose nello stesso tempo. Più codice, più test, più analisi. E, almeno in parte, funziona. Il problema arriva quando una fase della catena accelera e tutte le altre restano esattamente dove erano. Non hai automaticamente un sistema più veloce. Potresti avere soltanto una coda più lunga.

La vicenda di PostgreSQL 19 è interessante proprio per questo. Non racconta di un database improvvisamente diventato inaffidabile, né di un modello che ha mandato in crisi un progetto open source. Racconta di un’organizzazione tecnica che deve prendere decisioni su difetti reali, codice storico, patch e scadenze mentre il costo di scoprire problemi si è abbassato molto più rapidamente del costo di risolverli.

Una release rinviata per non scaricare il rischio sugli utenti

Il PostgreSQL Global Development Group ha annunciato il 15 ottobre 2026 la prima release candidate di PostgreSQL 19. Nello stesso comunicato ha indicato una seconda candidate per il 12 novembre e la disponibilità generale pianificata per il 19 novembre, salvo ulteriori problemi. La decisione ufficiale è stata motivata dal volume delle correzioni da integrare, comprese quelle destinate ai rami già supportati. Alla data di questo articolo, la release definitiva è ancora prevista, non già pubblicata.

Il 30 ottobre Robert Haas, committer e contributore storico di PostgreSQL, ha proposto una spiegazione più specifica nel suo intervento sul ritardo di PostgreSQL 19: gli LLM stanno rendendo molto più facile individuare bug in una base di codice ampia e matura, ma la capacità dei maintainer di valutarli, correggerli e portarli sui rami appropriati non cresce allo stesso ritmo. È la lettura di un protagonista del progetto, non una dimostrazione statistica che l’AI sia l’unica causa del rinvio.

Nella fase beta sono inoltre state ritirate tre funzionalità rilevanti: UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries e MERGE/SPLIT PARTITION. Un revert così tardo è una scelta costosa, ma può essere la scelta più responsabile quando il comportamento di una funzione non è ancora sufficientemente stabile. La release non si misura dal numero di feature che riesci a tenere dentro a ogni costo.

I commit aumentano. Non significa che il software sia peggiorato

Haas porta numeri precisi. Tra l’8 aprile e il 25 settembre 2025 conta 724 commit sul ramo REL_18_STABLE; nella finestra equivalente del 2026, sul ramo REL_19_STABLE, ne conta 1.169. L’incremento è di circa il 61,5%. Su un ramo stabile precedente il confronto passa da 248 a 433 commit, circa il 74,6% in più. Sono segnali di un lavoro di manutenzione cresciuto in modo importante.

Ma qui serve una distinzione che spesso scompare nelle discussioni sull’AI. Un commit non equivale a un bug distinto. Una correzione può richiedere più commit, un singolo cambiamento può sistemare più casi, e i criteri di backport possono variare. Quei numeri documentano attività sul repository, non misurano direttamente il numero di difetti, la gravità media o il livello complessivo di qualità del database.

Sarebbe altrettanto sbagliato leggere più segnalazioni come prova che nel 2026 gli sviluppatori abbiano scritto codice peggiore. Potrebbe semplicemente essere cambiata la capacità di vedere problemi che prima rimanevano nascosti. Haas considera questa spiegazione plausibile; la storia tecnica del progetto e la sua esperienza rendono l’ipotesi importante, ma non cancellano la necessità di distinguere correlazione e causa.

La conseguenza pratica è meno spettacolare di uno slogan e molto più utile: quando cambi lo strumento di misura, devi stare attento a non scambiare il nuovo numero per un peggioramento dell’oggetto misurato. Vale per il bug tracker, per i test, per i log di produzione e per quasi tutte le dashboard con cui decidiamo se un sistema sta bene.

Scoprire un bug è un evento. Accettare una patch è una responsabilità

Un modello può esplorare migliaia di percorsi, formulare ipotesi, proporre test e produrre patch in pochi minuti. Il maintainer deve invece capire se il comportamento segnalato sia davvero un difetto, se il test sia corretto, se la correzione rompa altri casi, se sia compatibile con il ramo stabile e se introduca rischi peggiori del problema originale.

Nel software infrastrutturale queste domande non sono burocrazia. Una modifica al motore di un database può interagire con concorrenza, recovery, planner, formati persistenti e compatibilità fra versioni. Un test verde in un caso specifico non prova che la modifica sia sicura in tutti gli altri. E un backport, per definizione, deve convivere con vincoli che il ramo principale potrebbe non avere.

C’è poi un costo che i grafici dei token generati non mostrano: il contesto mentale. Per revisionare una patch devi ricostruire l’intenzione del codice, capire quali invarianti protegge e confrontare la modifica con anni di decisioni tecniche. Se arrivano dieci segnalazioni in più, non puoi semplicemente chiedere a chi revisiona di leggere dieci volte più velocemente.

Per questo l’articolo che avevo dedicato agli agenti che trovano bug e devono produrre test eseguibili resta un pezzo del problema, non la soluzione completa. La riproducibilità alza la qualità dell’ingresso nella pipeline. Non elimina il lavoro necessario a decidere cosa fare di quella prova.

Il debito di verifica non compare nel conto dei token

Se la capacità di scoprire difetti cresce più velocemente della capacità di chiuderli, nasce un debito di verifica. Non è il classico debito tecnico accumulato scrivendo male una funzione. È una massa di segnalazioni potenzialmente corrette che qualcuno deve ancora classificare, riprodurre, prioritizzare, correggere e testare.

La coda può diventare pericolosa in due direzioni opposte. Se tratti ogni segnalazione come urgente, blocchi il lavoro sulle nuove funzionalità e consumi la capacità di review. Se la ignori perché arriva da un modello, rischi di lasciare aperti difetti reali. Il criterio non può essere chi ha trovato il bug: deve essere la qualità dell’evidenza e il rischio concreto del difetto.

La velocità con cui un sistema produce lavoro non è la velocità con cui un’organizzazione riesce ad assumersene la responsabilità.

È un principio che vale anche fuori da PostgreSQL. In una web app con pochi sviluppatori, in un e-commerce o in un sistema di integrazione, un agente che apre cinquanta pull request non ha automaticamente aumentato la produttività. Se chi conosce il dominio passa la giornata a validarle, hai spostato il lavoro e forse lo hai reso meno visibile.

Il processo deve cambiare prima del numero di agenti

Non serve tornare a cercare ogni bug a mano. Sarebbe una reazione difensiva e poco sensata. Serve progettare una pipeline che tenga conto di due risorse differenti: la capacità automatica di generare evidenze e la capacità umana di prendere decisioni affidabili.

Tre filtri prima della review costosa

• Riproducibilità: una segnalazione deve includere versione, condizioni, comportamento atteso e osservato, test minimo e risultato verificabile. Le ipotesi non dimostrate restano ipotesi.
• Impatto e priorità: separare corruzione dei dati, sicurezza e regressioni importanti da edge case con impatto limitato. Il volume non deve decidere da solo l’ordine della coda.
• Compatibilità e ownership: indicare rami coinvolti, rischi del backport, test di regressione e responsabile della decisione. Una patch proposta da un LLM non è una patch approvata.

Questi filtri non sostituiscono la review: le restituiscono tempo. L’automazione può eliminare duplicati, riprodurre casi in ambienti isolati, preparare test e raccogliere evidenze. Il giudizio finale sulle modifiche che entrano in una release resta esplicito, tracciabile e attribuito.

E vale la pena misurare le cose giuste: tempo medio dalla segnalazione alla riproduzione, percentuale di falsi positivi, tempo di review per classe di rischio, regressioni introdotte dalle correzioni, backlog per severità e tempo sottratto alle attività pianificate. Non sono numeri perfetti, ma descrivono meglio il costo del sistema rispetto al conteggio di patch generate.

La stessa logica si ritrova nella progettazione delle code e delle operazioni idempotenti. Nel caso di Symfony Messenger Inbox, per esempio, il punto non è soltanto far correre un worker: è stabilire cosa succede quando un’operazione viene ripetuta, quando si interrompe e chi garantisce che lo stato finale sia corretto. Con l’AI cambia il volume degli input, non sparisce la necessità di governare gli effetti.

La lezione di PostgreSQL 19 non è contro l’AI

La posizione di Haas contiene anche una prospettiva positiva: scoprire oggi difetti che per anni sono rimasti invisibili è un’opportunità per migliorare un software già molto maturo. Il fatto che un progetto preferisca rimandare una release, invece di dichiarare risolto un problema che non ha ancora compreso, è una forma di disciplina ingegneristica.

Ma questa opportunità ha un prezzo organizzativo. La disponibilità di strumenti più potenti non aumenta magicamente le ore di chi mantiene il codice. Può perfino rendere più evidente il limite del processo che usiamo da anni. Quando la discovery diventa abbondante, la risorsa scarsa diventa la verifica: la competenza necessaria a dire sì, no o non ancora.

Per chi sviluppa software la domanda utile, quindi, non è quanti bug un agente riesca a trovare in una notte. È quanti di quei bug riusciamo a trasformare in correzioni affidabili senza distruggere la capacità di continuare a progettare. PostgreSQL 19 rende visibile un problema che molti team più piccoli incontreranno con strumenti diversi e senza un comunicato ufficiale a raccontarlo.

L’AI può accelerare l’ingresso del lavoro. Se non progettiamo anche l’uscita, abbiamo costruito una macchina molto efficiente per produrre code.