- LLMs trained on OUR copyrighted works and OUR open source code which was licensed for human use (MIT license explicitly says for "Persons").

- A monetary system that has been centralizing opportunities and creating an asymmetric playing field due to the Cantillon Effect caused by government and institutional money creation.

Either of these points on its own entitles us to as much UBI money as we need.

I think even without AI or any technological progress, the monetary system is itself enough to create the kind of massive centralization that we've been seeing. People have been saying that for years before LLMs. People are now blaming AI for the fact that some people can't get jobs but it's not the root cause.

Software devs won't be able to get jobs as plumbers either because the plumbing sector in many countries has become insanely regulated... Society has been fundamentally corrupted.

I only see two ways forwards;

- Communism with UBI (closer to what we have now)

- Abolish all regulations and have Capitalism again.

Like for complex bugs in messy projects, it can get stuck and waste thousands of tokens but if your code is clean and you're just building out features. It's basically bug free, first shot. The bugs are more like missing edge cases but it can fix those quickly.

It's crazy how good coding agents have become. Sometimes I barely even need to read the code because it's so reliable and I've developed a kind of sense for when I can trust it.

It boggles my mind how accurate it is when you give it the full necessary context. It's more accurate than any living being could possibly be. It's like it's pulling the optimal code directly from the fabric of the universe.

It's kind of scary to think that there might be AI as capable as this applied to things besides next token prediction... Such AI could probably exert an extreme degree of control over society and over individual minds.

I understand why people think we live in a simulation. It feels like the capability is there.

https://saasufy.com/

They're good at solving well-defined puzzles under time constraints. It's interesting because that was the benchmark for hiring software engineers at big tech. The tech interview was and still is about fast puzzle-solving. Nothing about experience, architecture or system design in there... I suspect that's why it has a bias towards creating hacks instead of addressing the root cause.

Also, with skills, you can organize your files in a hierarchy with the parent page providing the most general overview and each child page providing a detailed explanation of each endpoint or component with all possible parameters and errors. I also made a separate page where I list all the common issues for troubleshooting. It works very well.

I created some skills for my no-code platform so that Claude could access and make changes to the control panel via HTTP. My control panel was already designed to update in real-time so it's cool to watch it update as Claude creates the schema and adds dummy data in the background.

I spent a huge amount of effort on refining my HTTP API to make it as LLM-friendly as possible with flexible access control.

You can see how I built my skills marketplace from the docs page if anyone is interested: https://saasufy.com/

This implementation simplicity came with tradeoffs; I chose a stateful signature scheme (Lamport OTS with Merkle Signature Tree) which I could fully understand and easily verify from first principles. It's actually one of the simpler aspects of my blockchain.

Originally, I wanted to use SPHINCS+ (stateless) but there were no good libraries for it at the time in the Node.js ecosystem and TBH, I didn't fully grasp some of the finer technical details at the time; it was clear it would have been a much more complex and error-prone solution.

That said, statefulness in the signature scheme creates complexity elsewhere and shifts the risk to the clients. There are risks that a poorly implemented client could lead to key-reuse. Also, there are concurrency scenarios which can't be supported securely (e.g. if the user tries to sign multiple transactions in parallel from two different clients from the same wallet/private key).

And yes, I did run several versions of Claude including Claude 4.6 sonnet against both:

https://www.npmjs.com/package/lite-merkle https://www.npmjs.com/package/lite-lamport

It said it found 2 non-critical issues with lite-lamport but neither was exploitable.

I had to add comments to the README so that anyone who tries to run an AI against the code knows that I'm aware of these concerns but they are not issues. I did fix a non-critical signature malleability issue but that was more to appease the AI since there was no exploit for it at the level of the blockchain; it basically ignored any extra trailing bits at the end of a valid signature which could in theory lead to replay scenarios with an extended signature with junk data at the end but not possible in practice since transaction IDs are unique and deterministic. There's no possibility of double-spend.

I look forward to running the new Claude Mythos on it when it comes out. In the meantime, if anyone can find an issue with it, please let me know.

Humans almost always underestimate the cost of features. I bet we could massively reduce the amount of code and complexity of the Linux Kernel if we abandoned the account system entirely and just made it one user with root access and just relied on containers to provide isolated sandboxes.

