Postgres 19 è in ritardo e uno dei suoi sviluppatori dà la colpa ai bug trovati dall’AI. Negli stessi mesi del 2025 e del 2026 le vulnerabilità corrette passano da 4 a 39, e per 9 il merito va a un’AI

Nel marzo 2023 un’azienda che fa i backup del proprio database PostgreSQL da una replica scrive alla lista dei bug del progetto: alcuni backup non si riescono a ripristinare, perché manca una riga a cui un’altra tabella fa riferimento. Peter Geoghegan, uno degli sviluppatori del database, risponde il giorno stesso che gli erano arrivate segnalazioni interne di sintomi simili in altre installazioni e che non era mai venuto a capo del problema, pur avendoci dedicato del tempo («never got to the bottom of the problem despite spending some time on it»). La correzione arriva il 26 agosto 2026, con Geoghegan come primo autore. Il messaggio del commit dice: «Claude Code diagnosed this problem», cioè la diagnosi l’ha fatta Claude Code. Anche il test che accompagna la correzione è una versione semplificata di quello che il modello aveva scritto per dimostrare il bug. La causa era una svista in una modifica del 2017, e la correzione è stata riportata su tutte le versioni ancora supportate, fino a PostgreSQL 14.

Sono episodi come questo che Robert Haas, committer di PostgreSQL che lavora per Databricks, ha in mente in «Postgres 19 is late, and it’s AI’s fault», pubblicato sul blog di Neon il 21 ottobre e ripreso sul suo blog il 30 ottobre. Da dieci anni, scrive, le versioni principali escono tra metà settembre e metà ottobre; la 19 con ogni probabilità non arriverà prima di novembre. Tre funzioni importanti ne sono state tolte tra il 27 agosto e il 15 settembre. Il 10 ottobre il gruppo che cura i rilasci ha spostato l’uscita definitiva al 19 novembre, dopo una seconda versione candidata il 12 novembre, «given the volume of fixes that have been added to the back branches», cioè per la quantità di correzioni finite nei rami delle versioni precedenti.

La prova di Haas è un conteggio. Tra il blocco delle nuove funzioni, l’8 aprile, e il 25 settembre, il ramo di manutenzione della versione precedente ha ricevuto 248 commit nel 2025 e 433 nel 2026: secondo lui un aumento di oltre il 74%. La sua spiegazione è che «a huge number of people on the Internet» ora segnala bug di PostgreSQL trovati con i modelli linguistici. I committer, pensa, non sono stati più sbadati del solito, ma «it seems likely», gli sembra probabile, che un numero molto maggiore dei loro errori sia stato scovato in fretta dai modelli. Anche correggere è diventato più facile, aggiunge, ma non nella stessa misura. E a preoccuparlo è il lungo periodo: se abbiamo quarant’anni di bug che gli esseri umani non sono riusciti a trovare e che i modelli sono ben in grado di scoprire, «how are we ever going to catch up», come faremo mai a rimetterci in pari?

Abbiamo rifatto il conteggio sulla cronologia pubblica del progetto, usando le date dei commit nello stesso intervallo. Il ramo della versione precedente passa da 249 commit nel 2025 a 436 nel 2026, il 75% in più, con uno scarto massimo di tre commit rispetto ai numeri di Haas. La crescita si vede anche sul ramo di PostgreSQL 14, uscito nel 2021: da 145 a 244. I commit che riconoscono a qualcuno il merito di aver segnalato il problema passano da 92 a 191, e i nomi diversi citati in quei riconoscimenti da 82 a 141. Il salto più netto riguarda la sicurezza: sul ramo della versione precedente, i commit contrassegnati con un identificativo ufficiale di vulnerabilità riguardavano 4 vulnerabilità nell’intervallo del 2025 e 39 in quello del 2026. Le 39 sono esattamente quelle corrette negli aggiornamenti di maggio e di agosto; secondo l’annuncio del progetto, quello di agosto da solo ha corretto 28 vulnerabilità e oltre 110 bug. La pagina sulla sicurezza del progetto elenca 7 vulnerabilità con identificativo del 2025 e, finora, 44 con identificativo del 2026.

Su che cosa abbia fatto l’AI, invece, la cronologia dice meno. Nell’intervallo del 2025 nessun commit di questi rami nomina un modello, un’azienda o uno strumento di AI, almeno a giudicare dai termini che abbiamo cercato. Nel 2026 lo fanno 16 dei 436 commit sul ramo della versione 18. Quindici attribuiscono a un modello o a un laboratorio di AI il merito di aver trovato, diagnosticato o analizzato un problema: quattro volte «Reported-by: Claude Code (via Noah Misch)», poi le due note secondo cui Claude Code ha trovato o diagnosticato il problema, tre segnalazioni di «Ben Morris in collaboration with Claude and Anthropic Research», tre di «Amy Burnett (OpenAI Codex Security)», una correzione firmata dall’«OpenAI Security Research Team», un’analisi fatta da uno sviluppatore «using claude» e una segnalazione di Calif.io «in collaboration with Claude and Anthropic». Il sedicesimo dice che le prime bozze della patch sono state scritte con Claude Opus 4.8: un aiuto nella scrittura, non nella ricerca del bug.

Altri tredici commit citano «Xint Code» senza aggiungere altro. Chi lo ha sviluppato lo descrive come «a fully autonomous AI-powered security analysis tool», uno strumento di analisi della sicurezza basato sull’AI e del tutto autonomo; a febbraio il progetto aveva già corretto un overflow di buffer nello heap che lo strumento aveva trovato in un’estensione per la crittografia, in una parte di codice aggiunta nel 2005. Contando anche Xint Code, 28 correzioni su 436, circa una su sedici, attribuiscono a un’AI la scoperta o l’analisi del problema. Se si contano le vulnerabilità, 9 su 39 hanno almeno una correzione che lo fa. Gli altri riconoscimenti nominano persone e aziende e tacciono sul metodo: una vulnerabilità di agosto, un overflow nella funzione di formattazione to_char, porta nelle sue correzioni i nomi di undici segnalatori diversi, tra cui Codex Security di OpenAI.

La cronologia conferma dunque la parte del racconto di Haas che si può contare: in un anno correzioni, segnalatori e soprattutto vulnerabilità sono aumentati di colpo, e nello stesso anno sono comparsi i primi riconoscimenti espliciti a un’AI. Se la maggior parte delle nuove segnalazioni venga dai modelli linguistici, come crede lui, i commit non lo possono dimostrare. Le righe di riconoscimento sono facoltative e non esiste un campo che registri come è stato trovato un bug; diversi segnalatori lavorano per aziende di sicurezza che vendono strumenti basati sull’AI, ma i commit non lo dicono e noi non li abbiamo contati. Haas non indica con precisione come ha delimitato le date, perciò i nostri numeri si discostano dai suoi di tre commit al massimo, e non abbiamo ricontato le sue cifre per il ramo della versione 19. I commit non sono bug: i rami di manutenzione ricevono anche modifiche alla documentazione, ai test e alle note di rilascio. La nostra ricerca delle menzioni dell’AI si basa su nomi e parole chiave e può non cogliere le formulazioni indirette; Xint Code è contato come AI solo in base a come lo descrive chi l’ha sviluppato. La data del 19 novembre è un’uscita prevista, non un rilascio avvenuto.