Whenever this topic comes up I am reminded of the black and white picture of all the scientist of 19th century together. Each individual in that photo had contributed something to human knowledge. It feels like in 19th century we believed in our scientists and advancing our knowledge. I feel today celebrities are given more importance than our scientists. The best minds of our century are focused on extracting value from rest of the population.
The era of scientists being celebrities is done for the simple reason that it's not possible for a single human to advance our knowledge. Breakthrough papers are published by large groups who build on knowledge created by even larger groups.
Also, science used to directly correlate with improvements in life standards. Nowadays we see advancements in science (AI, psychology) used to actively reduce the standard of life.
This points out a limitation of traditional web-based search (not limited to Google, any major search engine suffers the same issue): it's difficult to chain together a set of related questions and generate a tracking history of the results without maintaining an independent record of that yourself.
Sure, it's pretty low-friction to do this by opening a document on most platforms,[1] but using an LLM chatbot not only automates this but provides a synopsis of the findings, and if history's any guide, lowered frictions such as this tend to be the way people tend to move.
__________________________________________
Notes:
1. Though I'll note that opening a free-form text file on mobile OSes can be stubbornly difficult, let alone actually entering text into them. Even the simple act of copying and pasting text is remarkably higher-friction than on a desktop. In many ways the Web has gone vastly backward from text-based, CLI clients where I can 1) open my whole session in a terminal multiplexer (screen, tmux), 2) fire up a text-based web browser (w3m, lynx, etc.), and 3) just wholesale grab site metadata or result summaries and dump that to a textfile. Yes, you need a keyboard to do this efficiently, but keyboards and text-manipulation are just inherently so far superior to touch-based or speech-based interfaces it's not even funny. Touch and voice are convenient, for fast, very shallow uses. But not powerful.
> But it's expensive, complicated and time-consuming to maintain - and both a source of and recipient of endless waves of spam and scams. It's an endless pile of data to hold onto, FOREVER, as well.
They should let others do email. The more email service providers we have the better it is for everyone
I used memos which has similar feature set. One day I lost my hard drive and I had to restore from s3. Turns out the backup I had was incompatible with latest version of memos app.
Since then I just gave up on web based tools for notes. I just want to save my notes and be able to recover them when things go wrong. A simple directory with markdown files and hugo blog allows me to do that.
Since this is largely/almost entirely for private data with occasional publicly accessible content through share links, this is a good candidate to be rebased onto remoteStorage, which gives you auth and storage for free, and there's always an escape hatch for the user to have access to their data—and permit other apps to access it, too.
Begs the question if we should move on to minimal microservices so that whole project lives in context of llm. I hardly have to do anything when I'm working with small project with llm.
Why not take it a step further? Make each function in the codebase its own project. Then the codebase can fit into the context window easily. All you have to do is debug issues between functions calling each other.
I don't think it's a joke about left-pad, but the idea that the complexity increases tremendously when you take a cloud of "small" things all communicating with each other. You've just pushed the complexity elsewhere. Claude can easily crunch the small microservice, but you're pushing the complexity to communications issues, race conditions, etc.
Oddly enough I constantly run into the same issue on monolithic codebases too.
Things could just be one file but they end up being 12. I had to look through 12 levels of indirection for a single boolean recently. Twice, on two separate projects in the same week.
At least in a single codebase, that issue is at least theoretically solvable. At least the indirection wasn't split across 12 repos!
Like I said, if your work is already contained neatly inside one microservice then it doesn't matter.
The same would be true in a monolith: The context to understand what's happening would be contained to a few files.
When the work starts crossing through domains and potentially requiring insight into how other pieces work, fail, scale, etc. then the microservice model blows up complexity faster than anything, even if you have the API documented.
Ironically this is accidentally begging the question - that breaking them up into LLM context windows would be good because it would be to fit them in LLM context windows.
Maybe you're right but I'm aghast at how much of engineering over the last 15 years has been breaking up working monoliths to fit better within the budget of an external provider (first it was AWS). Those prices can change.
There are good reasons to use microservices but so often they're used for the wrong reasons.
I've done the opposite, moving multiple tightly coupled repos into a single monorepo. Saves the step of the llm realizing there's a bigger context, finding the repo, then also scanning/searching it. Especially for fixes that are simply one line each in two repos.
I'm a fan of the monorepo in general, even before LLMs. If using git it leverages git's best feature IMO, the commit as a snapshot of the entire repo. I've worked on so many projects where tightly coupled things are split across repos because it's thought of as a best practice, and it just makes it more difficult to figure out what code you are running.
Generally speaking no. Treat your IP (the code that runs your business, makes your business competitive or special) as precious and don't make it subservient to infra. It should be in the format (code, architecture, structure) that best serves it.
reply