How about (3): that in-house utility that you want to re-use across projects because it scratches one itch in precisely the way you want it scratched. Its raison d'être does not disappear from the appearance of LLM, it arguably gets stronger. You want the decisions that went into the library to be encoded in immutable form from the perspective of the contexts working on library dependents.
In the old days, both the investment in the library and the additional cost you'd want to sink on it to consider it publishing quality incentivised to keep it truly internal. LLM code however? It might be slop, but it's accurately groomed slop. Prompting the model to roleplay a public library author might even improve the output when it's in fact not published at all. The investment is low, the extra cost of sharing is low, worst that could happen is others actually picking it up and that would not be bad at all.
Is that spamming the public information universe on the faint hope that perhaps future models might come pre-trained with understanding of your library? Sure. But it's a very different thing from the scenarios described in (1).
One workload with observed radio discipline handling secrets, the other workload with a haystack of chatter that's not supposed to know about any of the secrets. When supply chain attack is in scope, trust only ever goes as far as misbehavior is observable. Cooperating workloads could be quite a powerful tool to make misbehavior less observable.
So many good answers here, all converging on moderation overreach stifling the page before LLM came in.
I'm not disagreeing at all, but I'd like to add that the moderation issues did not come from a vacuum: they were a reaction to SO reputation becoming so much of a CV optimisation metric that SO must have felt a lot of pressure to do something. Turns out that something wasn't good, but I'm not sure that other paths taken would have been much less bad. Some success just aren't set up to last.
> On top of that all AI companies seem to be run by megalomaniacs.
Not all of them. Only those who outspend all the others and then you never really hear of any others. It's like the most basic requirement for the job.
In the context of the current discussion (minus the part that's accidentally derailing it by focusing too much on other meanings of the term credit), credit card vs debit card is not relevant at all: they are both denominated in currency, so they are currency. This is not a discussion about cash vs electronic.
Currency vs credit, as it was used some posts up is more like quantifiable vs not quantifiable. It's not about the exact catering expenses of parties thrown ("they had champagne, we have to invite them twice!") it's about inviting or not inviting. Not about the number of hours taking over the children, it's about being there when needed.
Technically, this wording also implies that they ensure that there's always ample supply of imperfections so that they can never run out of improvements to be made ;)
NEVER run out of improvements to be made. Rule number one of getting audited.
Always leave an obvious-once-you-see-it, but minor, defect somewhere for the auditor to latch on to. One they can earmark for you to come up with a plan to address the issue before they grant you the certificate (and which you'll be able to write up in no time because you planned for it).
A good auditor and a company actually taking this stuff seriously can benefit from 27001. That probably accounts for 5% of all 27001 certifications out there.
If you're lucky you get an auditor who's just there along for the ride towards early retirement in a few years, and who'll joke with you and eat your lunch. Had one of those once. Doesn't help your security one bit of course, but it makes audit time more relaxed.
reply