Hacker News

I don't think it'll be that bad:

1. The cost of running AI is dropping down to "free" - there's open weight models, open source tools, and guides on running your own if the long list of suppliers isn't good enough for your use cases.

2. Vulnerabilities have always been a risk; AI is not a panacea. The pre-AI best practices still apply. Furthermore, a huge percentage of vulnerabilities are in 3rd party tools and systems, which are systematically being scanned and fixed and/or exploited, then fixed.

You mention "the free software community" in your last sentence though - this implies the code in question is open source, so it's able to receive plenty of improvements from anyone with access to these tools.

We haven't fired a single person yet due to AI. We just save everyone time, make input more accurate, make our accountants better, manage our technicians and jobcards better and so on. We also made our system bullet proof to the point that we only had one weekend failure in the last 24 months, and it wasn't our fault (a third party dependency did a large deployment on a friday night). Our system is now deeply "boring" and its awesome.

Perhaps the ultimate use case would be to use AI to scan, debug and find issues etc, but never to generate new code. Still have humans writing and understanding everything, keeping things as clean and concise as possible.

Actually, I have started with it already but is paused, but the approach is to rebuild it from scratch in parallel to our current legacy system and move our staff over to the new completed screens in batches (we have close to 1000 views in our system, 150 background jobs, with about 15 main categories (think organisational sub-divisions)). So as long as we go slow and steady (even with AI) it will work out fine, I expect it will be done in less than 6 months. One month if we rush but we don't want to rush it, as we are moving some things over from MSSQL to Postgres, so slow and steady is the way.

Because they are large codebases with their own technical debt. You're not doing a full rewrite, but just make what you need for you own codebase.

When you change a single setting in the IDE to make something more strict and you have 1M+ lines of code, you will get 30K items to fix, via red/yellow/blue squiggles in the IDE. Most of those can be simple refactorings, but the performance & UI of the IDE makes it incredibly unwieldy and it will sometimes fight you back, sometime crash internal processes which leave refactorings half baked and so. Now imagine you change 50 such settings, to make the compiler force you to write better code. Changing 200K+ lines of code yourself is a nightmare (and to prove it still does the same thing afterwards). Instead, claude systematically approaches whole classes of errors and convert them to cleaner variants (either using our custom skills or it writing new scripts to do it). I consider myself an advanced user of IDE's, know how to do bulk refactoring and renames and so on (esp with JetBrains tools), and I would say it would be a near impossible task to do as a human. Then there are other developers - so you flip a setting and now 5 other people's IDE's are forcing them to work a specific way which will make you unpopular very quickly and revert the changes. So, since most of us no longer use IDE's as our main tool to build/diagnose, we can more easily flip compiler settings without destroying someone else's week. Hope that makes sense.

Oh it also helps to split refactoring work into three buckets: business logic changes, performance changes (same output as before but faster) and cosmetic changes (rename files/folders/classes, breaking large files up, add logging/comments, domain layering etc). We tend to focus on performance and cosmetic changes for bulk refactors and leave logic changes to more dedicated sessions as to avoid changing what the system do (our domain is fairly complex and we cannot afford breakages). We also managed to port ALL of our code to dotnet 10 lts and have clean boundaries between projects (we have a mono-repo with about 50 projects in it), so we can wholesale upgrade dependencies without a sweat.

We are multiple developers, each having 10+ main claude agents running different sessions/terminal tabs. I have 10 copies of our codebase on my laptop, each with their own purpose and claude session and history. The other devs have different approaches but we all get similar output. And then we also built an agent framework that runs within our system that has access to our code (at most 60min behind master branch), our infra and our databases, so it can diagnose issues with excellent precision and prove it to us where to find code/data issues.

I personally started using AI with a very rudimentary "memory" system, and for first weeks corrected it ad nauseam, until, in the small domain I was responsible for, it started doing work end to end fully autonomously. Takes a lot of time and effort to bootstrap, but once steered well enough, it just clicks and less and less is needed to check manually

Myself specifically, I have a /code folder without about 10 copies of our codebase, each running their own claude sessions & git branch. Then, I have 10 terminal branches. I spend a ton of time planning out & specing the problem with claude, to be as specific as possible and be as constrained as possible so it cannot go on side-quests. I use Opus 5.5 on High effort. That's just on my laptop with what I can mentally cope with day to day. Then we have some other automatic ai goodies running within our custom agent framework that runs within our platform that also helps. Then for apps, I basically plug in multiple phones into my laptop with usb (and emulators if I really need to), and claude can fully drive the ui and testing on the phones via adb as an example. Even on linux/fedora/kde it can drive UI apps a and take screenshots and fix things properly etc. It can ingest all logs & debug chains, so it absolutely flies through its task.

Before we started this journey (about a year ago), we spent a ton of time cleaning up our codebase, splitting large files (10K+ lines) into files that are no more than 2K lines, things like that. Then we let claude scan our important files and summarize them, add comments for future claude sessions. So we've let it built up tribal knowledge per file and the reasons for things to exist. We tell it all about our operating environment, the country and legal framework etc, so every little piece helps it stay honest and on track.

