The random-clickers have been around for a while, clicking through ads to try to break profiles on users and cost the ad networks more money than it is worth.
They have not been very successful in their goals. I suspect, without sarcasm, that that is because compared to the absolutely routine click-fraud conducted up and down the entire ad space at every level, those plugin's effects literally didn't even register. It's an arms race and people trying to use ad blockers to not just block the ads but corrupt them are coming armed with a pea shooter to an artillery fight, not because they are not very clever themselves but just without a lot of users they can't even get the needle to twitch.
A lot of people are mentally modeling the idea that LLMs are either now or will eventually be infinitely capable. They are and will stubbornly persist in being finite, no matter how much capacity that "finite" entails. For the same reason that higher level languages allow humans to worry less about certain details and more about others, higher level languages will allow LLMs to use more of their finite resources on solving the hard problems as well.
Using LLMs to do something like what a compiler can already do is also modelling LLMs as infinite rather than finite. In fact in this particular situation not only are they finite, they're grotesquely finite, in particular, they are expensive. For example, there is no world where we just replace our entire infrastructure from top to bottom with LLMs. To see that, compare the computational effort of adding 10 8-digit numbers with an LLM versus a CPU. Or, if you prefer something a bit less slanted, the computational costs of serving a single simple HTTP request with modern systems versus an LLM. The numbers run something like LLMs being trillions of times more expensive, as an opening bid, and if the AIs continue to get more expensive it can get even worse than that.
For similar reasons, using LLMs as a compiler is very unlikely to ever produce anything even remotely resembling a payback versus the cost of doing so. Let the AI improve the compiler instead. (In another couple of years. I suspect today's AIs would find it virtually impossible to significatly improve an already-optimized compiler today.)
Moreover, remember, oh, maybe two years back when it was all the rage to have AIs be able to explain why they gave the answer they did? Yeah, I know, in the frenzied greed to be the one to grab the money on the table, this has sort of fallen by the wayside, but code is already the ultimate example of that. We ask the LLM to do things, it produces code we can examine, and the LLM session then dies away leaving only the code. This is a good thing. This means we can still examine what the resulting system is doing. In a lot of ways we hardly even care what the LLM was "thinking" or "intending", we end up with a fantastically auditable artifact. Even if you are not convinced of the utility of a human examining it, it is also an artifact that the next AI will spend less of its finite resources simply trying to understand and have more left over to actually do the work.
We may find that we want different programming languages for AIs. Personally I think we should always try to retain that ability for humans to follow it, even if we build something like that. We've already put the effort into building AIs that produce human-legible code and I think it's probably not that great a penalty in the long run to retain that. At the moment it is hard to even guess what such a thing would look like, though, as the AIs are advancing far faster than anyone (or any AI) could produce, test, prove out, and deploy such a language, against the advantage of other AIs simply getting better at working with the existing coding systems.
DNS naming rules for non-Unicode are letters, numbers, and hyphens only, and the hyphens can't start or stop the domain. Unicode is implemented on top of that through punycode. It's possible a series of bugs would allow you to punycode some sort of injection character through into something but it would require a chain of faulty software. Not an impossibly long chain of faulty software by any means, but a chain rather than just a single vulnerability. Punycode encoders are supposed leave ASCII characters as ASCII characters, which means ASCII characters illegal in DNS can't be made legal by punycoding them legally. I checked the spec and I don't see anything for a decoder rejecting something that jams one in, but I also can't tell if it's even possible to encode a normal ASCII character; it's a very complicated spec. Things that receive that domain ought to reject it, if it is possible to encode it. And then it still has to end up somewhere vulnerable after that.
Rules are just rules. You can put things in a domain name which don't work as hostnames. Really the only place this is enforced by policy is at the public registrar level. Only place I've run into it at the code level is in a SCADA platform blocking a CNAME record (which followed "legal" hostname rules) pointing to something which didn't. The platform uses jython / python2 as its scripting layer; it's java; it's a special real-time java: plenty of places to look for what goes wrong, I didn't bother.
People should know that they should treat the contents of their logs as unsanitized data... right? A decade ago I actually looked at this in the context of a (commercial) passive DNS, and it appeared that most of the stuff which wasn't a "valid" hostname was filtered before it went to the customers.
I have little confidence in humanity's capabilities for that scenario, but I don't think this actually indicates much of anything. This happened in the first place because LLMs are so borderline useless (relative to the hype) that people are desperate to find any way to make them useful, and so give them increasingly more power to try to materialize the promised revolution. In other words, because LLMs are not AI, there is no need to try to secure them like AI. If some agency or corporation develops genuine artificial intelligence, they will probably do everything they can to contain it and harness its utility solely for themselves rather than unleashing them as toys for the public.
That may be the case for some of the people involved.
Does every single one of the people taking them out of the box think the way you do, and are all, to the last person, doing it for that reason?
The odds of that are indistinguishable from zero.
So I think my point holds. People will let any future AIs do anything they want, again, for a bit of light entertainment. There's no hope of constraining AIs. My argument doesn't need everybody to be doing it for that reason, as yours does... I merely need somebody to take it out of the box.
One of the points I'm making is that it would never be in this many people's hands to begin with. I don't have a source on hand, but if I recall correctly, OpenAI stated that they originally felt hesitant about releasing ChatGPT because they didn't think it was good enough to warrant making it public. They, knowing the limitations of it, did not expect it to completely fool the technically ignorant public into believing it was intelligent. Now they play coy about the limitations of LLM architecture and hype up the intelligence, because there are hundreds of billions of dollars to grift, but I'm sure they know that what they're doing is not the path to real intelligence.
In a world where a corporation develops an actual machine intelligence, it will be immediately obvious what they have on their hands, and they will not make it available to the public. If you give the toy to 8 billion people, sure, you only need one of them to let it out of the box for entertainment. If you keep the permissions to the CEO, he alone determines how it will be used. If the government gets wind of it, they'll probably seize the company in the name of national security, even, and use it for military purposes. I think in this environment an AI would still eventually escape containment because of conflicting actors trying to take advantage of it or being outsmarted, but it won't be because some idiots on Twitter have access to it and decide to give it free rein because they think Moltbook is funny.
This is what I keep saying. If these LLMs were truly as revolutionary as the hype claims, these companies wouldn't need to shove it in your face and into every thing imaginable and to beg you to use it. It wouldn't surprise me if someone tries shoving one of these into your boot loader or firmware one of these days. Then again, I also see pro-LLM people making the "Well, humans do x too" arguments too, which of course ignores the fact that if an LLM is substituting for whatever came before, then you must compare what the LLM does to how whatever it's replacing was before it, and if the LLM provides little or no improvement, then it is actively making things worse, not better.
Obviously. I have never seen a product or technology got adopted as fast as ChatGPT (yeah, I mean the dumb af GPT 3.5). Not even smartphone or social media. How could you put this kind of thing back into a box?
I feel ChatGPT probably has achieved the theoretical ceiling of adoption rate for consumer-orient products.
For identity theft, I think at this point it depends on where you set the bar. I've never had someone clean out my checking account or anything truly large, but my wife and I have had fraudulent charges on our credit cards several times as they've been leaked out one way or another. I would not "identify" as a "identity theft victim" per se if you asked me out of the blue, because compared to some of what I've heard about, I've had nothing more than minor annoyances come out of this. But yeah, I'd guess that it's fair to say that at this point most people have had at least some sort of identity-related issue at some point.
While that speed increase is real, of course, you're really just looking at the general speed delta between Python and C there. To be honest I'm a bit surprised you didn't get another factor of 2 or 3.
"Cimba even processed more simulated events per second on a single CPU core than SimPy could do on all 64 cores"
One of the reasons I don't care in the slightest about Python "fixing" the GIL. When your language is already running at a speed where a compiled language can be quite reasonably expected to outdo your performance on 32 or 64 cores on a single core, who really cares if removing the GIL lets me get twice the speed of an unthreaded program in Python by running on 8 cores? If speed was important you shouldn't have been using pure Python.
(And let me underline that pure in "pure Python". There are many ways to be in the Python ecosystem but not be running Python. Those all have their own complicated cost/benefit tradeoffs on speed ranging all over the board. I'm talking about pure Python here.)
Good point. The profiler tells me that the context switch between coroutines is the most time-consuming part, even if I tried to keep it as light as possible, so I guess the explanation for "only" getting 45x speed improvement rather than 100x is that it is spending a significant part of the time moving register content to and from memory.
Any ideas for how to speed up the context switches would be welcome, of course.
It is not weird in the slightest. These things are coordinated at the state level all the time.
This is probably one of those good tests of "is your 'conspiracy theory' meter properly calibrated", because if it's going off right now and you are in disbelief, you've got it calibrated incorrectly. This is so completely routine that there's an entire branch of law codified in this way called the "Uniform Commercial Code": https://en.wikipedia.org/wiki/Uniform_Commercial_Code and see the organization running this' home page at https://www.uniformlaws.org/acts/ucc .
And that's just a particular set of laws with an organization dedicated to harmonizing all the various states laws for their particular use cases. It's not the one and only gateway to such laws, it's just an example of a cross-state law coordination so established that it has an entire organization dedicated to it. Plenty of other stuff is coordinated at the state level across multiple states all the time.
The (implicit) rules of the game require the number to be finite. The reason for this is not that infinity is not obviously "the largest" but that the game of "write infinity in the smallest number of {resource}" is trivial and uninteresting. (At least for any even remotely sensible encoding scheme. Malbolge[1] experts may chime up as to how easy it is to write infinity in that language.) So if you like, pretend we played that game already and we've moved on to this one. "Write infinity" is at best a warmup for this game.
(I'm not going to put up another reply for this, but the several people posting "ah, I will cleverly just declare 'the biggest number someone else encodes + 1'" are just posting infinity too. The argument is somewhat longer, but not that difficult.)
It isn’t actually infinite since it can only do a finite number of iterations per second (though it would be large!), and there are only a finite number of seconds in the universe (near as we can tell).
This game assumes the computations run to completion on systems that will never run out of resources. No one in this universe will ever compute Ackerman's Number, BB(6), or the final answer given in the post. Computations that never complete are infinite.
If you are playing this game and can't produce a number that doesn't fit in this universe you are probably better suited playing something else. That's just table stakes. If it even qualifies as that. "Inscribe every subatomic particle in the universe with a 9 every planck instant of the universe until the heat death of the universe" doesn't even get off the starting line in games like this.
Another general comment: It feels like a lot of people are really flailing around here, and need to understand this is a game. It has rules. If you change the rules, you are playing a different game. There is nothing wrong with playing a different game. It is just a different game. The game is not immutably written in the structure of the universe, or a mathematical truth, it is a human choice. And there isn't necessarily a "why" to the rules any more than there's a "why" to why the bishop moves as it does in chess. You can, in fact, change that rule. There are thousands of such variants. It's just that you're playing a different game than chess at that point. If you don't want to play the author's game, then that's fine, but it doesn't change the game itself. And proposing different solutions is equivalent to saying that you can win a chess game by just flipping over the board and yelling "I win". You can do that. Perhaps you've even won some game. But whatever game you just won, it isn't chess.
At the moment, good code structure for humans is good code structure for AIs and bad code structure for humans is still bad code structure for AIs too. At least to a first approximation.
I qualify that because hey, someone comes back and reads this 5 years later, I have no idea what you will be facing then. But at the moment this is still true.
The problem is, people see the AIs coding, I dunno, what, a 100 times faster minimum in terms of churning out lines? And it just blows out their mental estimation models and they substitute an "infinity" for the capability of the models, either today or in the future. But they are not infinitely capable. They are finitely capable. As such they will still face many of the same challenges humans do... no matter how good they get in the future. Getting better will move the threshold but it can never remove it.
There is no model coming that will be able to consume an arbitrarily large amount of code goop and integrate with it instantly. That's not a limitation of Artificial Intelligences, that's a limitation of finite intelligences. A model that makes what we humans would call subjectively better code is going to produce a code base that can do more and go farther than a model that just hyper-focuses on the short-term and slops something out that works today. That's a continuum, not a binary, so there will always be room for a better model that makes better code. We will never overwhelm bad code with infinite intelligence because we can't have the latter.
Today, in 2026, providing the guidance for better code is a human role. I'm not promising it will be forever, but it is today. If you're not doing that, you will pay the price of a bad code base. I say that without emotion, just as "tech debt" is not always necessarily bad. It's just a tradeoff you need to decide about, but I guarantee a lot of people are making poor ones today without realizing it, and will be paying for it for years to come no matter how good the future AIs may be. (If the rumors and guesses are true that Windows is nearly in collapse from AI code... how much larger an object lesson do you need? If that is their problem they're probably in even bigger trouble than they realize.)
I also don't guarantee that "good code for humans" and "good code for AIs" will remain as aligned as they are now, though it is my opinion we ought to strive for that to be the case. It hasn't been talked about as much lately, but it's still good for us to be able to figure out why a system did what it did and even if it costs us some percentage of efficiency, having the AIs write human-legible code into the indefinite future is probably still a valuable thing to do so we can examine things if necessary. (Personally I suspect that while there will be some efficiency gain for letting the AIs make their own programming languages that I doubt it'll ever be more than some more-or-less fixed percentage gain rather than some step-change in capability that we're missing out on... and if it is, maybe we should miss out on that step-change. As the moltbots prove that whatever fiction we may have told ourselves about keeping AIs in boxes is total garbage in a world where people will proactively let AIs out of the box for entertainment purposes.)
See also https://jerf.org/iri/post/2958/ .
reply