d0liver

> It’s possible that some of this jump is the result of committers making more mistakes this year than they did last year, but I don’t think anyone who works on the project really believes that’s the main cause. Rather, it seems likely that PostgreSQL committers were about as conservative in 2026 as they were in preceding years, but a lot more of the mistakes they made were quickly found by LLMs.

This is pretty lazy. Especially considering the fact that later in the post author talks about how humans have to author the fixes, because the AI ones aren't up to snuff. It's not a stretch to think that more of the AI generated stuff that's not up to snuff just got through. And, focusing on bug fixes is going to yield more but fixes, regardless of the technologies involved.

I'm not saying that LLMs aren't helping, necessarily, but this isn't very convincing.

I already really liked candy corn, but this made me like it even more? This is awesome.

Right. Corporations own people, not cash.

Not really. Like, yes, relative to your competitors. But, if the cost of growing potatoes is ten cents per potato, and then I make something that can produce potatoes for one cent then I'd expect everyone to just have more potatoes. This would drive down the cost of potatoes, because the supply would be saturated eventually, but AI is supposed to just make more of everything. So, if AI works as advertised, then you'd probably expect a brief period of highly increased profit margins (by the consumers of AI) followed by rapid _deflation_ as the value of everyone's dollar increases exponentially. Of course, neither of those things is going to happen, because the AI sales pitch is actually a pyramid scheme, so you get the people at the top raking in cash, while everyone else tries to sucker the next tier of buyers so that they can make their buck.

The fear is the sales pitch. AI has some uses but nowhere near enough to justify the price tag, so we need something more to sell it.

Came here to say this. What AI is doing with math is essentially fuzzing, but looking for valid inputs that solve a problem and the inputs are mathematical abstractions. It's a cool approach, but AI doesn't understand what's going on, and without understanding it won't be able to create the next generation of mathematical abstractions needed for the next generation of proofs.

I don't think that's true. If what you're doing is building a fuzzer for mathematical proofs then just say that? The fact that it's doing some of the initial work on hard problems is cool. So is the fact that the promise of that new approach is having a social effect of crowd sourcing talented people to follow up on that work. No need to try to misrepresent it as more than that.

You seem to be misunderstanding the premise of the statement. Go write, "print 'foo';" and copy and paste that statement one hundred thousand times. Congratulations, you just wrote one hundred thousand lines of functioning code! Was that hard? No? Okay, so how is this different from other code? The difference is that it's easy to _understand_ how that code works, because it's the same behavior repeated over and over. So, writing code is easy, but understanding code is difficult! And, when we code with AI, undertanding is precisely the part that it can't handle, even though that's where almost all of the value is!

If, by your definition of understanding, you can understand something without knowing how it works, then what would be the point in understanding it?

Your argument underscores the fact that understanding exists on a spectrum and that deep understanding can be difficult, or even impossible to achieve. Even formal verification seeks to verify certain properties of a system, and doesn't represent anything close to comprehensive understanding, and the process of formal verification is also guided by a fallible human. In a lot of ways, formal verification is just pushing up to review of a different "programming language."

So, good review is really hard, but ignoring the difficulty doesn't make it go away.

What if I told you that understanding what it is doing and finding bugs is actually the same problem?

I think you just made some strong arguments for classifying them as gatekeepers. The idea, like you said, is to make it so that competitors can enter the market and pick up the slack in areas where AWS and Azure are dropping the ball.

In other words, for the primary uses of search things have gotten much worse, but some workarounds still exist.

> software was already in a horrible state before AI, so your dichotomy doesn't work.

It depends on the software. But, generally speaking, I try to use and write the best software available that solves my problem, even if it's one of a kind; it doesn't really matter if the other 99.9999% of the software in the space is broken.

Given 1000 hours to work on a problem, an LLM will continue to yeet out mediocre variations on a theme. Give me 1000 hours to work, and my product will keep getting 1% or 2% better until it's much better than any shit an LLM would spit out.

Similarly, I would much rather use someone else's emulator that they spent 1000 hours on than have AI yeet out some mediocre shit that kinda works, but is really just a mindless exploitation of something that someone else wrote that was actually good.

Then, you follow that with, "Yeah, but AI just allows you to iterate faster and skip the boring stuff, so that you make your product better even faster."

And then I follow that with, "The part where you take it apart piece by piece and study each piece and get kicked in the head by the realities of your lack of understanding is the part that's actually valuable, and it's precisely what you're skipping with an LLM"

