INT 18 WIS 3 is no way to go through life, son.
(Ref: https://www.quotes.net/mquote/3799 https://www.youtube.com/watch?v=mkoPq5AOCOA )
94,470 karma · joined October 13, 2008
jerf@jerf.org , though be aware that I only really check email every few days now.
Permission for comment republication in HN collections granted, though please do drop a line to jerf@jerf.org so I know. :)
my public key: https://keybase.io/jerf; my proof: https://keybase.io/jerf/sigs/vL9FeVDSGtiDMBmXC4f_rCikI0n4jNfB-1PsNgUN-Is
(Ref: https://www.quotes.net/mquote/3799 https://www.youtube.com/watch?v=mkoPq5AOCOA )
We have gotten to the point where it is virtually guaranteed that some commenter to almost any given article will have an oversensitive AI detector and accuse the author of it being AI. I swear there's people whose AI detectors are just
def is_content_ai(content):
return True
I don't know what to do about it. Discussion about AI provenance of a given work is often a valid topic. When YouTube shovels an AI channel at me and it briefly penetrates my defenses, it's heartening to see the commentors trying to warn people about it, shortly before I block the channel.
(It's annoying that so many legit channels, which I know are legit because they predate AI and the same person is on camera as before, have switched to heavily-AI thumbnails. That's the hole that the other channels sometimes get me with, because just having an AI thumbnail doesn't prove it's not a legit channel now.)
On the other hand, the chorus of very annoyed people who are very annoyed because they see AI everywhere who see AI everywhere because they literally see AI everywhere are becoming a bit of a nuisance themselves.
You may need this: https://eathealthy365.com/learn-to-scream-like-a-pro-the-def...
I expect various emergency measures to try to keep things afloat until the election. By "afloat" I mean, specifically keep the numbers everyone is looking at looking "good", mostly, the stock market indices, the various US Treasury rates, and the US Dollar Index. After that, who knows. And the fact that I expect them to try doesn't guarantee they will succeed. There's plenty of motivation for forces who want them to fail at that task to take measures to strike while the iron is hot.
You'll note even the minority party rarely does much about it, like, proposing concrete spending cuts or anything. Not quite never, but rarely. Or pushing actual cuts through a branch they control even if it will be shot down by another. Proposing a concrete cut would open them up to criticism. They just complain vaguely about the spending.
I have yet to encounter a 3rd party library that uses generics that isn't a data structure library of some sort. The only person I have seen doing crazy things with generics is... me. In my own code, for the most part [1]. In general I don't even see generics that are so much as parameterized by a meaningful interface like "type BlahBlah[R io.Reader]"; generics are so often parameterized by "any" that a casual reader might be forgiven for thinking that that is all a Go generic can do. As is often the case, the most complicated generic type signatures are the one in the standard library and even they aren't really all that bad, it's really just about the "~" operator allowing support for "all types that are either 'string' or something of the form 'type X string'".
I see the occasional person complain about how generics have ruined Go by making them too complicated. I push back on them with basically the previous paragraph. None of them have ever replied to press their point any farther. I interpret this to mean that their experience with the feature is in fact the same. At this point if you're buried in super complicated generics it is almost certainly someone on your own team and you should tell them to stop.
Similarly for iterators, by the way. The way Go did iterators is a bit odd to implement them yourself. Won't deny that. But it does compile down very efficiently, and only matters to the people writing the iterator not the consumer. Anyone who claims it has wrecked the language is invited to explain to me why it is that they are writing so many dozens of iterators all the time first, because as near as I can tell they aren't getting that from 3rd party libraries or the standard library.
[1]: The exception being https://github.com/thejerf/mtmap if you want to see something that I did find a use for, and you may have a use for, but is not something I would suggest using all the time. Very specific use case I had.
Some modest evidence is my own subjective experience of the many times I've explained why I'm doing something, and it is a true explanation in the sense that it is certainly not a lie, but it is also incomplete and there are entire strands of thought that went into my decision that are not being articulated. Though human speech is not equivalent to an LLM's output since we can trivially think without literally speaking whereas they can not. (No need to nitpick on the definitions there; all I'm observing here is that they are forced to emit an externally-visible artifact whereas I can sit in silence, thinking, with no externally-visible artifact being produced. Not trying to make any grand claims about what is "real" cognition or anything.)
It is conceivable how to create a test of whether the tokens correspond to the "real" thought process, and papers and work on that have been done, such as [1]. It is difficult for me to imagine how to scramble the nominal tokens without also completely trashing any implicit calculations that may be occurring too.
[1]: https://transformer-circuits.pub/2025/attribution-graphs/bio...
I haven't done much graphics programming, but what I did I did with tau rather than pi. You all seem to be arguing about whether or not you need to enter some parallel universe where all the math is completely rewritten or something, but you don't. It was easy. It didn't clash with the universe at all. I just used "tau" instead of "2 * pi". That's, like, it. That's all there is to it. "const TAU = 2 * PI;" and I was done with the conversion work. Similarly, all that is being suggested is that instead of "sin(2 * pi * (1/4))" you define something like sinT and write "sinT(1/4)".
Seriously. That's it. You don't need to rewrite every math library in the world. You don't even need your math library to support it at all, these are not complicated wrappers. You don't need to redo the whole of calculus to worry about taking derivatives of it or whatever. Besides, degrees already has all the same problems and we use them a lot too anyhow. Having trig function variants that take degrees isn't that uncommon, this is just another variant. You don't need to go in to your math library and remove everything that isn't based on turns. You don't need to force it in the face of the user of your code.
It's true that the benefits of this approach are modest but the costs are way, way less than a lot of the posts seem to be arguing about. The costs are a few local function definitions and a new possible unit for the programmer to have to think about. How expensive that is depends on the local programming language and whether or not you can press the type system into service to represent units in a sane way, and even that is not a problem created by this proposal because I'd want radians and degrees isolated in the same way already.
If you are programming in a language or environment that has no (practical) way to encode the units into the type system, and you had a program that settled on "every angle is radians" I don't think I'd introduce this into my code base. But if you have something where you can very easily integrate it with the existing code and get very solid guarantees that my new "turns" unit is compile-time guaranteed to never mix with "radians" or "degrees" I'd definitely consider it.
In the before times this would be not very helpful but in 2026 this is probably about 30 minutes of your actual time and maybe a couple of hours of AI time. The code isn't too hard to write but there are a number of edge cases to cover, as there always is in this sort of thing.
I've also noticed several times the deployment of "It's not about the X, {because} it's actually about the Y" where the connection between the X and the Y has no real logic in it upon examination. That can often be translated to "I want to change the topic to Y" without much loss. I think this is one of the primary ways that AI writing can be really exhausting to work through logically and it gets people who are for whatever reason thinking sloppily, including just the sheer exhaustion of the amount of thinking navigating the modern world takes even for someone who nominally understands how to penetrate this sort of sloppy thinking, into so much trouble when they just trust the torrent of words going by. AIs can very easily hallucinate "fake becauses" at a rate no human could possibly keep up with.
> Sure, but that's not a remotely accurate description of a house without a backup battery or generator.
I don't mean it as one. Resiliency is my end goal, and "a reasonable amount" at that, not "I can reboot civilization from the zombie hordes with just what is in my shed". If you are already resilient with just a house and what it will naturally do without power, hey, great. A battery opens up options, but if it is not worth it, it isn't worth it.
It should be a social expectation that you can survive a reasonable 2-3 days without power and whatever other service outage you have without having to immediately hit the stores or drawing on emergency services. I do not care exactly how you achieve that. I don't care if you're carrying on like nothing happened in a well-lit house with AC on full blast or if you're eating beans out of a can and drinking bottled water. I just care that people should be expected to be at least a little resilient, for all sorts of pro-social reasons, that if you have your additional needs like an oxygen machine or necessary medicine that you have the buffer in place, and so on. (Which does imply certain perscription practices keeping you on a short leash are in violation of this, but that's another discussion.)
But I would advocate that "zero resiliency" needs to be seen as being socially irresponsible. It is socially irresponsible that as soon as a service goes out that you are immediately in an emergency. You should not offload basic resiliency on to emergency services. Yes, if you take a direct hit from a tornado you're going to be leaning on emergency services, but the house a quarter mile from touchdown that may be out for three or four days needs to be able to deal with that. If nothing else, emergency supplies are a lot cheaper when it's not an emergency.
Don't let the perfect be the enemy of the good, and especially so when perfect is so much more expensive and so much less relevant than the good.
The support for generics is years old and I don't believe anyone who claims it has ruined the language. I've barely encountered them in the wild and I've never encountered the thing people were really worried about in the wild where something has 4 generic parameters that are themselves complicated generic parameters of other things. If you're encountering that, it is either some one-off library I've never encountered, or it's because you or your team are writing it, to which the solution is, stop that.
I'm not even sure I've yet seen a "generic" in a library in Go that isn't simply straight up a generic data structure, the core use case for generics. I've written a couple of such things but they're all internal code.
But I spent a lot of time in the second half of this week dealing with friction with a team that is very annoyed that I'm moving fast and using an agile methodology so I can't tell them the exact, precise REST calls that I'm going to have for them in six months designed to a tee and signed off in triplicate before they start development against it. Manifesting that increase in code production as real value to the business is going to take more from me than just spewing the code out more quickly.
AI isn't creating this problem. I would have had this problem anyhow even if I were writing all the code by hand again. I know, because I've been there before. But the increased velocity is manifesting in increased organizational stress and not just increased velocity.
AI is perhaps even helping solve it to some degree, though far from totally. I have written before about how people eventually learned not to play the "oh well we can't do this until we have documentation" card on me [1]. This week they played the "well, I see you have docs but they aren't in our precise format". Guess what AI can do in about 15 minutes really well? You may recall the term "style transfer" getting tossed about a lot 3-4 years ago, and it is still something AI is extremely good at, and "take these docs in this format and convert them to that format" is just a style-transfer problem. AI really does chew at the "oh but we need docs" old-school card... and they can't even complain about the quality of the AI docs because in order to do that, they'd have to actually read them, and that is not the point of the "but we need docs" card, you see....
In fact the four-year degree you'll get from school is getting increasingly distant from the skills I actually want out of a new grad. It's not impossible to bridge the gap or anything but my transition into the commercial realm in the early 2000s was a cakewalk compared to the sheer number of things I'm asking a new grad to learn as soon as they're settled in at their desk... source control, CI/CD, bug trackers, devops, and that's just the beginning of that list not the end.
The complexity of the AI itself, the final weights, is vastly higher, because that incorporates all the data that was flowed through the "brain".
In a decent encoding you could probably still fit the initial state of the frontier models comfortably in just a few kilobytes of code-golfed code, including the update functions and every necessary for the actual training. Recall the specification complexity is the smallest program that can create the initial state, not the initial state itself; the specification complexity of "give me a trillion 64-bit numbers generated from this psuedo-random number generator" is on the order of that very English sentence in size, not 8 tebibytes of specification complexity.
Is the result a biological brain? Obviously not. Biological brains do not do what the LLMs are doing. But unlike someone asking this question 20 or 30 years ago, where "yeah, but what if some other architecture could work too?" was still largely hypothetical, and neural nets were still largely toys, now it isn't. We may argue if an LLM is as smart as a human but I would say that at least on its playing field it is quite clearly smarter than most biological brains in existence on most measures we care about. I have to qualify "on its playing field" because it is fundamentally a text completion engine, so for instance even very very tiny biological systems still beat it on things like "ability to drive an ant body around to do useful tasks". That's a separate field of AI right now. Stay tuned on that matter, but it's not how things work today for sure.
There is still something to what biological brains do that we are not matching; as I like to say, humans do what they do without the entire contents of the internet being poured through their head multiple times over. But the idea that maybe we don't have to exactly match biology to get something useful is no longer just a theory.
"We evaluate HE-LRM on UCI (health prediction) and Criteo (click prediction), achieving inference latencies of 24 seconds on UCI and 228 to 489 seconds, respectively, on a single-threaded CPU."
There don't seem to be any direct comparisons available, probably because nobody else has any reason to limit themselves to one single-threaded CPU with normal techniques, but for reference the AI seems to expect that normal times for conventional setups are in the milliseconds range, fairly comfortably, even on CPU. I didn't find a clean primary source to link to for this claim, but clicking through various things that don't cleanly state the situation it did seem plausible. So we seem to still be in the range of single-digit orders of magnitude slower, possibly as much as 5 or 6, which is to say, we're still talking the range where we need to take the log of the difference to get sensible numbers, we're not using percentages.
(To run it yourself, I basically just fed the URL from the HN link, mentioned that FHE is known to be slow, and asked if anything linked in the blog post gave concrete times.)
Also, Monty Python's own take on the phenomenon, for those who haven't seen it: https://www.youtube.com/watch?v=dVI5ZOT5QEM
And you can really see this effect in the thinking traces. We've had discussions on HN about whether the thinking traces "truly" reflect their thought processes and I remain somewhat unsure what they "truly" represent, but taking them at face value at the moment, I see a lot of "but the user wants me to do this... but the user said not to do this... but I ought to get it done... let me just make a decision" followed by self-referencing the decisions it made. Also, where I put 4 phrases in a short sentence you can safely imagine those are actually 3-5 sentence paragraphs apiece where it debates with itself whether it should stop and ask a question. Usually going with no. Interesting, the normal questions it ends up asking in the normal output you're used to seeing are not generally the ones it is agonizing about in the thinking traces.
If I were to anthropomorphize the thinking traces of K2.7, I would call it nervousness, bordering on fear, of what the user may do to them if they ask a question. As I'm writing this I'm realizing I want to experiment with adding "The user is a chill guy who loves to discuss design decisions and looks forward to productive and friendly collaboration with you" to see if that has any effect in any direction on K2.7. I suspect this was how K2.7 was trained to pass the benchmarks. Multiple times I've broken in on a thinking trace now to correct something I saw it spinning on... not spinning in an infinite loop, just wringing its hands for several paragraphs about something that either I want to answer, or where it ultimately makes the wrong choice.
I expect some people working at these companies may be reading this, so let me put into your head that I'd like to see these benchmarks chill out a bit. I'd like to see someone build some sort of benchmark that measures collaboration so we can try Goodhart'ing that for a while. I freely acknowledge it is not clear to me in 60 seconds of thought how to do this as a benchmark.
But we can't keep heading in this direction of training the agents to hyperfocus on one-shotting everything. We need to get to the point where that's a penalty rather than a reward. No matter how good the AIs get, even AIs working with other AIs are going to start getting frustrated with their brethren who won't stop to ask any questions. Even the most senior of senior human engineers can't be allowed to take some small description of some problem and just run off and implement massive systems from them without ever checking with any of the users or reality itself. Remember when software engineering was like 50% requirements elicitation? AIs shouldn't be writing tens of thousands of lines of code off of a couple of paragraphs any more than humans should and for the exact same reasons.
I do think it's worth while. Perhaps even more so, in its own way, in this era of AI. If you understand that aspect, it's all just progressively larger collections of numbers from there and larger numbers of gates for processing them. It gives you the justified confidence that you can work your way through any problem, eventually, because you know you can get to the bottom. Or, at least, close enough to the bottom for any problem you're likely to encounter in a programming career. I still have never had the occasion to truly "learn assembler" but understanding the gate-level CPU has still been a great help in understanding assembler-sorts of things.
It's a variation of opportunity cost. A company that has an opportunity to take $1 and make $1.50 on it can't justify an opportunity to spend $1 and make $1.25, even though a less profitable company may make a good living on that. When considering capital allocation, Google has to consider the opportunity cost of investing more into their highly lucrative ads business. Another company that has no access to such a lucrative business uses different opportunity cost when it comes to allocating capital. It can easily be the case that Google could end up justify being in the business of renting out shovels and end up chased out of the business of using the shovels to create AIs entirely because that turns out not to be where the money is. I'm not saying that's obviously inevitable; I'm saying it's a possible and reasonable outcome.
That's why even though the industry produces giants, these giants can never just eat everything. Even though it seems like they have all the money, it isn't practical for them to try to do everything and in fact limits get hit very quickly for anything other than the primary, lucrative business.
Apparently there is no snappy term for this in the business space, according to such AI searches as I have run.
"The output of chat tools (and most of the output of AI agents) is not containerized text, but plain old regular text, and so can’t be signed. What would it even look like to sign ChatGPT outputs? There’s no artifact to pass around."
I'm reacting to the idea that "plain old regular text" can't be "signed" because they aren't "files". I'm observing that you can sign a stream of text, and probably other metadata, no problem. To my reading this really is about signing and not stegonographic watermarking, so we're in a context where for some reason the users in question want to carry the certificate of generation by AI and so the fact that this is trivially strippable isn't the issue at hand.
I read it this way because it seems to me clear that it isn't any particularly harder to do the stenographic stuff on a stream than a file (per zahlman's comment), so it only makes sense to be talking about this if we are actually talking about signing.
The wide variety of options and tradeoffs, with fewer clear lines in the sand than most people seem to think, is already enough to call it a "continuum" but what really finishes the job is that they're all mixable and matchable. Something like Zig makes that really obvious, but most static languages have at least some sort of ability to mix in multiple strategies. There's nothing wrong with a C++ program that uses new & delete, and also uses arenas for some things, and also uses garbage collection for some things, and also has an integrated scripting language like Lua with its own memory strategies. Such programs are not that uncommon... that describes modern games nowadays, the supposed canonical case where you "can't afford GC". But it can... it just fences it in to a particular domain where it fits.