Hacker News new | ask | show | jobs
by chongli 14 days ago
Humans built codebases many millions of lines long, well before LLMs existed. Human memory has not been a restriction on us in a long time.

Look at all the libraries full of books we've built. It's useful for more than mere training sets.

1 comments

I think the trick here is plural; I guarantee no single human knows all 1 million lines. Note this is different than knowing how to orient yourself in a million line codebase quickly.

The limit here I think the ancestor comments are getting at is cognitive load, which is real and measured. We only have so much memory to devote to a "stack" when executing, and it's usually quite constrained.

Note this is different than knowing how to orient yourself in a million line codebase quickly.

Hence my library mention. Humans have been doing this for millennia: orienting ourselves within a library (the physical kind, full of books) and calling upon its information resources as needed to accomplish tasks (research). Ultimately, it's all just one big cache hierarchy. Your short term memory, your long term memory, the book in your hands, the desk at the library, the nearby shelves, the card catalogue, the stacks, the inter-library loan system.

To manage it all, we humans have developed our abilities for abstraction. When we build clean, tight abstractions we reduce our cognitive load. Perhaps the best abstraction we've built so far is the TCP/IP and web stack. We don't need to care at all about the hardware details of a server in order to talk to it. It's such a powerful and airtight abstraction that we take it for granted.

I'd like to hear from more people who have spent a lot of time building with LLMs, because so far what people are saying is that these models do not have the ability to reason about and build the kind of marvellous abstractions us humans have built.

Fair, my mistake.

I've built a lot with LLM's, my experience sort of but not really tracks that. I've had to course correct a few bad abstractions but the larger the code base becomes the better it seems to be at reusing things. Maybe this is because of types, or spec-first development (with OpenAPI), or black box integration testing - but also maybe not. But generally I have to think about the abstractions and let the LLM fill in the details with rare exception.

I built a web-OS, a graphical IDE, and a version control system to replace git, all in about 40,000 lines of highly abstracted Javascript. If you're thinking about how important it is to be able to maintain million-line codebases, I suspect you might have substituted a metric for the actual end goal.
That looks like a nice feat, can you share a repo?

That said, reality at scale always come with details that will break the model, and the main roads when it happens are to ignore/reject any change proposal in the model, go in the mystic quest to reach a model that will fit it all including these new cases with an elegant simple solution, or accommodate special cases on the side until it grows too big or just percolate too fast in the main part to let it be sustainable.

It's a GitHub org: https://github.com/bablr-lang

Basically we've taken the "mystic quest" route, but we now have a pretty damn good data model