Here's a good one for you:
"Explain the double slit experiment which way variation"
If they say anything about leaving two straight lines, then it fails. Just tried Gemini, and it failed.
This is an extremely common misconception that has spread all throughout the internet, and so it is baked into the training data. The real answer is that there are multiple ways to do which way double slit experiments, but Einstein's thought experiment proves it's impossible for any of them have an interference pattern, as that would violate Heisenburg's Uncertainty Principle.
Somehow, not leaving an interference pattern became twisted into leaving a specific pattern of two lines, which then falsely implies that quantum objects lose their quantum behavior in certain circumstances. The field of quantum physics becomes so much simpler to understand once you realize that all of this is hogwash.
The best reference I can find for where this myth started is a documentary about quantum physics that tries to connect it with mysticism. On the other hand, Wikipedia actually has it correct. In its "which way" section in the double slit experiment page, it correctly says "A well-known thought experiment predicts that if particle detectors are positioned at the slits, showing through which slit a photon goes, the interference pattern will disappear".
I'll add to that: you are more likely to have a good experience if it has a lot of relevant data that it was trained on. You are also more likely to have a good experience if errors don't cause major issues.
So one-shotting a game of Snake should be great (tons of training data, errors are easily caught because it's a small program). Similar with building a lot of web UI front end, or one-shotting a personal project. On the other hand, I haven't been convinced that it's good enough to maintain large codebases or assist with niche topics that are not very well documented.
I'm one of those developers, and I think it makes sense to write documentation for Claude and I have no issues with that.
The point of self-documenting code isn't to get rid of the documentation. Instead, it's to integrate it into the code. This fixes the two biggest problems with documentation. First, that the code will often be updated and documentation left behind, making it useless. And second, that English and code are intertwined in the same document, making you constantly switch mental contexts of how you are reading. So no, I don't consider developers who write documentation to be inferior. If anything, I value documentation even more, and the purpose of self-documenting code is to make the documentation better, not get rid of it.
With Claude, the documentation you make for Claude is just fine as it doesn't run into any of the above two problems. The documentation isn't being left behind, because you add to it instead of the code. And it's not intertwined with code, because you are just writing English for Claude, you are not writing code in-between.
While I haven't had this issue with Gmail, I recently got a new computer and the first two weeks for full of moments like this. It's shocking to me how much we've let popups go rampant on everything. Perhaps the worst offender is Windows update, as it won't even let you use your own computer without clicking through 10 screens refusing all sorts of products they are trying to push on you.
The author is definitely not inventing a problem. I ran into this issue at work this month.
We were using WPF, which is C# combined with XAML. I needed to call some async code. First, I tried to call it from synchronous code. That compiled correctly and seemed okay, but then I got vague crashes, and after doing research, I found everyone was like "don't ever call an async function from a sync function" for that exact reason. So instead, I had to change whatever called that to be async, and then whatever called that to be async, and so on. The solution I ended up having to go with was literally changing the code in over a hundred places. This is legacy code that I touch as little as possible, and instead of the one line fix that it felt like it should have been, async turned it into over a hundred small changes throughout the entire project.
I'm not saying there isn't a better approach. I'm pretty new to async/await code as I've been doing asynchronous code through threads my whole programming career. I don't think WPF is a good technology, so maybe some newer tech has solved it better. But what I can say is that this problem was not invented, it is a real problem and it caused a simple change to become a complicated one.
There are two types of "brainrot" that are related but not the same. Essentially brainrot is anything that is anti-thinking.
The first type of brainrot is what happens when you let other things think for you and your thoughts and opinions become not your own. AI is anti-thinking because you can let the machine think for you. Social media is anti-thinking because you can let other peoples' opinions think for you.
On the other hand, memes actually communicate ideas. For example, The Simpsons Ralph meme "I'm in danger" and the dog on fire "This is fine" memes both represent understanding being in a dangerous situation while doing nothing about it. Star Trek was actually way ahead of its time with the episode "Darmok and Jalad at Tanagra" which was about a culture that used memes as communication.
So what do you get when you combine brainrot ("anti-thinking") with memes? You get brainrot memes, which is the second type of brainrot. For example, 6-7. 6-7 doesn't communicate ideas. It doesn't mean anything. Instead, it communicates the opposite of an idea. So when someone says "6-7", they are embracing using language in an anti-thinking way. In this way, brainrot memes can be thought of more as an anti-meme. It's as contagious as an idea, but since it doesn't contain any information, it acts more like a virus. So brainrot memes are essentially mind-viruses that embrace the lack of thinking that comes with brainrot.
They really aren't all that different from each other. One is imaginary things that might one day be possible, and the other is imaginary things that won't ever be possible.
And even then, that can swap between the genres. Scifi often contains FTL tech, which from what we know is almost certainly impossible so it's actually more like fantastical magic. Meanwhile, fantasy can have hard rules for its magic, in which case it acts more like technology that we haven't discovered yet. I haven't read it yet myself, but I've heard of Wizard's Bane, where a programmer is transported to a magical land and becomes really powerful because he treats the magic system like a new programming language.
Other things I've noticed is that scifi tends to involve spaceships and is more mystery oriented, whereas fantasy tends to take place on the ground and is more hero's journey oriented. But even these aren't defining traits. Plenty of scifi books involve investigating alien planets and many contain the hero's journey (including the original Star Wars if you count that as scifi). Meanwhile plenty of fantasy books are on some sort of ship (Narnia - Voyage of the Dawn Treader) and many are more mystery oriented (Harry Potter for example).
Personally, I think a better line of division is hard vs soft. Was the world created first with actual rules and the characters molded to fit the world (Dune, Lord of the Rings)? Or were the characters created first and the rules are bent to create the story that is being desired to tell (Star Trek with its technobabble, Star Wars's prequels and sequels, the entire universe of Harry Potter)?
I agree, and one place I've observed this is in quantum physics. The double slit experiment is an experiment where you shine light through two slits, and instead of the expected two bands, it makes a wave-like interference pattern. This single experiment changed how we view all of physics. However, nearly every source targeted at laypeople claims that there is a variation where you can put a detector on one of the slits and it will show two bands. This is false.
One clue is that these claims never detail on what this "detector" is. There are various types of detectors, and instead of showing a two band pattern they show a single slit interference pattern. By not giving specifics, the claim becomes much harder to disprove. This may not be malicious though, as the source of the faulty claim is likely the miscommunication of a thought experiment proposed by Einstein. Einstein proved by thought experiment that any detector couldn't show an interference pattern, which is easily twisted into the incorrect claim that it does show the two band pattern that people initially expected.
Even with all that, it's simply hard to refute. Like you said, it requires rigorous technical arguments, specifically as the faulty claim didn't specify what kind of detector they use. So the layperson has to choose between <some detector makes shape you'd expect> and <multiple complex existing detectors makes different shape>.
In the end, to a layperson, it wouldn't even seem to be all that important. And yet, almost all of the misunderstandings people have about quantum physics come from this one faulty claim. This claim makes it seem like some objects have quantum behavior, and some don't, and that you can change an object from quantum to non-quantum by detecting it. When in reality, all objects have quantum behavior, we just don't usually notice it.
She graduated with a computer science degree in January, and then her dad passed away. The estate was a mess so she ended up spending time figuring that out. Then, we found and fixed a medical issue that had been draining her energy. She's doing a lot better now, but as a result she has an 8 month gap on her resume. She also never took an internship so that she could finish a semester earlier with summer classes. So now she's absolutely screwed for phase 1.
She switched to phase 2 recently. She got a hit for software support. She got rejected, but the person was like "Why aren't you applying for programming jobs, since you like programming?" They set her up for an interview for an actual programming job, and said her lack of experience wasn't an issue because they had a lot of pull, and that they would offer her a test where she could prove herself. She spent the next several days preparing non-stop for the interview, only for the same guy to be angry at her for not having multiple significant projects on Github and refused to even give her the test.
After that we thought about continuing phase 2, but we both felt like it was just a waste of time, especially after the last experience. She's had previous experience tutoring and I've written some instructional books, so we've now just decided to ignore the job market and form an LLC related to teaching. She'd be a great programmer, and it's really stupid that no one wants to give her a chance, but at some point you just figure the job market is so irrational that we should be able to beat it by doing it ourselves.
If they say anything about leaving two straight lines, then it fails. Just tried Gemini, and it failed.
This is an extremely common misconception that has spread all throughout the internet, and so it is baked into the training data. The real answer is that there are multiple ways to do which way double slit experiments, but Einstein's thought experiment proves it's impossible for any of them have an interference pattern, as that would violate Heisenburg's Uncertainty Principle.
Somehow, not leaving an interference pattern became twisted into leaving a specific pattern of two lines, which then falsely implies that quantum objects lose their quantum behavior in certain circumstances. The field of quantum physics becomes so much simpler to understand once you realize that all of this is hogwash.
The best reference I can find for where this myth started is a documentary about quantum physics that tries to connect it with mysticism. On the other hand, Wikipedia actually has it correct. In its "which way" section in the double slit experiment page, it correctly says "A well-known thought experiment predicts that if particle detectors are positioned at the slits, showing through which slit a photon goes, the interference pattern will disappear".