So to start, do something simple like: Scan the files in this folder for database code and check for queries that loads the entire result set into memory and/or queries that loads all columns. Suggest which queries we can filter better or reduce columns being transferred. Once done, also check real db row counts, compare them with the queries in these files and check if they might benefit from an index or partitioning/sharding. Also check for queries that loads data but their results are not used. Don't make changes yet, just do a deep investigation and report back. Feel free to spin up muliple agents to batch the scans.

edit: it goes without saying you need a language with strict typing and a good compiler (we use dotnet). Doing this on python/javascript would be a nightmare.

Our legacy system runs mvc view with bootstrap 3 and some jquery. It's not a SPA, so no framework to replace. But we still have to mess around with npm sometimes.

We’ve also been blowing a lot of retainer hours just patching sites instead of building new features. It sucks. Ultimately going to cost clients more.

Same here. I got access to Mythos two months ago, it confronted me with decades of nasty bugs I wrote. This has been stressing me out a lot, caused sleep deprivation (the bugs follow me in my sleep, yes, really). All other progress is halted, I've been squashing bugs day and night. I see a light at the end of the tunnel.

Bottom line: it's a good thing. My software will be better after that. Even if it's currently not good for my ego (and my health). But I'm glad for all the tools that help me improve quality.

And sure, I can just ask LLMs to fix the bugs, which works well half of the time, and produces bad slop in the other half. This is where human expertise and judgement is still necessary to avoid letting our code bases drift into LLM spaghetti hell.

How did you get product management to agree to that? Ours said "I could fix all of that in 2 days with Claude." They are still not fixed. Granted, our PMs suck.

Interesting that this could result in net negative software productivity world wide in terms of features right now.

LLMs finding unpatched vulnerabilities faster than they can be reasonably patched, bringing all other software development to a halt.

It’s amazing how much slop humans have produced that now needs to be fixed by AI…

I don't see how that's a relevant comparison. These are software bugs. Once you find them you fix them. You can't predict the harm from a small bug when AI can chain complex exploits and when your software is used in mission critical applications as a data store. There's no paradox here, bugs are bad and you want to fix them all.

That's a flawed analogy though.

Firstly, the cost of fixing a bug once you know it exists is usually minimal compared to the cost of discovering that bug. This is the inverse of medicine, where the cost of testing (at least in terms of health outcomes for the patient) is typically minimal compared to the cost of treatment.

