This is a great point. I'm really concerned about it. Most people seem to have poor taste and like what is most generic because generic is familiar.

100%, poorly architected software is really difficult to make secure. I think this will extend to AI as well. It will just dial up the complexity of the code until bugs and vulnerabilities start creeping in.

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.

I'm not even talking about poorly architected software. They are finding vulnerabilities in incredibly well-engineered software. The Linux kernel is complex not because it's poorly written. It's complex because of all the things it needs to do. Rhat makes it beyond the ability of a human to comprehend and reliably work with it.

There are different degrees of well-engineered software. It's almost impossible for humans to do a good job with a large codebase. Some software is just too complex for any human or machine to implement correctly.

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.

> It doesn't fit into LLM context windows and there aren't enough attention heads to attend to every relevant part.

That's for one pass. And that pass can produce a summary of what the code does.

But the summary is likely to summarise out the details which makes the code vulnerable.

I suspect it will converge on minimal complexity software. Current software is way too bloated. Unnecessary complexity creates vulnerabilities and makes them harder to patch.

Which in turn is bad for vibe coding

I'm skeptical of the whole thing, it almost seems like a marketing campaign to encourage developers to use more tokens.

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.

>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.

"Claude write a one-way function. Wait, no, not like that!"

Yep. Good quality, succinct code saves time and money. Always has and always will.

I had an epiphany about the software industry when I stayed at my parent's place and used a microwave that had the worse UX of any machine I had ever seen. Basically there was no start button, there was no way to increment the timer after you started, there was no '10 second or 1 minute preset' like every other brand and the only way I could figure out to make it 'work' would turn on a super loud fan which would keep running even after the Microwave had been stopped; I had to pull the plug on the thing to make it stop.

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 <popular electronics company>" 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.

> Crypto signature library written from scratch.

That's a sentence every white hat cryptography enthusiast loves to hear lol.

It's a very simple signature algorithm. They're welcome to try and crack it. If there is an issue with it, it shouldn't be hard to identify within those few hundred lines. Nobody found any issues in the last 5 years though.

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.

> What's wrong with hedging?

To be (an actual) hedge, something needs to be very solidly understood (by the purchaser), a very solid investment in its own right, and either reverse correlated or independently correlated specifically with a particular asset being hedged.

And not based on analysis of one "hedging" scenario, because both are going to be owned over a huge distribution of scenarios.

Probably the worst indicator of an investment being credible, is a promoter who has to stoop to the floor to ask "What's wrong with hedging?", as if that manipulative bon mot was ever in question, or was the relevant question.

If a motivated promoter can only make a very bad case, believe them.

And, if an "expert" attempts to get respect for their work from non-experts, instead of from other experts, there is something very wrong. Because the former makes no sense.

--

If you don't know how to get respect from experts, study more, and figure out how to trash what you have. Counterintuitive. But if you have anything original right, thats how to find it. Identify it. Purify it. And be in a better position to build again, with just a little more leverage, and repeat. Or communicate it clearly to someone qualified to judge it.

You won't have to persuade anyone.

If you have to persuade someone, either you don't have something, or you don't understand what you have well enough to properly identify and communicate it.

You have ambition. You have motivation. You have interest. You follow through and build. That is it. Don't stop. Ego derails ambition. Kill your darlings. Keep going.

Why would experts care about my product? There's no big money behind it. The big money has to come in first, then the experts come later to tell the big money whatever they want to hear. Maybe they want to hear the truth maybe not... Either way the paymaster always hears what they want.

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.

You are leaving something out then. Which you allude to.

Bravo on five years! I recently solved a problem that took me over 30. I originally thought, 3-5 months maybe, then 3-5 years, ... I am happy it didn't take 50. I have killed a lot of my own darlings.

Well apparently you know what you are doing, I am sure you have something.

I have found the best language models are great at attacking things. You may have already done that, but if not its worth a try. Free brutality.

The crypto dev community has a strange idea that working with binary is superior. For many algorithms, it's not. It just obfuscates what's happening and the performance advantage is negligible... Especially in the context of all the other logic in the system which uses far more resources.

I didn't know that Protobuf wasn't canonical but even without this knowledge, there are many other factors which make it an inferior format to JSON.

Also, on a related topic; it seems unwise that essentially all the cryptographic primitives that everyone is using are often distributed as compiled binaries. I cannot think of anything more antithetical to security than that.

I implemented my own stateful signature algorithm for my blockchain project from scratch using utf8 as the base format and HMAC-SHA256 for key derivation. It makes it so much easier to understand and implement correctly. It uses Lamport OTS with Merkel MSS. The whole thing including all dependencies is like 4000 lines of easy-to-read JavaScript code. About 300 lines of code for MSS and 300 lines for Lamport OTS... The rest are just generic utility functions. You don't need to trust anyone else to "do it right" when the logic is simple and you can read it and verify it yourself! Simplicity of implementation and verification of the code is a critical feature IMO.

If your perfect crypto library is so complex that only 10 people in the world can understand it, that's not very secure! There is massive centralization and supply chain risk. You're hoping that some of these 10 people will regularly review the code and dependencies... Will they? Can you even trust them?

Choosing to use a popular cryptographic library which distributes binaries is basically trading off the risk of implementation mistake for the risk of supply chain attack... Which seems like a greater risk.

Anyway it's kind of wild to now be reading this and seeing people finally coming round to this approach. I've been saying this for years. You can check out https://www.npmjs.com/package/lite-merkle feedback welcome.

> I didn't know that Protobuf wasn't canonical but even without this knowledge, there are many other factors which make it an inferior format to JSON.

If strict typing and versioning are useless to you, sure.

While protobuf comes with the strict parser built in, it's certainly possible to work with JSON in such a way that it is effectively strictly typed and versioned. These factors aren't really a "key difference" between the two formats, so much as an ergonomic one, imo

I've been talking about 'complexity' for years but business people just didn't get it. Now software development has become almost entirely about complexity management so now I'm hoping that they will finally understand what software engineering actually is. I hope they will finally start valuing engineers who can reduce complexity.

I was always into software architecture and I was dreaming to be a software architect but after completing university, the position was on the way out.

I've been advocating to minimize the number of dependencies for some time now. Once you've maintained an open source project for several years, you start to understand the true cost of dependencies and you actually start to pay attention to the people behind the libraries. Popularity doesn't necessarily mean reliable or trustworthy or secure.

I'll agree with that, and you would think it's common sense for any competent engineer, but for many people it's just an afterthought. Including senior and lead engineers. General matters like security are a political liaison, how can you raise the alarm/advocate for critical security improvements as an IC without making people around and above you look bad? How can you justify time invested into these things without raising the alarm? At the same time, you can't just ignore glaring security holes. It's a fine line to walk, and actually being realistic about the possibilities has found me nothing but enmity from peers and superiors due to it seeming like I'm throwing them under the bus.

In general, management was to see progress. I've come to find that technical details like these are an afterthought for most engineers, so far as the deadlines are being met.

It's one of these things that are under the water, tech side jobs. Everyone has to be on board, if your peers don't give a fuck you're just an annoyance and will be swimming counter-current.

Can relate. It's like; if you're less rigorous than the CTO, they would think you're incompetent. If you're more rigorous than the CTO, they would think you're overly pedantic; not pragmatic enough.

Agree. This is one of the major takeaways I've had from writing Go over the years -- which is even a Go proverb [0], "a little copying is better than a little dependency." Fortunately, LLMs make writing your own implementations of little dependencies super easy too.

[0]: https://go-proverbs.github.io/

I started a project on Expo recently and my god, a thousand dependencies later, it was running.