It’s literally not possible. It has nothing to do with intelligence. A perfectly intelligent AI still can’t read minds. 1000 people give the same prompt and want 1000 different things. Of course it will need supervision and intervention.
We can synthesize answers to questions more easily, yes. We can make better use of extensive test suites, yes. We cannot give 1000 different correct answers to the same prompt. We cannot read minds.
If the answer is "yes"? Then, yeah, AI is not coming for you. We can make LLMs multimodal, teach them to listen to audio or view images, but we have no idea how to give them ESP modalities like mind reading.
If the answer is "no"? Then what makes you think that your inability to read minds beats that of an LLM?
This is kind of the root of the issue. Humans are mystical beings with invisible sensibilities. Many of our thoughts come from a spiritual plane, not from our own brains, and we are all connected in ways most of us don't fully understand. In short, yes I can read minds, and so can everybody else.
Today's LLMs are fundamentally the same as any other machine we've built and there is no reason to think it has mystical sensibilities.
We really need to start making a differentiation between "intelligence" and "relevance". The AI can be perfectly intelligent, but without input from humans, it has no connection to our Zeitgeist, no source material. Smart people can be stupid, too, which means they are intelligent but disconnected from society. They make smart but irrelevant decisions just like AI models always will.
AI is like an artificial brain, and a good one, but humans have more to our intelligence than brains. AI is just a brain and we are more.
Various cheating to get their conclusions (from the paper):
> To allow for an unobstructed gait recording, participants were instructed not to wear any baggy clothes, skirts, dresses or heeled shoes.
> Due to technical unreliabiltities, not all recordings resulted in usable data. For our experiments, we use 170 and 161 participants for CSI and BFI, respectively. [out of 197]
I wish they had explained what the technical unreliabilities were.
> the technology explicitly promises tomorrows models will be better then todays, which means the skill investment is deflationary
This is just wrong. A) It doesn’t promise improvement B) Even if it does improve, that doesn’t say anything about skill investment. Maybe its improvements amplify human skill just as they have so far.
It’s a sandbox. If your model generates and runs a script for each email in your inbox and has access to sensitive information, you want to make sure it can’t communicate externally.
In this model the spec/scenarios are the code. These are curated and managed by humans just like code.
They say "non interactive". But of course their work is interactive. AI agents take a few minutes-hours whereas you can see code change result in seconds. That doesn't mean AI agents aren't interactive.
I'm very AI-positive, and what they're doing is different, but they are basically just lying. It's a new word for a new instance of the same old type of thing. It's not a new type of thing.
The common anti-AI trope is "AI just looked at <human output> to do this." The common AI trope from the StrongDM is "look, the agent is working without human input." Both of these takes are fundamentally flawed.
AI will always depend on humans to produce relevant results for humans. It's not a flaw of AI, it's more of a flaw of humans. Consequently, "AI needs human input to produce results we want to see" should not detract from the intelligence of AI.
Why is this true? At a certain point you just have Kolmogorov complexity, AI having fixed memory and fixed prompt size, pigeonhole principle, not every output is possible to be produced even with any input given specific model weights.
Recursive self-improvement doesn't get around this problem. Where does it get the data for next iteration? From interactions with humans.
With the infinite complexity of mathematics, for instance solving Busy Beaver numbers, this is a proof that AI can in fact not solve every problem. Humans seem to be limited in this regard as well, but there is no proof that humans are fundamentally limited this way like AI. This lack of proof of the limitations of humans is the precise advantage in intelligence that humans will always have over AI.
> Recursive self-improvement doesn't get around this problem. Where does it get the data for next iteration? From interactions with humans.
It wasn't true for AlphaGo, and I see no reason it should be true for a system based on math. It makes sense that a talented mathematician who's literally made of math, could build a slightly better mathematician, and so on.
AlphaGo was able to recursively self-improve within the domain of the game of go, which has an astonishingly small set of rules.
We're asking AIs to have data that covers the real physical world, plus pretty much all of human society and culture. Doing self-improvement on that without external input is a fundamentally different proposition than doing it for go.
> the real physical world, plus pretty much all of human society and culture
is only a tiny part of the problem (more data plus understanding more rules) and the main problem is "getting smarter".
You can get smarter without learning more about the world or human society and culture. I mean, that's allegedly how Blaise Pascal worked out a lot of mathematics in his teenage years.
My point is that the "getting smarter" part (not book-smart which is your physical world data, not street-smart which is your human culture data, but better-at-processing-and-solving-problems smart) is made of math. And using math to make that part better is the self-improvement that does not necessarily require human input.
I think you're strawmanning my math point from "if you're made of math and can make a trivial improvement in the math, you get a smarter n+1 program that can likely make another trivial improvement to n+2"... to "AI can solve all math" (which is not my point at all).
You seem to be generalizing item #3 from "there are limits to what AI can do with math", to "therefore, AI can't improve any math, and definitely not the very specific kind of math that is relevant to improving AI". That is a huge unjustified logical jump.
Has it ever happened on the path from Enigma to Claude Opus 4.6, that the necessary next step was to figure out a new nth Busy Beaver? Is Opus 4.6 a better Busy Beaver than Sonnet 3.5?
Or is that a mostly unrelated piece of math that is mostly irrelevant to making a "smarter" AI program from where we are today?
This is incorrect. The set paradox it’s analogous to is the inability to make the set of all ordinals. Russel’s paradox is the inability to make the set of all sets.
Technically speaking, because it's not a set, we should say it involves the collection of all sets that don't contain themselves. But then, who's asking...
This is the easiest of the paradoxes mentioned in this thread to explain. I want to emphasize that this proof uses the technique of "Assume P, derive contradiction, therefore not P". This kind of proof relies on knowing what the running assumptions are at the time that the contradiction is derived, so I'm going to try to make that explicit.
Here's our first assumption: suppose that there's a set X with the property that for any set Y, Y is a member of X if and only if Y doesn't contain itself as a member. In other words, suppose that the collection of sets that don't contain themselves is a set and call it X.
Here's another assumption: Suppose X contains itself. Then by the premise, X doesn't contain itself, which is contradictory. Since the innermost assumption is that X contains itself, this proves that X doesn't contain itself (under the other assumption).
But if X doesn't contain itself, then by the premise again, X is in X, which is again contradictory. Now the only remaining assumption is that X exists, and so this proves that there cannot be a set with the stated property. In other words, the collection of all sets that don't contain themselves is not a set.
Let R = {X \notin X}, i.e. all sets that do not contain themselves. Now is R \in R? Well this is the case if and only if R \notin R. But this clearly cannot be.
Like the barber that shaves all men not shaving themselves.
The paradox. If you create a set theory in which that set exists, you get a paradox and a contradiction. So the usual "fix" is to disallow that from being a set (because it is "too big"), and then you can form a theory which is consistent as far as we know.
Perhaps I overstated how related the two were. I was pulling mostly from the Lean documentation on Universes [0]
> The formal argument for this is known as Girard's Paradox. It is related to a better-known paradox known as Russell's Paradox, which was used to show that early versions of set theory were inconsistent. In these set theories, a set can be defined by a property.
Nah I'm a C++ (ex?) enthusiast and modules are cool but there's only so many decades you can wait for a feature other languages have from day 1, and then another decade for compilers to actually implement it in a usable manner.
I am fine with waiting for a feature and using it when it's here.
But at this point, I feel like C++ modules are a ton of complexity for users, tools, and compilers to wrangle... for what? Slightly faster compile times than PCH? Less preprocessor code in your C++.. maybe? Doesn't seem worth it to me in comparison.
Author here. Sadly, this had to be done, otherwise you would not see anything on the chart. I added an extra progress bar below, so that people would not get a wrong impression.
Hey, I really appreciate this site! Independent from my personal opinion on modules, I think it's extremely helpful to everyone to see the current state of development; and you do an excellent job reflecting that.
Thanks <3 Working on this project also made me realize that cpp needs something like crates.io. We are using vcpkg as a second-best guess for cpp library usages, because it has more packages than sites like conan. Also adding support of things like import statement list, shows that there needs to be a naming convention, because now we have this wild mix:
I don't really want to learn how to use the borrow checker, LLM help or not, and I don't really want to use a language that doesn't have a reputation for very fast compile/dev workflow, LLM help or not.
Re; Go, I don't want to use a language that is slower than C, LLM help or not.
Zig is the real next Javascript, not Rust or Go. It's as fast or faster than C, it compiles very fast, it has fast safe release modes. It has incredible meta programming, easier to use even than Lisp.
Writing code without the borrow checker is the same as writing code with the borrow checker. If it wouldn't pass the borrow checker, you're doing something wrong.
Rusts borrow checker is only able to prove at compile-time that a subset of correct programs are correct. There are many correct programs that the BC is unable to prove to be correct and therefore rejects them.
I’m a big fan of Rust and the BC. But let’s not twist reality here.
> There are many correct programs that the BC is unable to prove to be correct and therefore rejects them.
There are programs that "work" but the reason they "work" is complicated enough that the BC is unable to understand it. But such programs tend to be difficult for human readers to understand too, and usually unnecessarily so.
The BC will not incorrectly approve an incorrect program.
But the BC does not approve all correct programs. Because some patterns which are indeed perfectly correct and will never explode the BC is not able to prove that and therefore the BC rejects the program.
The BC is effectively incompatible with typical video game patterns. The whole level/frame life cycle is effectively unsupported by the Rust BC. As just one example.
there’s a miscommunication. programs that pass the borrow checker all are memory safe (assuming code marked unsafe is sound). This means that all memory unsafe programs are excluded. but some memory-safe programs are excluded too.
I've never seen `split_off_mut` but I do use `split_at_mut` quite often to solve similar issues. Using a slice instead of using a Vec directly also tends to greatly simplify things.
I also don't fully understand the buffer reuse example. Why would you want to store references to a string after the string ceases to exist?
Come on that’s not true. How would you write and LRU cache in rust? It’s not possible in idiomatic rust. You either need to use unsafe or use integer indices as a poor man’s pointer.
Indices are fine. Fixating on the “right” shape of the solution is your hang-up here. Different languages want different things. Fighting them never ends well.
It shouldn’t come up because it’s not sufficient. How would systemd prevent local JavaScript code from sending DNS, http, webrtc network requests when it’s opened in the users browser?
We can synthesize answers to questions more easily, yes. We can make better use of extensive test suites, yes. We cannot give 1000 different correct answers to the same prompt. We cannot read minds.