I would much rather have software that works but lacks accessibility features than software that's broken but also has some broken accessibility features sprinkled in. The former is useful to many people, while the latter is useful to no one.

But the key here is: LLMs don't have latent rigor, nor any other kind of rigor.

What makes you say that AI is not going anywhere? I hear this overwhelmingly, "AI is here to stay", as if y'all are so caught up in the movement that you've started taking that conclusion as being the axiom. TBH, it feels like a religion.

Getting people into coding is both cool and also not specific to AI.

Gross .

This isn't a JS specific issue.

"If you travelled back in time, the coastline itself would be unrecognisable to modern eyes. In the Jurassic Period, most of what later became Britain was under the sea, apart from Scotland, East Anglia and a series of small islands in the southwest."

https://www.nhm.ac.uk/discover/life-in-jurassic-oceans.html

It's clear that the article is mostly talking about the reader's ability to interpret figuratively, regardless of the specific reference. However, I'm not even sure it's a biblical reference, because I think dinosaurs are generally incompatible with the story of Noah's Arc. I'm guessing it's probably more along the lines of some theory of continental movement that was prevalent at the time. Maybe it's just a weird mismash of dinosaurs and Noah's Arc, though?

> if all the water left, it could be dry like a desert too

This is just a contextual interpretation thing. It's clear that's not what he means because he says it's muddy, so it must be the other thing. Also, it becoming a desert is more extreme, so in that case the writer would probably offer up a more detailed explanation.

Someone saying they vibe coded a thing is like them saying they were hammered when they wrote it. Maybe they did a great job, but probably not; it's definitely cause for concern.

Unnecessary access isn't a solveable problem. In order to restrict permissions to exactly what a program needs, in general, you'd have to define exactly what a program does. In other words, you'd need to rewrite the program with self-enforcing access restrictions.

So, permissions are always going to be more general than what a program actually needs and, therefore, exploitable.

Producing incorrect information is an insidious example of this. We can't simply restrict the program's permissions so that it only yields correct outputs -- we'd need to understand the outputs themselves to make that work. But, then, we're in a situation where we're basing our choices on potentially incorrect and unverified outputs from the program.

My impression was that it's next gen because it's using Rust on WASM as opposed to something that compiles to JavaScript.

However, I could be wrong. There's a small semantic difference between "next gen Rust web UI library" and "next gen web UI library written in Rust"

I think that's kind of the point though: AI is the sand, but it's the rocks that hold all of the value; the further you get away from using AI the more real value you obtain. Like, a few of the rocks have gold deposits in them, and the sand is just infinitely copious but never holds anything valuable. And you've got a bunch of people running around saying, "Behold my mountains of sand!"

IIRC, you can do git branch -D $(git branch) and git will refuse to delete your current branch. Kind of the lazy way. I never work off of master/main, and usually when I need to look at them I checkout the remote branches instead.

This issue exists with the parsed case, too. If you're using a database to store data, then the lifecycle of that data is in question as soon as it's used outside of a transaction.

We know that external systems provide certain guarantees, and we rely on them and reason about them, but we unfortunately cannot shove all of our reasoning into the type system.

Indeed, under the hood, everything _is_ just a big blob that gets passed around and referenced, and the compiler is also just a system that enforces preconditions about that data.

I think, more generally, "push effects to the edges" which includes validation effects like reporting errors or crashing the program. If you, hypothetically, kept all of your runtime data in a big blob, but validated its structure right when you created it, then you could pass around that blob as an opaque representation. You could then later deserialize that blob and use it and everything would still be fine -- you'd just be carrying around the validation as a precondition rather than explicitly creating another representation for it. You could even use phantom types to carry around some of the semantics of your preconditions.

Point being: I think the rule is slightly more general, although this explanation is probably more intuitive.

> As I understood it the trick was effectively to dump the full public API documentation of one of those services into their agent harness and have it build an imitation of that API, as a self-contained Go binary. They could then have it build a simplified UI over the top to help complete the simulation.

This is still the same problem -- just pushed back a layer. Since the generated API is wrong, the QA outcomes will be wrong, too. Also, QAing things is an effective way to ensure that they work _after_ they've been reviewed by an engineer. A QA tester is not going to test for a vulnerability like a SQL injection unless they're guided by engineering judgement which comes from an understanding of the properties of the code under test.

The output is also essentially the definition of a derivative work, so it's probably not legally defensible (not that that's ever been a concern with LLMs).

Definition one on Merriam Webster is, "To make into a product suitable for use." This is what I thought you meant, because cost of production is what it costs to forego buying something. IMO, that's the cost you really want to consider.