I would say your reply feels like you didn’t read beyond the first sentence of my comment.

If you did, then I apologise. But my point is accessing that knowledge when AI isn’t available. Not about how AI discovered its corpus to begin with.

I re-read it. I think your thesis is that we ought not to depend on technology in case the infra to support it goes away. Does that capture it?

No. It’s that we shouldn’t depend on AI always being available.

Absolutely we should use all the tools at our disposal which enhances productivity. But that doesn’t mean we shouldn’t also learn how’re to do things for ourselves too.

> It’s that we shouldn’t depend on AI always being available.

I made the general tech-dependence statement, but it sounds like you think it is only AI tech that shouldnt' depend on. I wouldn't worry about it; humanity has proven itself to be INCREDIBLY resilient and adaptable when the things we've come to depend on go away or change materially.

We aren’t just talking about technology, we are talking about knowledge.

Like I said, I have zero issue being “AI first”. 90% of my day-to-day is using AI. But the part I objected to in the OP was “we don’t need to know things because we have AI” (to paraphrase. So I was asking the question: what if AI goes away?

I agree humans are resilient. But that’a not a good excuse for complacency.

I think local AI will distribute the knowledge across the planet, avoiding a single point of failure.

I think we are still a long way from that becoming an option due to the cost of hardware to run even the lower end models. But I do like this prediction of yours

I feel like having a local qwen model that could run without the internet competes with having a local searchable wikipedia. If disaster does strike, we could now recreate a lot of knowledge with a single high end pc

There's much more about humans then there is writing about them, a lot of cultures with oral histories, a lot of nuance in behavior we take for granted, can it all be digitized?

So there's a common dichotomy in software engineering between the "big ball of mud" and "beautiful diamond" patterns. A big ball of mud is a software system that grows through accretion: it often has tangled flow control, data whales, lots of special-casing, lookup tables, and so on. It evolves, it isn't really designed. A beautiful diamond is a software system that is meticulously designed, consistent, oftentimes with tight interdependencies between how it works. Everything is efficient and easy to understand, but if you take one part out of it, it tends to fall apart. Common Lisp is a big ball of mud, Scheme is a beautiful diamond. C++ is a big ball of mud, K&R C is a beautiful diamond. Windows is a big ball of mud, BeOS is a beautiful diamond. Microsoft VSCode is a big ball of mud, Turbo Pascal is a beautiful diamond.

The big ball of mud structure is often taken to be an antipattern: at least, when I Googled this, Gemini told me it's a "haphazard, tangled anti-pattern" and gave me some advice about how to refactor such a software system into a beautiful diamond. But nearly all software systems that people actually use and maintain are big balls of mud. This is because the big ball of mud tolerates partial failure extremely well. It tolerates changing requirements very well. It tolerates parallel development very well. You can change part of it without throwing away the whole thing.

AI is a beautiful diamond. For the most part, if an AI model malfunctions, you have to blow it away and retrain it. Or I guess you can build layers to fix up the output case-by-case, but then you're really building a big ball of mud around the beautiful diamond, and obscuring it in the process.

That's a little worrisome when it comes to durability. Living, enduring systems usually end up becoming a patchwork of mud. Your ability to do this with LLMs are basically limited to LoRa patches and post-processing steps.