I guess we'd have to see the graph with the evolution of paying customers: I don't see the number of potential-but-not-yet clients being that high, certainly not one order of magnitude higher. And everyone already knows OpenAI, they don't have the benefit of additional exposure when they go viral: the only benefit seems to be to hype up investors.
And there's something else about the diminishing returns of going viral... AI kind of breaks the usual assumptions in software: that building it is the hard part and that scaling is basically free. In that sense, AI looks more like regular commodities or physical products, in that you can't just Ctrl-C/Ctrl-V: resources are O(N) on the number of users, not O(log N) like regular software.
Yeah, for instance: even if Trump's bullying works for now, he made sure that most governments in Latin America, including right wing ones, will prioritize uncoupling the country from the US economy. Even if they won't say this quiet part out loud.
4. The community seems to have realized that untangling the mess that is building C/C++ stuff is a fool's errand and seems to mostly prefer to reimplement it in Go
How much does the door help? I think generally people don't follow hygiene to the point that particles anywhere in the bathroom won't get tracked out of the bathroom. Don't get me started on people who touch their phones while eating...
tbh if I start worrying about poop particles in my day to day, I fear I'm one step closer to becoming a germaphobe. plus I feel if that's something that truly worries you, you'd start taking showers after each poop because clearly you will bring some poop particles with you when you leave anyway.
maybe this thread will end up being some kind of revelation, but I very much agree with the person you replied to. If I'm alone, I'm not bothered and the door may as well stay open
Sure, you can't get rid of everything. But you can mitigate a few things, and closing the door is such an easy fix... There's worrying too much, and there's not worrying enough
Is it, though? Apparently the current best practice is just to allow the LLM untethered access to everything and try to control access by preventing prompt injection...
Well it took me 2 full-time weeks to properly implement a RAG-based system so that it found actually relevant data and did not hallucinate. Had to:
- write an evaluation pipeline to automate quality testing
- add a query rewriting step to explore more options during search
- add hybrid BM-25+vector search with proper rank fusion
- tune all the hyperparameters for best results (like weight bias for bm25 vs. vector, how many documents to retrieve for analysis, how to chunk documents based on semantics)
- parallelize the search pipeline to decrease wait times
- add moderation
- add a reranker to find best candidates
- add background embedding calculation of user documents
- lots of failure cases to iron out so that the prompt worked for most cases
There's no "just give LLM all the data", it's more complex than that, especially if you want best results and also full control of data (we run all of that using open source models because user data is under NDA)
I already had experience with RAG before so I had a head start. You're right that it's not rocket science, but it's not just "press F to implement the feature" either
P.S. No vibe coding was used. I only used LLM-as-a-judge to automate quality testing when tuning the parameters, before passing it to human QA
You still need to find the correct data, and get it to the LLM. IMO, a lot of it is data engineering work with API calls to an LLM as an extra step. I'm currently doing a lot of ETL work with Airflow (and whatever data {warehouses, lakes, bases} are needed) to get the right data to a prompt engineering flow. The prompt engineering flow is literally a for loop of Google Docs in a Google Drive that non-tech people, but domain experts in their field, can access.
It's up to the domain experts and me to understand where giving it data will tone down the hallucinative nonsense an LLM puts out, and where we should not give data because we need the problem solving skills of the LLM itself. A similar process is for tool-use, which in our case are pre-selected Python scripts that it is allowed to run.
NodeJS, Ruby, etc also have this problem, as does Go with CGO. So the problem is the binary dependencies with C/C++ code and make, configure, autotools, etc... The whole C/C++ compilation story is such a mess that almost 5 decades ago inventing containers was pretty much the only sane way of tackling it.
Java at least uses binary dependencies very rarely, and they usually have the decency of bundling the compiled dependencies... But it seems Java and Go just saw the writing on the wall and mostly just reimplement everything. I did have problems with the Snappy compression in the Kafka libraries, though, for instance
.
The issue is with cross platform package management without proper hooks for the platform themselves. That may be ok if the library is pure, but as soon as you have bindings to another ecosystem (C/C++ in most cases), then it should be user/configurable instead of the provider doing the configuration with post installs scripts and other hacky stuff.
If you look at most projects in the C world, they only provide the list of dependencies and some build config Makefile/Meson/Cmake/... But the latter is more of a sample and if your platform is not common or differs from the developer, you have the option to modify it (which is what most distros and port systems do).
But good luck doing that with the sprawling tree of modern packages managers. Where there's multiple copies of the same libraries inside the same project just because.
If "food" were a singular universally used product, and units of food were totally interchangeable I'd say that food should be treated like a utility. Instead there's a lot of different types of food from ultra-processed crap that's sat on a shelf for years to whole/fresh foods and everything from the skill of the manufacturer/baker/chef to the quality of the ingredients used will result in massive differences in the food and its costs.
That isn't really the case with water and power (or even internet access). Water is water. Electricity is Electricity. There's no artisanal organic Electricity made from the finest ingredients that powers your stuff any better. You either have a safe, functioning product or it isn't. Everyone needs the exact same stuff, it makes sense for the government to supply it. Not everyone needs, or even wants, the same foods.
Food distribution networks might be infrastructure, but POS stores aren't, generally. Drinking water supplies are infrastructure; drinking fountains aren't.
Food production is largely nationalised due to heavy subsidies provided to farmers. Different countries have different policies here, but in my country of Australia it meets the definition of a nationalised industry by everything but name.
Food distribution as not, and again in my country we are having constant investigations into monopolistic anti consumer behaviour by the large supermarkets.
And there's something else about the diminishing returns of going viral... AI kind of breaks the usual assumptions in software: that building it is the hard part and that scaling is basically free. In that sense, AI looks more like regular commodities or physical products, in that you can't just Ctrl-C/Ctrl-V: resources are O(N) on the number of users, not O(log N) like regular software.
reply