The Goodreads of music. I'm a lifelong music nerd and have developed habits for finding and curating good music, both new and old. I'm codifying my habits and heuristics for discovering new music into an AI-powered social platform that can be used by anybody to widen their horizons in terms of music they listen to and to share their taste with others. https://waxnerd.com/adnan
Might happen. Or not. Reliable LLM-based systems that interact with a world model are still iffy.
Waymo is an example of a system which has machine learning, but the machine learning does not directly drive action generation. There's a lot of sensor processing and classifier work that generates a model of the environment, which can be seen on a screen and compared with the real world. Then there's a part which, given the environment model, generates movement commands. Unclear how much of that uses machine learning.
Tesla tries to use end to end machine learning, and the results are disappointing. There's a lot of "why did it do that?". Unclear if even Tesla knows why. Waymo tried end to end machine learning, to see if they were missing something, and it was worse than what they have now.
I dunno. My comment on this for the last year or two has been this: Systems which use LLMs end to end and actually do something seem to be used only in systems where the cost of errors is absorbed by the user or customer, not the service operator. LLM errors are mostly treated as an externality dumped on someone else, like pollution.
Of course, when that problem is solved, they're be ready for management positions.
> The biggest lesson that can be read from 70 years of AI research is that general methods that leverage computation are ultimately the most effective, and by a large margin.
Is this at all ironic considering we power modern AI using custom and/not non-general compute, rather than using general, CPU-based compute?
The "bitter lesson" is extrapolating from ONE datapoint where we were extremely lucky with Dennart scaling. Sorry, the age of silicon magic is over. It might be back - at some point, but for now it's over.
the way by which things will scale is not only limited to the optimization of low level hardware but also just by brute force investment and construction of massive data centers, which is absolutely happening.
The transformer architecture IS the bitter lesson. It lets you scale your way with more data and computational resources. It was only after the fact that people come up with bespoke algorithms that increase the efficiency of transformers through human ingenuity. Turns out a lot of the things transformers do is completely unnecessary, like the V cache, for example, but that doesn't matter in practice. Everyone is training their model with V caches, because they can start training their bleeding-edge LLM today, not after they did some risky engineering into a novel architecture.
The architectures before transformers were LSTM based RNNs. They suck because they don't scale. Mamba is essentially the successor to RNNs and its key benefit is that it can be trained in parallel (better compute scaling) and yet Mamba models are still losing out to transformers because the ideal architecture for Mamba based LLMs has not yet been discovered. Meanwhile the performance hit of transformers is basically just a question of how many dollars you're willing to part with.
In 2025 and beyond it is my sincere hope that we stop lauding articles that merely present problems without providing any substantive thoughts on how to solve them.
I'm not going to say if this author is successful or not, but isn't the first step to addressing a problem identify there is one? Step 0 of stop, drop, and roll is to say to yourself "You know what, I think I'm on fire."
The first step is being honest about if the problem is even solvable, and second if it is solvable would people really want what the solution means.
This article is dishonest in using a definition of work that excludes the vast majority of work people have done over history. The sexist view that women never work because watching kids, making clothing, washing clothing, preparing meals (all traditional things women did in various societies) was not real work, while the things men did (hunting, fishing) was real work.
> "you have to do things and not all will be pleasant."
This is arguing that there is no difference between being a slave and being a free human because both have to prepare food, chop wood, wash dishes.
"I own a house, I will put the bins out because I want my house to be rat-free and smell nice" is fundamentally different from "my master orders me to put the bins out and if I don't I will be punished" and from "my employer orders me to put the bins out and if I don't I will become unemployed, homeless, unable to get food, so I am coerced to do it and have no choice".
You are arguing that the choice is meaningless because labour and work and employment are all the same, and the author is arguing that the choice is everything.
Can you quote the definition of work that the article uses and how it excludes women's labor? I don't think you actually read the whole article.
But in terms of steps, yes the problem of capitalist exploitation is solvable. Of course the 1% don't really want that solution which is why they try so hard to perpetuate the myths the author takes on.
Between the bad layout and how obviously wrong it was in the early paragraphs I'll admit to not finishing. They were building up a strawman of capitalism to knock down, and I couldn't read it anymore.
Which is to say I can't quote their definition, but it was clearly leading to the sexist one. (elsewhere people are using a labor vs work distinction which I'm going to contend comes from the same sexism and isn't a useful distinction)
Hey I must miss something certainly as I don’t see what is the substantive thoughts shared in this comment that would mitigate this issue of unmerited laud for mere careful exposition of a perspective. Surely it’s just me missing the point.
The reality is that people LOVE reading articles like this. They love sharing articles like this. Anthony Burgess wrote a wonderful preface to a clockwork orange which I consider inline with this concept in which he wrote:
"Unfortunately there is so much original sin in us all that we find evil rather attractive. To devastate is easier and more spectacular than to create. We like to have the pants scared off us by visions of cosmic destruction. To sit down in a dull room and compose the Missa Solemis or The Anatomy of the Melancholy does not make headlines or news flashes."
All the anti-capitalist doom lit out there has its place, but all of the adults all agree that its intellectually dishonest. This article is just calling out something with no attempt to improve or offer a way forward (thank you to the parent comment for calling this out). Its even ignoring that there are many people who actually enjoy the state of affairs.
In our case, we do a lot of client-side computing (for data privacy reasons). We also support hashing, and real-time events. These all have different implementations per language that aren't trivially scaffolded.
There is a distinction between Twine games, or choice-based games, and parser games, which are typically called Interactive Fiction games. One provides a pre-set list of choices at branches of narrative, while the other provides a world that the user can explore and manipulate via a palette of text commands.
Wait, Twine is _not_ for making "text adventure" style games with a palette of text commands? Somehow I was getting the idea that it was, but when used for shorter stories authors just didn't want to call it "text adventure". but we're actually talking about a different feature set of the game software entirely?
Twine does not lend itself to making Infocom style games easilly. It is more like Choose Your Own Adventure books in that at its simplest it is "do you want to go left or right?" style choices.
However, you can use javascript to program more complicated styles of game play.
Yes - Twine is for what's called "CYOA" (after the old Choose Your Own Adventure book series) or "choice based" interactive fiction. That type of IF has its origin in gamebooks, and generally consists of sections of text that you move between by picking from a list of choices ("to open the door turn to section 223, to run away turn to section 543", that sort of thing). Digital tools can add more dynamic elements, but generally it's rooted in the experience of reading/playing a Fighting Fantasy or Choose Your Own Adventure type gamebook.
The other main type of IF is the "parser" kind - that's the Infocom style where the UI is a bit like a command line, you type arbitrary commands, and get dynamic feedback. The main tool used nowadays for making that type of IF is Inform 7, though there are others.
I've been working on a project that largely addresses this need. It's a distillation of knowledge gained from building web apps of my own as well as for startups for the past several years. The stack comprises of React (via NextJS), GraphQL, Express, Node.js, and PostgreSQL - all written w/ TypeScript.
The goal was to provide a hardened boilerplate app with no distinct featureset but at a minimum have things like ORM, user authentication, migrations, as well as a frontend web UI set up so that it could be used as a head-start for any web app projects in the future.
It's built for fast developer experience, while decoupled enough (a la containers) so that it can easily be taken into a kubernetes cluster for scale. (Still a monolith though.)
The project is private now, but happy share it on request. Also happy to answer any questions.
This sounds right up my alley honestly, could you explain a bit more about the affordances you set up for the decoupled container component to allow it to grow from a few containers to an orchestrated K8s cluster? Just some insight into how and when one decides to grow from a container or two to full on clusters would be really good to know.
As for sharing, while it's very generous of you to offer access and I'm certainly interested in using it once it gets a public launch, I'm much more in pursuit of the thinking behind system design choices and better developing the intuition that makes those choices. Honestly the framework you're putting together sounds like it could help a lot of people with similar problems to me though :D
Sure; because it is a monolith, it makes things simpler by having just the one backend container to scale. So it's a matter of making more instances of it available (via # of pod replicas in your k8s cluster) for increasing availability.
You can start using k8s right away, and just have 3 replicas running to start. As you scale, just up the number of replicas (and nodes as you need them) as you go.
Your real bottleneck becomes the database at that point (in addition to any blocking 3rd party APIs you may be using), which I would not host in k8s but use a managed service such as AWS RDS. This bottleneck will make itself apparent later on, depending on your application and the scale you reach. But you should definitely have the resources to cross that bridge once you, if ever, reach it, because you should be dealing with a large number of customers at that point.
Ah gotcha yeah at the small scale(?) scaling we're talking about monolithic applications, being a bit simpler to organize and run, do still make for a compelling solution. That's a great tip regarding how to handle ballooning storage issues via managed cloud offerings (in the weird case I make something that really works) that I hadn't considered. However, it's starting to feel like these scaling questions/solutions are a lot more akin to Factorio bottleneck chasing than I would like haha.
