News for hackers. Stuff that matters.

A comment on Postgres 19 is late, and it's AI's fault. Parent comment

Re:Postgres 19 is late, and it's AI's fault by cloudbonsai on Monday November 02, 2026 @01:21AM (#50333692)
Do you think AI is as good at writing bug-free code as finding bugs? If that's the case, this should be a one-time event during human coders -> AI transition. It's like catching a lot of bugs during a handover review.
[ Parent | on HN ]
Re:Postgres 19 is late, and it's AI's fault by wongarsu on Monday November 02, 2026 @04:09AM (#50334583)
The code it writes in the first attempt is at least as buggy as a human's. So the question is more whether it is as good at spotting bugs in its own code as it is at spotting bugs in human code

I'm tempted to say "no, it isn't". But I don't have numbers to back that up

[ Parent | on HN ]
Re:Postgres 19 is late, and it's AI's fault by jiggawatts on Monday November 02, 2026 @01:50AM (#50333834)
Most software used to be written in assembly language. Microsoft DOS was mostly .ASM files, for example.

That era is over, compilers are used for almost all software, eliminating entire categories of bugs.

[ Parent | on HN ]
Re:Postgres 19 is late, and it's AI's fault by codebje on Monday November 02, 2026 @11:50PM (#50348215)
What categories of bugs would you say we eliminated going from macro assemblers to compilers?

(Operating systems, by the way, are the exception to the rule for assembly: the Linux kernel today has an x86/x64 assembly source component around the same size as MSDOS 5.0: ~250kloc of it. Windows is smaller, based on the NT4 kernel leak at around 70kloc. As a percent of total they're much less, of course, but they also do much more. And have correspondingly more bugs, too.)

[ Parent | on HN ]
Re:Postgres 19 is late, and it's AI's fault by jiggawatts on Tuesday November 03, 2026 @01:53AM (#50348896)
> What categories of bugs would you say we eliminated going from macro assemblers to compilers?

Entire classes of 'safety' bugs that just don't exist in modern compilers.

E.g.: forgetting to "POP" something you "PUSH"-ed, especially when it was a conditional allocation for a temporary.

Similarly, type errors were much more common, especially signed/unsigned, or accidentally overwriting things in scenarios that just don't occur even with ordinary C code. Function args were easy to push "correctly enough" that it "worked", but not really.

[ Parent | on HN ]