People are far more empowered today, many more can work near the bleeding edge, and funding can be arranged in different ways than holding on to a patent.

I think the crates trumping other complexity metrics isn't entirely obvious to me. For problem 15 in the OP's post, author says it was too expensive to compute at runtime in the browser. From a human perspective, it's not apparent why, as a large part of the solution is very repetitive. It feels as if there should be a more condensed representation for iterating over problems like that one.

If I may gauge your opinion on it, have you looked into MazeBench? It comes from LLM benchmarking circles, but seems to suggest a search space that's too difficult for LLMs, even with tools, to solve. Curious how much overlap the PS/MIS solvers would have with solving something like this.

I feel like there's an interesting tradeoff of storing/computing cheap representations vs exploring a smaller tree.

Also, what counts as "complexity" in Sokoban puzzles. Does it plateau at a point, where board size/box count starts scaling the solving time more linearly?

I think the UI elements and layout look very similar to how LLMs like to create them. It's hard to describe, but something about the rounded-edge, thick outline buttons equidistantly placed on the side bars, and heavily dependent on tabbed layouts in sub-menus. I'd argue there's parts where menus have too much empty space, which typically hints that a menu hasn't been thought out completely. It's also the most common type of game/dashboard view that LLMs are capable of: canvas in the middle with interactive buttons on the sides.

For an example of an immersive and good looking UI I'd look to something like Sunless Sea. It's a different type of game and is more narrative driven, but it doesn't have any of the more web-like UI qualities.

I think we can at least partially put constraints on other tasks that look fuzzy to us now, but haven't figured out how yet.