It's actually common for human-written projects to go through an initial R&D phase where the first prototypes turn into spaghetti code and require a full rewrite. I haven't been through this myself with LLMs, but I wonder to what extent they could analyse the codebase, propose and then implement a better architecture based on the initial version.
Let's be real, a lot of organizations never actually finish that R&D phase, and just continue iterating on their prototypes, and try to untangle the spaghetti for years.
I recently had to rewrite a part of such a prototype that had 15 years of development on it, which was a massive headache. One of the most useful things I used LLMs for was asking it to compare the rewritten functionality with the old one, and find potential differences. While I was busy refactoring and redesigning the underlying architecture, I then sometimes was pinged by the LLM to investigate a potential difference. It sometimes included false positives, but it did help me spot small details that otherwise would have taken quite a while of debugging.
If you write that first prototype in Rust, with the idiomatic style of "Rust exploratory code" (lots of defensive .clone()ing to avoid borrowck trouble; pervasive interior mutability; gratuitous use of Rc<> or Arc<> to simplify handling of the objects' lifecycle) that can often be incrementally refactored into a proper implementation. Very hard to do in other languages where you have no fixed boilerplate marking "this is the sloppy part".
Rust is a language for fast prototyping? That’s the one thing Rust is absolutely terrible at imo, and I really like the production/quality/safety aspects of Rust.
You can have cryptographically signed data caches without the need for a blockchain. What a blockchain can add is the ability to say that a particular piece of data must have existed before a given date, by including the hash of that data somewhere in the chain.
Still, it might be interesting information to have access to, as someone running the model? Normally we are reading the output trying to build an intuition for the kinds of patterns it outputs when it's hallucinating vs creating something that happens to align with reality. Adding in this could just help with that even when it isn't always correlated to reality itself.
Part of the issue with phones is that they are already controlled by the Google/Apple duopoly, and hence heavily optimized for constant distraction and addiction. These laws only cement that duopoly and provide fewer means to build more friendly platforms.
While I don't appreciate the implementation of "security" generally involving monopolization, I think it's important to note that you only need age verification for things that are irrelevant to children. In fact the entire point is to exclude children. So a non-Google/Apple device is still perfectly usable for them if (or even specifically because) it cannot pass age verification/attestation. Really the main concern should be use of attestation for banking/government stuff.
I've been hearing talk for years about a "web of trust" system, that could filter spam simply by having users vouch for eachother and filtering out anyone not vouched for. However, I haven't seen a function system based on this model yet.
Personally I'd love to add in something like the old slashdot comment model, where people would mark content as "helpful", "funny", "insightful", "controversial" etc, and based on how much you trust the people labeling it, you could have things filtered out, or brought forward.
There is the simpler version that is approximately "you can only get in if someone vouches for you. If a person you vouch for misbehaves you get punished as well". That's effectively a "tree of trust" with skin in the game. And it's incredibly successful, used in lots of communities, crime rings, job recommendations, etc.
Any attempt to generalize this by allowing multiple weak vouches instead of a single strong one, or allowing people to join before getting vouched for, or removing the stakes in vouching for someone, etc. always end up failing for fairly predictable reasons. No matter how much cool cryptography you add
Wouldn't that be easy to bypass by just adding one or two proxy accounts? Say person A invites me (a bad actor). I could invite a second throwaway account, with which I invite a third throwaway account. I do bad things on my third account. Could you reasonably punish person A for this? You'd first have to prove that the throwaway accounts all belong to me.
No one has to proof anything. If A invites B and B invites C who acts openly bad, you can remove all parties at once and maybe revoke on appeal. All up to the community. Otherwise it would be indeed simple to defeat. But before banning A, one can also just give a Warning. No restrictions here in principle, but I am also open for concrete implementations that work well.
The point is that either there has to be a limit for how much you get punished for the acts of your grandchildren, which leaves room for motivated abusers to work around your system, or people can expect to be banned for basically no fault of their own if they ever invite anyone, in which case your system is DOA.
The point is, it is a balance each community has to find on their own. In reality this means adjusting depending on incidents. But if A invites B who openly does bad things, it very much is the fault of A to drag this person into the community.
Some of the social media systems, including Bluesky, started as invite-only, but that was only ever really for rate-limiting and in particular there were no negative consequences for inviting someone who was subsequently banned.
reply