PostgreSQL 19 kann nicht veröffentlicht werden? Die KI ist so schnell darin, Fehler aufzuspüren, dass die Menschen mit der Behebung von Bugs nicht mehr Schritt halten können.
Kürzlich hat die Veröffentlichung von PostgreSQL 19 eine seltene Verzögerung erlebt. Das PostgreSQL-Team hat angekündigt, dass die ursprünglich für den 29. Oktober geplante offizielle Veröffentlichung von PostgreSQL 19 auf den 19. November verschoben wird. Davor wird das Projekt zusätzlich eine weitere RC2-Kandidatenversion hinzufügen, die am 12. November veröffentlicht wird. Der offizielle Grund dafür ist, dass in letzter Zeit viele Korrekturen zu allen Wartungszweigen hinzugefügt wurden. Das Team möchte diese Korrekturen zuerst von der Community über RC2 validieren lassen, bevor die offizielle Veröffentlichung erfolgt.
Gleichzeitig wurden nach Beginn der Beta-Phase etwa 8 bis 10 wichtige Funktionen aus PostgreSQL 19 zurückgezogen, wobei einige Funktionen erst in einem sehr späten Stadium entfernt wurden. Normalerweise ist es bei einem großen PostgreSQL-Versionszyklus nicht ungewöhnlich, dass eine wichtige Funktion zurückgerollt wird, aber das Zurückziehen von fast 10 Funktionen auf einmal liegt deutlich außerhalb der üblichen Praxis.
Peter Eisentraut, Kern-Committer von PostgreSQL und Vizepräsident von EDB, hat anschließend einen speziellen Artikel verfasst, um diese Anomalie zu erläutern. Einer der Schlüsselfaktoren ist genau die rasch ausgereifte KI-gestützte Code-Prüfung und Fuzz-Testing durch große Sprachmodelle.
KI hat Probleme, die sonst erst in 5 Jahren entdeckt worden wären, vorzeitig aufgedeckt
Peter Eisentraut widerlegt eine naheliegende Vermutung: Diese Probleme sind größtenteils nicht durch Vibe-Coding entstanden.
Er erläutert, dass die meisten betroffenen und letztendlich zurückgezogenen Funktionen bereits fertiggestellt wurden, bevor die LLM-gestützte Programmierung und Code-Prüfung ausgereift waren. Das heißt, die Entwickler haben nicht massiv minderwertigen PostgreSQL-Code von Modellen wie Claude und Codex generieren lassen, der dann in der Beta-Phase massiv Probleme verursacht hat. Im Gegenteil: Die immer leistungsfähigeren KI-Prüfwerkzeuge begannen, den zuvor nach traditionellen Verfahren entwickelten Code erneut zu prüfen.
Peter teilt die entdeckten Probleme grob in zwei Kategorien ein. Die erste Kategorie ist tatsächlich relativ schwerwiegend: Einige zurückgezogene Funktionen weisen Mängel auf Architekturebene auf, die in der kurzen Beta-Phase kaum vollständig behoben werden können. Daneben gibt es aber auch eine Reihe von langfristigen Randproblemen: Viele einzeln betrachtet nicht schwerwiegende Probleme, die nur unter bestimmten Randbedingungen ausgelöst werden.
Früher wären solche Probleme möglicherweise vor der Veröffentlichung nicht entdeckt worden. PostgreSQL würde normalerweise veröffentlicht, und in den folgenden Jahren würden die Probleme nach und nach durch Patches behoben, wenn echte Benutzer auf verschiedene seltene Kombinationen stoßen. Peter schätzt, dass viele dieser Probleme sonst erst in den nächsten 5 Jahren nach und nach aufgetaucht wären.
LLMs haben diesen Prozess verändert. Mit Hilfe der KI-gestützten Code-Prüfung können Randmängel, die früher über mehrere Jahre verteilt auftraten, jetzt innerhalb weniger Tage oder Wochen gebündelt aufgedeckt werden.
Peter führt als Beispiel an, dass Entwickler plötzlich mit etwa 40 Fehlerberichten konfrontiert werden. Selbst wenn für jedes Problem durchschnittlich nur 3 Codezeilen geändert werden müssen, erfordert die Bearbeitung jedes Problems einen festen Aufwand. Der Code selbst lässt sich vielleicht in wenigen Minuten anpassen, aber bei Dutzenden von Problemen ist die menschliche Arbeitszeit schnell aufgebraucht.
Dies führt auch zu einem sehr kontraintuitiven Ergebnis: KI verbessert die Softwarequalität, kann aber kurzfristig die Veröffentlichungsgeschwindigkeit von Software verringern.
Peter fasst dieses Phänomen als „Anhebung der effektiven Qualitätsschwelle“ zusammen. Als diese Funktionen entwickelt und eingereicht wurden, verfügte die Branche noch nicht über die heutigen LLM-Prüfkapazitäten. Als PostgreSQL 19 zur Veröffentlichung bereitstand, konnten die neuen Werkzeuge bereits Probleme erkennen, die früher schwer zu finden waren. Code, der früher den Veröffentlichungsstandards entsprochen hätte, ist unter den neuen Prüfkapazitäten plötzlich „nicht mehr gut genug“.
KI-gestütztes Fuzz-Testing könnte direkt in die Funktionsentwicklung einbezogen werden
Datenbanken sind besonders anfällig für solche Probleme.
Ein wichtiges Merkmal von PostgreSQL ist, dass Entwickler oft erwarten, dass verschiedene Funktionen frei kombiniert werden können. Eine SQL-Funktion muss nicht nur in den üblichen Fällen funktionieren, sondern kann auch in Domänen, zusammengesetzten Typen, partitionierten Tabellen, Ansichten, Funktionen mit Sicherheitsdefinitionen, Triggern und anderen Umgebungen eingesetzt werden, und diese Fähigkeiten lassen sich zudem weiter ineinander verschachteln.
Peter führt als Beispiel an, dass eine neue Funktion auf SQL-Ebene mit einer solchen Kombination konfrontiert werden kann: Eine Domäne ist auf einem zusammengesetzten Typ angewendet, das Feld im zusammengesetzten Typ ist selbst wiederum eine Domäne; die Domäne hat eine Nicht-Null-Bedingung; die Spalte wurde einmal gelöscht und dann wieder hinzugefügt; die Tabellenpartition wurde getrennt und dann in einer anderen Spaltenreihenfolge wieder angehängt; schließlich taucht all dies in einer Ansicht auf, die von einer Sicherheitsdefinitionsfunktion in einem Trigger aufgerufen wird.
Theoretisch wünschen sich Entwickler, dass all diese Dinge einwandfrei funktionieren. Das Problem ist, dass Menschen kaum alle Kombinationen aufzählen können, geschweige denn jede einzelne manuell testen.
LLM-gestütztes Fuzz-Testing eignet sich genau hervorragend für diese Art von Aufgaben. Das Modell kann ständig Randkombinationen generieren, Testeingaben erstellen, Anomalien beobachten und dann entlang der Anomaliepfade weiter expandieren. Daher geht Peter davon aus, dass diese Art von KI-gestütztem Fuzz-Testing in Zukunft direkt in den Funktionsentwicklungsprozess von PostgreSQL integriert werden muss, statt erst spät in der Beta-Phase gebündelt eingesetzt zu werden.
Im tatsächlichen Entwicklungsprozess gibt es bereits entsprechende Anzeichen. Im August dieses Jahres ließ Robert Haas, Mitglied der PostgreSQL-Community, Claude eine Risikobewertung für die Patches von PostgreSQL 19 durchführen, basierend auf Anzahl und Art der nach dem Feature Freeze behobenen Fehler. Dabei wurde die SQL-Attributgraphenabfrage als eine der Hochrisikofunktionen eingestuft, die zu diesem Zeitpunkt bereits 17 Korrekturen durchlaufen hatte.
Der Kernentwickler Tom Lane erklärte anschließend, dass er sogar „um ein Abendessen wetten“ würde, dass bei SQL/PGQ im damaligen Zustand nach der Veröffentlichung Probleme auftauchen würden, die erst mit PostgreSQL 20 vollständig behoben werden könnten. Letztendlich wurde SQL/PGQ tatsächlich aus PostgreSQL 19 zurückgezogen.
Ein anderes Mitglied der PostgreSQL-Community erwähnte anschließend, dass nach dem Start der KI-Prüfung für diese Funktion weitere schwerwiegende Probleme entdeckt und manuell bestätigt wurden. Das bedeutet, dass KI in diesem Veröffentlichungszyklus nicht nur als „gesprächsorientierter Code-Kommentator“ fungiert, sondern bereits an der Risikoprüfung echter Open-Source-Projekte beteiligt ist.
Peter betont aber auch, dass KI nicht der einzige Grund für diese groß angelegte Rückziehung ist. Einige Codes weisen tatsächlich eigene Qualitätsprobleme und Mängel in der Architekturdesign auf. Die PostgreSQL-Community hat in diesem Jahr zudem eine intensive Phase der Bearbeitung von Sicherheitsproblemen durchlebt, bei der viele erfahrene Entwickler von April bis August mit der Behebung von Sicherheitsproblemen beschäftigt waren. Dadurch wurden die zusätzlichen Prüfungen und Tests, die eigentlich in der frühen Beta-Phase stattfinden sollten, beeinträchtigt. Als diese Entwickler wieder an PostgreSQL 19 arbeiteten, traten viele Probleme erst spät im Veröffentlichungszyklus zutage. Darüber hinaus ist die stetig wachsende Komplexität von PostgreSQL selbst eines der grundlegenden Probleme.
Die große Anzahl an Problemen hat die PostgreSQL-Community schließlich zu einer sehr konservativen Entscheidung gezwungen.
Laut Peter wurden je nach Statistikverfahren etwa 8 bis 10 wichtige Funktionen aus dem Zweig von PostgreSQL 19 zurückgezogen, von denen viele nach Korrekturen voraussichtlich wieder in PostgreSQL 20 aufgenommen werden. Eine repräsentative Funktion davon ist SQL/PGQ, das für die Abfrage von Eigenschaftsgraphendaten aus Knoten und Kanten nach SQL-Standard dient, aber aufgrund ungelöster Probleme letztendlich nicht in PostgreSQL 19 aufgenommen wurde.
Bemerkenswert ist, dass die PostgreSQL-Community zuvor sogar der Ansicht war, dass PostgreSQL 20 hauptsächlich zur Fehlerbehebung dienen würde und nicht viele neue Funktionen enthalten würde. Jetzt hat sich die Situation umgekehrt: Die aus PostgreSQL 19 entfernten Funktionen haben bereits eine Reihe fast abgeschlossener Kandidatenfunktionen für PostgreSQL 20 hinterlassen.
PostgreSQL 19 selbst wird dadurch aber nicht zu einer „kleinen Version“. Peter erwähnt, dass es weiterhin wichtige Funktionen wie REPACK CONCURRENTLY, die logische Replikation von Sequenzen und Abfrageplaner-Hinweise über pg_plan_advice enthalten wird. Nach dieser zusätzlichen Prüfung erwartet er sogar, dass PostgreSQL 19 eine noch stabilere Version wird.
RC1 wurde wie geplant am 15. Oktober veröffentlicht, aber die offizielle Version wurde vom ursprünglich geplanten 29. Oktober auf den 19. November verschoben. Das Veröffentlichungsteam hat zudem RC2 für den 12. November hinzugefügt, um die große Anzahl an kürzlich angesammelten Korrekturen einer weiteren Validierung zu unterziehen. Das offizielle Team bezeichnet dieses Jahr als „ungewöhnlichen großen Versionsveröffentlichungszyklus“ und betont, dass das endgültige Ziel nach wie vor die Gewährleistung der Stabilität und Zuverlässigkeit von PostgreSQL ist.
KI kann unbegrenzt Probleme finden – bis zu welchem Grad sollen Menschen sie beheben?
Dieses Ereignis hat sich anschließend in der Entwickler-Community schnell verbreitet. Viele Entwickler sind der Ansicht, dass der neue Engpass in der Softwareentwicklung möglicherweise von der „Fehlererkennung“ zur „Klassifizierung von Fehlern“ wechselt.
„Diese Situation wird nicht so schnell verschwinden. Der nächste Schritt, der wirklich gelöst werden muss, ist die Klassifizierung der von KI gefundenen Probleme, sodass nur die schwerwiegendsten Probleme vorrangig zur manuellen Prüfung weitergeleitet werden.“ Andere Entwickler weisen auch darauf hin, dass nach dem plötzlichen Rückgang der Kosten für das Auffinden von Schwachstellen und das Erstellen anormaler Eingaben die Geschwindigkeit von „Problemfindung“ und „Problembehebung“ nicht mehr übereinstimmt. Früher brauchten Sicherheitsforscher möglicherweise Tage oder sogar Wochen, um einen komplexen Mangel zu finden, während KI eine große Anzahl von Pfaden gleichzeitig erkunden kann – menschliche Wartende können aber immer noch nur einen nach dem anderen bestätigen.
Aber eine andere Gruppe von Entwicklern fürchtet, dass KI zu einer „Flut von echten und falschen Fehlern“ führt.
Ein Entwickler gibt an, dass seine Erfahrung zeigt, dass KI eine große Anzahl von Problemen meldet, die im Kontext des lokalen Codes plausibel erscheinen, aber im Kontext des gesamten Systems nicht zutreffen. Wenn das Entwicklungsteam jeden von KI vorgeschlagenen Fehler mechanisch behebt, kann am Ende ein überkonstruiertes System mit schlechterer Leistung entstehen. Der zeitaufwändigste Teil besteht darin, dass Menschen einzeln beurteilen müssen, ob es sich um einen echten Fehler, um einen extremen aber akzeptablen Randfall oder um eine reine Falschmeldung handelt.
Ein Entwickler, der im Bereich Datentechnik arbeitet, gibt an, dass in seinem internen KI-Code-Prüfungssystem selbst wenn das Modell Zugriff auf Kontext wie Code-Repository, Confluence und JIRA hat, nur etwa ein Achtel der Berichte letztendlich als gültig eingestuft wird. Bei allgemeineren Prüfrobotern kann dieser Anteil sogar noch weiter sinken. Ein anderer Entwickler mit Kenntnissen über statische Analysewerkzeuge gibt an, dass eine große Anzahl von Falschmeldungen seit jeher ein altes Problem der automatisierten Analyse ist. Wenn die Anzahl der Fehlerberichte auf zehntausend ansteigt, ist es kaum realistisch, eine 100%ige manuelle Bestätigung zu verlangen.
Einige Nutzer beweisen aber anhand ihrer eigenen Erfahrungen, dass sie trotz Unzufriedenheit mit Falschmeldungen nicht auf die KI-Prüfung verzichten wollen, da sie tatsächlich seit Jahren versteckte technische Schulden aufdecken kann. Sie ließen KI eine gebündelte Code-Prüfung für Skripte, Aufgaben und Konfigurationen in einem Kundensystem durchführen, das seit etwa 10 Jahren stabil läuft. Dabei wurden 39 Probleme gefunden, von denen 30 als echte Fehler bestätigt wurden, die zuvor nie ausgelöst worden waren.
Ähnliche Vorfälle treten nicht nur in Open-Source-Projekten wie PostgreSQL auf. Bei einigen Closed-Source-Softwareprodukten können seit Jahren entwickelte Funktionen ebenfalls nicht wie geplant veröffentlicht werden, da KI neue Probleme entdeckt hat. Früher war die übliche Vorgehensweise, die Software zuerst auszuliefern und dann schrittweise Patches in zukünftigen Versionen zu veröffentlichen. Sobald das Entwicklungsteam aber eindeutig weiß, dass ein Fehler oder eine theoretische Schwachstelle existiert, wird es immer schwieriger, diesen weiterhin in die offizielle Version zu übernehmen, wenn es um Sicherheitsaspekte und Haftungsfragen geht.
Ein Entwickler weist darauf hin, dass viele Probleme in komplexer grundlegender Software wie Datenbanken nicht dadurch gelöst werden können, dass man den Fehlerbericht einfach an das LLM zurückschickt und auf „automatische Reparatur“ klickt. Einige Mängel entsprechen tatsächlich Abwägungen in Architektur und Produktsemantik: Ein bestimmtes Verhalten kann in Nutzungsszenario A ein Fehler sein, in Szenario B ein sinnvolles Design und in Szenario C bedeuten, dass das grundlegende Design von vor einem Jahr neu erstellt werden muss. KI kann solche Widersprüche sehr kostengünstig aufdecken, aber die Entscheidung, „was das richtige Verhalten eigentlich ist“, erfordert nach wie vor erfahrene Wartende.
Es gibt bereits Befürchtungen vor einem anderen Extrem: der „Veröffentlichungslähmung“. Wenn KI ständig neue Randprobleme aus jedem komplexen Code-Repository ausgraben kann, gibt es theoretisch immer den nächsten Fehler. Bis zu welchem Grad ein Projekt Fehler beheben muss, bevor es veröffentlicht werden darf, könnte in Zukunft ein schwierigeres Problem werden als die Frage, „wie viele Fehler KI finden kann“. Einige Entwickler schlagen vor, statt zu versuchen, alle von KI gefundenen Mängel in einer einzelnen Version zu beseitigen, diese systematisch zu erfassen, zu klassifizieren und in den nachfolgenden Entwicklungsplan aufzunehmen – sonst kann keine große Software jemals einen echten „Null-Fehler“-Zustand erreichen.
Schlusswort
Da die Programmierfähigkeit von Tools wie Claude Code und Codex immer stärker wird, ist das Schreiben von Code durch KI kein Problem mehr. Das Ereignis um PostgreSQL 19 zeigt aber, dass auch das „Entdecken von Problemen“ kein Problem mehr ist, wenn KI in der Lage ist, Code in großem Umfang zu prüfen, zu testen und zu attackieren.
Das, was als Nächstes wirklich knapp wird, könnte das menschliche Urteilsvermögen sein: Welche Probleme müssen unbedingt behoben werden, welche sind akzeptabel; ob es sich lohnt, die Veröffentlichung einer wichtigen Funktion zu verschieben, nur um einen Randmangel zu beheben, der mit drei Codezeilen korrigiert werden kann; welche der Dutzenden von von KI gefundenen Problemen bedeuten, dass die Architektur selbst neu entworfen werden muss; und was eine Software überhaupt erreichen muss, um als „gut genug zur Veröffentlichung“ zu gelten, wenn Maschinen endlos nach Anomalien suchen können.