186 karma · joined May 22, 2025
Em dashes, semicolons, deftly delving. It’s all just so…facile. We might as well tell ourselves we can tell it’s shopped from the pixels, having seen some shops in our day.
God, who knows. Could it have worked at Wikipedia? Both Wikipedia and SO have the same problem that all the easy work is taken. The article on Silicon looked *pretty* different 25 years ago: https://en.wikipedia.org/w/index.php?title=Silicon&oldid=280...
"A chemical element, in the periodic table Silicon has the symbol Si and atom number 14."
Now it has 127 references. Same with SO. There's just only so many questions to ask about list comprehension but everyone has them. The site was built for a lot, but it wasn't built for new humans having question shaped problems who still wanted to ask those questions.
https://data.stackexchange.com/stackoverflow/query/1926661#g...
This is not a problem that is gonna be solved by a change here or there. That graph says "toes up". Wikipedia has a softer one; it's heading the same direction and it hit the peak before SO did. It's structural. I think a lot of folks imagine "if only we did X, ..." but I am not so sure.
Because if the current system favors the bankers, the previous system sure as hell favored the bankers. Is it the bank runs?
I guess I should say this is all academic now, since we're about a month an a half away from Weimarizing the dollar lmfao. We've been kicking the institutional legs out from the stool for a while and we will discover the virtue of an independent central bank whether we like it or not.
Same thing happens to Wikipedia. The people building the platform pay good money for user study that show, pretty clearly, that trying to contribute to SO/WP is like hitting a brick wall. User study after user study will show the same thing but not give any way to break the logjam.
So then something like the above happens, with identical results each time. It’s glorious. Meanwhile new questions trend to 0.
It’s hard to make reliable, directional assumptions about the kind of self-selection and refusal they saw, even without worrying about the reward dropping 66%.
As you point out, human systems are machines for making do. There is no guarantee that dramatic pressures produce dramatic change. But I think we’ll see something weird, soon.
Developers are refusing to complete the survey or selecting themselves out because they (apparently) don’t want to complete the non-AI task.
The also saw selection effects from a large reduction in the pay for the study (which is an unfortunate confounder here), 150/hr -> 50/hr.
They guess this makes their estimates lower bounds, but the selection effect is complicated (which they acknowledge).
Overall this is a hard problem for them in the current state. It will be challenging to produce convincing year over year analysis under these conditions.
If one can accept failure to follow instructions, then the world is open. That condition does not really comport with how we think about machines. Nevertheless, it is the case.
Right now, a productive split is to place things that you need to happen into tooling and harnessing, and place things that would be nice for the agent to conceptualize into skills.
The issue was that it still was kind of hard to produce crappy mid rate papers, so you kind of needed the infrastructure of a small lab to do that. Now you don’t. The success rate for those mediocre papers produced by grad students and postdocs will go way down. It is possible that will cease to be a useful signal for those early career researchers.
This kind of pattern is gonna get repeated in a lot of sectors when previous practices that were merely unsustainable become unsustained.
Putting that in a `.md` file just means you don’t need to do it twice.
Prior to standardization, you had to become an expert on how the computer did arithmetic in order to do something that required arithmetic. This did not mean simply knowing an approximation for a function which you could program in a language. That is not enough as you point out that is 200 level stuff. If you wanted it to actually work on an actual machine, you would need to understand how the machine itself was actually going to undertake those operations. You had to have a numerical analyst around, or at least someone that had taken a couple of those courses.
Today you can tell me how simple it is to write a sine function, because when I press you for detail details, you can say things like well. It’ll just need to be to the standard or I’ll use a library.
In the 1970s that was not the case. Nothing about computer arithmetic was simple or unified or anything other than requiring an inordinate amount of attention paid to something that was not the object of interest. Lots of organizations that needed to get things done on computers had to hire people and train people to be experts in the arithmetic in a way that we do not have to anymore. Most people programming do not have to think about computer arithmetic in any significant fashion. If you compare this to the 1940s or the 1950s or the 1960s or the 1970s, the picture is very different. If you became a programmer in the 1960s about half of what you were learning was how to make the machine do arithmetic. Need to do a square root? well you better write that function from scratch. Does it also need to be performant? Well, then you’re in trouble.
The amount of intellectual effort, devoted to training programmers of all stripes in computer arithmetic is much less than it was 50 years ago. The fact that it is possible at all for you to boast that you could write that sine approximation and know its bounds and trust those is due to the standardization effort.
I am saying, and I have been saying that we are entering into a similar era, where there are whole categories of concerns, which are local to the machine that most users are not going to have to deal with. Some of these things will have been very central to some people’s identities, like being able to brag about sine approximations. Training is going to change; capabilities are going to change; what it means to be an engineer is going to change.
I’m having fun with the change, personally.
It's why people are hooking Open Claw up to stuff and letting it rip--putting it into a sandbox in a VM in a jail is like getting a brand new smartphone and setting it on Airplane Mode first thing.
We also so far have yet to see anyone successfully sue over software copyright with LLMs—-this is a bit redundant, but we’ve also not seen a user of one of these models be sued for output.
Maybe we converge on the view of the US copyright office which is that none of this can be protected.
I kind of like that one as a future for software engineers, because it forces them all at long last to become rules lawyers. If we disallow all copyright protection for machine generated code, there might be a cottage industry of folks who provide a reliably human layer that is copyrightable. Like Boeing, they will have to write to the regulator and not to the spec. I feel that’s a suitable destination for a discipline. That’s had it too good for too long.
What I’m saying is that we act as though claims about these scaling laws have never been tested. People feel free to just assert that any minute now the train will stop. They have been saying that since the Stochastic parrots.
It has not come true yet.
Tomorrow could be it. Maybe the day after. But it would then be the first victory.
Read what I wrote.
I'm saying is if you bet AGAINST [LLM] scaling laws--meaning you bet that the output would peter out naturally somehow--you've lost 100% so far.
100%
Tomorrow could be your lucky day.
Or not.