PostgreSQL core team member Peter Eisentraut has written a blog post reflecting on the "unusually high number of features" that have been taken out of the upcoming PostgreSQL 19 release since the beta period began.
Some of the reverted features had significant architectural defects that would have been hard to fix quickly and during beta. But there was also a long tail of relatively harmless issues involving various edge cases. In past times, many of these would not have surfaced until much later and we would have fixed them bit by bit over the subsequent five years. But with LLM-assisted code review, these kinds of things can get found much faster, and then you're staring at a list of like forty defect reports. And even if each of them requires only a three-line fix on average, there is a fixed overhead to dealing with each of these, and then you run out of time. Most if not all of the affected reverted features were written a long time ago when LLM-assisted code review was not as useful as it is now, meaning that the effective quality bar has been raised after the time the feature was written and committed. Unless the capabilities of LLM-assisted code review keep improving at the current rate, this situation should sort itself out for future development cycles.
A corollary of that is that, at least for the most part, as far as I can tell, this situation is not due to "vibe coding". This code was written well before that was a possibility.
LWN covered the unusually large number of bug fixes required for PostgreSQL 19 features in September.