> Whatever I link to you are just going to say its AI, or inconclusive.

There is no point in linking anything further because your line of reasoning is flawed to begin with, due to two reasons.

Reason one, your argument amounts to: software has bugs, and every bug is there because there was no test that would prevent that specific kind of bug (and it would if they were doing testing "correctly"). This is a completely vacuous argument because all software has bugs and therefore no one is doing testing "correctly" to your satisfaction anyway, which makes the whole discussion moot.

Reason two, you seem to be assuming that I am somehow advocating for not doing software quality assurance or not writing any tests. I am not. I am arguing that it is not worth investing extra time into learning that discipline, because a) not fundamental; b) you will be forced to learn it anyway. Therefore, spend your precious extra time on more interesting and useful things.

> But I don't see anything on getting the "fundamental theory" wrong.

Typically projects that get the basics wrong don't live long enough to find themselves in an AI training corpus used to generate listicles.

> Why would I if I could avoid it?

a simple "no" would have sufficed to establish that your opinion on usefulness of bloom filters in distributed systems probably shouldn't be weighed very high.

> That's just basic programming in the type system of your chosen language, not "fundamental theory" as you call it.

The fundamental theory bit helps to choose the appropriate data organization for your use case and either implement it yourself or modify a pre-existing implementation, or convince yourself that a pre-existing implementation is sufficient.