Secondly, if you have an asymptomatic illness, this does not typically make you more vulnerable (hence why it's asymptomatic). Like you say, you typically only die of one thing, so if you know the patient won't die of a particular diagnosis because something else is more likely to kill them, then it might not be worth making that diagnosis. But for software, you can be simultaneously vulnerable to lots of things at once, and any of these vulnerabilities can be the one to "kill" you. Some vulnerabilities may be easier to find and exploit (or do more damage) but in principle any active vulnerability can be exploited.

Thirdly, having multiple vulnerabilities makes software more vulnerable overall, because those vulnerabilities can potentially be chained together to create more serious exploits than each vulnerability would have represented on its own. To a certain extent this can be true in medicine as well, but generally it isn't.

Fourthly, we can't cure death (yet?) but we can cure all the vulnerabilities that we've found so far. There is no known upper bound on the lifespan of a piece of software, and we know that older code tends to have fewer bugs in that newer code, presumably because those bugs have been fixed over time. This is different from health issues, where a given condition may be chronic or terminal and therefore at a certain point there's nothing you can do to fix it.

Finally, ultimately in healthcare it's your body, and your decision was to what you do with it (assuming you can find a doctor willing to do what you want). If you have a condition and you want it cured, even if it is completely benign and will have no impact on your life whatsoever, then you can do that. (Again, assuming you have the resources and the condition is curable). But a software vulnerability does not affect you as the developer of the software, it instead affects your users/clients/customers. Therefore there are different dynamics in play. If I sell you a tool and I know it could be vulnerable, but I don't try and find out what those vulnerabilities are, then you're ultimately the one on the hook when all your data gets deleted or leaked.

> some bugs you don't want to find

The key thing you forgot, which makes this approach non-sensible, is the omniscience, without which you have no clue whether your posture towards a new bug-finding tool is good or not, since you don't know whether it will mostly find those bugs that are not worth fixing and the time wasted on fixing them is detrimental.

Similarly, how is ignorance better than informed decision when ignorance also includes missing critical security bugs?

Doing surgery on a code base is dramatically better than surgery on a person, the analogy breaks down pretty quickly I’d say…

Medicine is fuzzy, software is mostly maths. You can prove your software has no bugs and you increasingly should be proving that. The hard part is knowing if what you prove is what the software is doing.

Luddites were actually pretty reasonable when you dig into it. Maybe shouldn't be using it as an insult?

RTFA

> In the end, I don’t think that the delay in shipping PostgreSQL 19 is particularly concerning. It is not a long delay in the grand scheme of things, and it emerges directly from the project’s concern for quality.

Luddism, did not expect to ever hear that word with Postgres development :>

We could really use a lot more luddites tbh. Doesn't seem very applicable here tho.

Did you honestly need a /sarcasm tag in the article?

The article also concludes that overall, yes, finding more bugs is a good thing. Basically saying it’s the LLMs “fault” that the quality is improving, alongside a slight delay to the release.

They found a more efficient way to play Whac-A-Mole with bugs, they didn't find a way to reduce bugs.

It’s pretty clear there are a lot of valid reports based on the large increase in backport commits cited.

I'd imagine just as every other project, both.

likely both

I've been engaged with Postgres community for over 20 years now, and this has been my experience, too, throughout that time. Off and on I have interacted with a few other large projects, and nowhere (except at CodeBlocks) have I found such a welcoming and responsive community. The CodeBlocks IDE project has been one exception where I felt welcomed; but my interaction there was quite limited, and spanned over just a few days, so I can't extrapolate too much from that.

BTW, the Postgres community is also quite protective of their culture, so I expect this welcoming nature of the community to persist for a while.

I am pretty sure we have always been able to add holes faster than we can find them and fill them, and that this has not changed with the advent of faster hole finding tools that are also faster hole producing tools.

I will add more example links in the top-level comment, but here is the thread for that bug. [0]. tl;dr timestamp vs timestamptz comparisons aren't consistently ordered in a pathological edge case, which means that index scans can return the wrong answer. There's no way to fix it without either redefining the operators in a surprising way or disabling index scans in this case.

[0] https://www.postgresql.org/message-id/flat/c22286ad6268347c6...

That problem is as old as commercial programming; it doesn't matter that now your actors are prompt engineer and LLM, the same story can be told with manager and programmer.

This feels like just another variation of “it’s not the tool it’s the user,” which is too frequently leveraged during any discussion about AI. It makes it impossible to honestly assess the quality of the tool. You can always just say “people are doing it wrong.”

> The most common error for a search task is omission, and that's really hard to spot

NP-Hard, even[1]!

[1] https://www.i-programmer.info/news/112-theory/3830-physics-i...

The planning, which can also be done in concert with AI, before getting the AI to write the code helps with not losing track of what you're building. In my current workflow, I never tell AI to just code X, I always approach it in such a way to leave space for research and breaking it up into multiple units of work (tickets) if the scope of the feature or idea calls for it.

I wouldn't say it's "interesting", rather that it's a natural result of incentive structures. If the AI labs try to sell their product as being good at finding bugs, then their expected valuation is the entire market cap of the existing static analysis industry, which is not very high. If they instead sell their product as being good at writing software, then their expected valuation is the "market cap" of the code-writing industry, a.k.a. the total spent on software development labor, which is very high. It doesn't matter what's true, only what promises to make them the most money.

It is not in any way a “query thing” in the same manner as PageRank, it was based on prior work in deep learning and it is irrelevant that Deepmind was purchased by the same company that was behind Google Search.

Then just have the same AI bug checks for new PRs and automatically reject any that fail.

Depends. Security is and never was only bug free software.

If no attacker reaches system X you are not as exposed as with your internet facing frontend.

Note how Robert mentions a sharp increase in back-patched commits. Many of these bugs have indeed been around, silently, for a long time.

Ah, that makes more sense. Thank you!

"But beyond that... not every bug needs fixing; that's a trap"

this doesn't seem good attitude for critical software like database

"Don't be curmudgeonly. Thoughtful criticism is fine, but please don't be rigidly or generically negative."

https://news.ycombinator.com/newsguidelines.html

I think of you as a good HN contributor, but you've been posting a lot of unsubstantive comments lately, and breaking the site guidelines in other ways too. Can you please stop doing this, and return to using HN in the intended spirit? Your substantive, thoughtful points are welcome, but not comments like this current one, nor these (to pick a few examples):

https://news.ycombinator.com/item?id=50280377

https://news.ycombinator.com/item?id=50275967

https://news.ycombinator.com/item?id=50147625

Are the features bad by design? Like are they bad even if they work perfectly because they add bad abstractions to pg's SQL syntax, or are just broken in how they are supposed to work? If so the process is dysfunctional to let them get this far before noticing.

Are the features designed well (from a product perspective) but implemented poorly? Again, the process is dysfunctional to let them get this far before it notices.

Were there known issues with these that were planned to be fix, but the fixes didn't happen in time? That would make sense and it happens, but how is an LLM making that worse? LLMs in the worst case let you get the same work done more quickly, because you can always get the work done as quickly as you ever could by just not using an LLM. So the strongest thing you might say here is that you thought LLMs would let you get a feature into shape before it was too late, and for whatever reason that was overly optimistic.

I wish they'd adopt, merge in, or give official blessings to versioned postgres extensions like citus and pgvector.

Also Postgres has enjoyed decades of debugging.

To be honest I would love for someone to work on the structuring of pg_dump for example, which is entirely driven by regexes and binary structures. It’s awful and absolutely not programmable - a real shame.

I hope you don't believe this, PGRust has fallen far from grace. Wire protocol support is useful (other than said recommendation)

Remove pgrust: the entry is cheating (per-query kernels and result caching) (197 points, 10 days ago, 166 comments) https://news.ycombinator.com/item?id=50205816