A lot of features just crept in over long periods of time and weren't re-evaluated as needs changed. I think the approach I'm suggesting would have been horrible 20 years ago but makes more sense now in the era of cloud virtualization. The account system and containerization aspects are basically different implementations which solve the same modern problem of environment isolation... Nobody really needs per-file access restrictions anymore... The cloud era is more like "here is Bob's environment, here is Alice's environment" and they can do whatever they want with their own container/sandbox. The account permission systems is more of an annoyance than a solution for most use cases.

Everyone just latched onto the existing abstractions and could not fully re-imagine them in the context of changing requirements. LLMs are even worse than people in that sense.

That said, I think supporting a wide range of possible hardware is a real challenge for the Kernel and that part will always require an amount of code proportional to the amount of hardware supported.

At some point, people will have to decide to stop the complexity creep and try to produce minimal software.

For any complex project with 100k+ lines of code, the probability that it has some vulnerabilities is very high. It doesn't fit into LLM context windows and there aren't enough attention heads to attend to every relevant part. On the other hand, for a codebase which is under 1000 lines, you can be much more confident that the LLM didn't miss anything.

Also, the approach of feeding the entire codebase to an LLM in parts isn't going to work reliably because vulnerabilities often involve interactions between different parts of the code. Both parts of the code may look fine if considered independently but together they create a vulnerability.

Good architecture is critical now because you really need to be able to have the entire relevant context inside the LLM context window... When considering the totality of all software, this can only be achieved through an architecture which adheres to high cohesion and loose coupling principles.

My experience as a software engineer, including with Claude Code itself, is that the more code you have, the more bugs there are. It quickly turns into a game of Whac-a-Mole where you fix 1 bug and 2 new bugs appear.

Looking at the functionality of Claude code. There is no way it requires 500k lines of code as claimed. It would make it very difficult to debug... Though it seems they have a team of 10 people which is a lot for a CLI wrapper.

It's more likely that somebody ran the real code through an agent to intentionally obfuscate it into a more complicated form before they leaked it. This is trivial to do with LLMs. You can take any short function of a couple of lines and turn it into a function hundreds of lines long which does the exact same thing.

It's actually a great way to obfuscate code in the AI era because LLMs are good at creating complexity and not good at reducing it. I've done tests where I ask Claude to turn a simple 1 line function which adds two numbers together into a 100 line function and when I asked it to simplify it down, it couldn't reduce it back to its original simple form after multiple attempts. I had to explicitly tell it what the original form of the function was for it to clean up properly. This approach doesn't scale to a whole codebase. Imagine doing this to an entire codebase, it would take more time for you to read and understand each function to tell the LLM how to clean it up than just re-generating the entire app from scratch.

The problem with large amounts of code is not only that it's harder to maintain and extend, it's often less performant.

While LLMs can allow us to get more out of bad code, they will allow us to get even more value out of the equivalent good code when it comes to maintainability, reliability and efficiency.

It was a popular brand and I suspect it probably sold well. The mind-boggling dysfunction may not have been obvious at a glance when the consumer made the purchasing decision. The UX was so bad, I still have nightmares about it.

As I was trying to use the damn thing as a user and kept running into one hurdle after another, it triggered a flashback of my experience of debugging complex software as a software engineer and I thought to myself "F***, I chose the wrong career. I'm cooked. The user doesn't care. The user doesn't care AT ALL." In that moment, I understood that getting replaced by AI was the least of my problems. Far bigger problems had been there since the beginning. I just didn't notice them.

I just thought about the software engineer who had to implement this retarded UX... I imagine they would put on their resume "Wrote the firmware for " and it would sound really good. The worst part is that it's probably not even their fault that their work sucks.

Anyway it just made me realize how unmeritocratic this industry is. We could do a great job or a horrible job and most of the time it has nothing to do with career progression and opportunities.

Besides, I am an expert. I studied cryptography at university as part of my degree. I have 15 years of experience as a software engineer including 2 years leading a major part of a $300 million dollar cryptocurrency project which never got hacked... I know why the experts were not interested in my project and after careful analysis, I believe it has nothing to do with flaws in my work.

If anything, it might be because my project doesn't have enough flaws...

At this stage, I hope you're right. I hope I will find the flaws in my projects that I've been looking for after 5 years.

Isn't it a good thing that there exists at least one blockchain in the world which isn't based on the same crypto library used by every other project? What if those handful of libraries have a backdoor? What if the narrative that "you shouldn't roll out your own crypto" is a psyop to get every project to depend on the same library in order to backdoor them all at once at some future date?

Strange how finance people always talk about hedging but in tech, nobody is hedging tech.