At work, they mostly let me increase quality, because it's easy to say find all parsers in my code base and fuzz them.
Of course, you can make a giant pile of doggy-doo-doo, but that was always true, just you can now make an epic Giza-sized pile.
Yeah but were more likely to learn how bad your code was in the process. I see people oblivious to their slop putting pressure on others to merge it.
The other place they are amazing is in working with legacy code bases. I mean, the kind the dev team always wants to throw away. First, even if you do want to throw it away, you can first find out what it does and realize it does more than you think it does. You can also create integrations to more modern components which can be used to extend it. You can also create a pretty decent test suite if you do not have one. And, once the behaviour has good test coverage, you can re-write it into something more modern. You can even completely change the architecture while ensuring compatible external behaviour. Remember, this is all in place of “throw it away and start over from scratch, only to discover that the scope is much larger than expected”.
It’ll still take weeks with AI in the picture, but for some reason management is more willing to plan it when they also have the additional token bills to pay.
Now, you can make enough progress with one developer’s quiet afternoon to be confident and finishing the work also takes less time.
The technical grasp of the legacy codebase was a factor, but often not the largest.
I mean, I have finished more side projects than before. So they do change it. Just not as dramatically.
You have the perfect verifier.
I know AI bros are allergic to reading, but at least feed my reply to a clanker and get it to summarise for you before ignoring what I wrote.
Pets.com was an ignominious scam but the internet flourished after a cleansing.
Do you think anyone will pay for photoshop in 10 years, when a free version can be conjured up just by screen capturing all the interactions professionals have with photoshop?
> how PostgreSQL is having dozens of bugs discovered and fixed via LLMs
The PostgreSQL article was specifically about how the LLMs were incapable of fixing bugs, meaning they had to delay their next major version because humans were unable to deal with the volume of bugs. I did not make a claim that LLMs are useless, could not do code review, etc, but there is a difference between a useful tool and something that generates production-ready code.
This is what "100" looks like if you try to generate a DB from scratch: https://jepsen.io/analyses/particledb-1.1.4 - written in Rust, ""formally verified"", scammed AI-pilled investors out of $90 million for a database that fundamentally doesn't work in any capacity whatsoever.
The subthread was also about 80-100. This seems like a goal post move.
>The PostgreSQL article was specifically about how the LLMs were incapable of fixing bugs
We must have read different articles. This one does not say that, as best as I can tell: https://www.theregister.com/databases/2026/10/16/postgres-19...
Speak for yourself :)
More and more, I am using half finished as a polished product, but pragmatically very useful software I have built myself.
More importantly, I see no reason to polish this into a product. It is more useful in this half finished, easily moldable state.
Like it use to make sense to bake the clay and sell the hardened output but now I want to keep the soft clay so it can be molded to my changing needs. I keep adding to a collection of these moldable states.
But its a lot less effort that when we didn't have LLM's.
Interestingly it does seem that it's still enough effort to prevent most folks from making that step though.