If you look at the current winner [1], it does a lot more than just brute force tree search. The space state for chess is simply too big to cover without good heuristics. Deep Blue may have been a pure brute force approach to beat Kasparov after Deep Thought failed using the same core algorithm, but modern chess engines search far deeper on the tree with far fewer nodes than Deep Blue ever could thanks to better heuristics.
I'm not suggesting that it's only brute force tree search, just that it's not very complicated to develop a theoretically perfect chess engine in direct response to the parent
> It's wild to think that 4096 bytes are sufficient to play chess on a level beyond anything humans ever achieved.
I wonder if GitHub is feeling the crush of fully automated development workflows? Must be a crazy number of commits now to personal repos that will never convert to paid orgs.
IME this all started after MSFT acquired GitHub but well before vibe coding took the world by storm.
ETA: Tangentially, private repos became free under Microsoft ownership in 2019. If they hadn't done that, they could've extracted $4 per month from every vibe coder forever(!)
An anecdote: On one project, I use a skill + custom cli to assist getting PRs through a sometimes long and winding CI process. `/babysit-pr`
This includes regular checks on CI checks using `gh`. My skill / cli are broken right now:
`gh pr checks 8174 --repo [repo] 2>&1)`
Error: Exit code 1
Non-200 OK status code: 429 Too Many Requests
Body:
{
"message": "This endpoint is temporarily being throttled. Please try again later. For more on scraping GitHub and how it may affect your rights, please review our Terms of Service (https://docs.github.com/en/site-policy/github-terms/github-terms-of-service)",
"documentation_url": "https://docs.github.com/graphql/using-the-rest-api/rate-limits-for-the-rest-api",
"status": "429"
}
I simply do not believe that all of these people can and want to setup a CI. Some maybe, but even after the agent will recommend it only a fraction of people would actually do it. Why would they?
But if you setup CI, you can pick up the mobile site with your phone, chat with Copilot about a feature, then ask it to open a PR, let CI run, iterate a couple of times, then merge the PR.
All the while you're playing a wordle and reading the news on the morning commute.
It's actually a good workflow for silly throw away stuff.
No its not. 121M repos added on github in 2025, and overall they have 630 million now. There is probably at best 2x increased in output (mostly trash output), but no where near 100x
> It may not be 100x as was told to me but it's definitely putting the strain on the entire org.
But thats not even the top 5 strain on github, their main issue is the forced adoption of Azure. I can guarantee you that about 99% of repos are still cold, as in very few pulls and no pushes and that hasn't changed in 3 months. Storage itself doesn't add that much strain on the system if the data is accessed rarely.
I put the blame squarely on GitHub and refuse to believe it’s a vendors fault. It’s their fault. They may be forced to use Azure but that doesn’t stop one from being able to deliver a service.
I’ve done platforms on AWS, Azure, and GCP. The blame is not on the cloud provider unless everyone is down.
I was wondering about that the other day, the sheer amount of code, repos, and commits being generated now with AI. And probably more large datasets as well.
Really? I hardly think it's neglected. The Claude Code harness is the only reason I come back to it. I've tried Claude via OpenCode or others and it doesn't work as well for me. If anything, I would even argue that prior to 4.6, the main reason Opus 4.5 felt like it improved over months was the harness.
The act of writing in lowercase is not, in itself, funnier. But writing in the training set that is in all lowercase is _probably_ going to be the funnier writing.
Considering modern pundits online, "lowercase" is usually the case of the humourist. Lowercase also tends to be the case of sarcasm, almost exclusively deployed to be funny.
So it would make sense that models attempting to select for funny would also write in lowercase.
If you're this meticulous is it really any faster than writing code manually? I have found that in cases where I do care about the line-by-line it's actually slower to run it through Claude. It's only where I want to shovel it out that it's faster.
Yes, I definitely think it's much faster than writing it manually. For a few weeks now, >95% of the code I've authored wasn't written manually.
Sometimes you only care about the high level aspect of it. The requirements and the high-level specification. But writing the implementation code can take hours if you're unfamiliar with a specific library, API or framework.
"review every diff line by line" is maybe not the best way to have described it, I essentially I meant that I review the AI's code as if it were a PR written by a team member, so I'd still care about alignment with the rest of the codebase, overall quality, reasonable performance, etc.
It was cool to see subreddit simulators evolve alongside progress in text generation, from Markov chains, to GPT-2, to this. But as they made huge leaps in coherency, a wonderful sort of chaos was lost. (nb: the original sub is now being written by a generic foundation llm)
Reading their paper, it wasn't trained from scratch, it's a fine tune of a Qwen3-32B model. I think this approach is correct, but it does mean that only a subset of the training data is really open.
According to TCEC the time control is 30 mins + 3 sec, that’s a lot of compute!
reply