I’ve been learning to solve a 3x3 Rubik’s cube with my kid recently.
I already knew the basic layer-by-layer method — enough to solve it, but painfully slow. This time, I wanted to take the opportunity of playing with my child to upgrade the last layer from the beginner method to CFOP — specifically, learning the OLL and PLL algorithms. Stanford has a two-or-three-page tutorial that covers exactly this in the second half: which algorithm goes with which pattern, how to identify orientations — all laid out clearly. Following along, it’s not hard at all.
But I wanted to take a shortcut. I figured I’d have an LLM reorganize the OLL and PLL teaching steps for me, so I wouldn’t have to pore over the PDF myself.
Turns out — it couldn’t do it.
It’s not that it had zero understanding. Every model could discuss the CFOP framework, mention how many OLL and PLL cases there are, and even produce algorithm sequences that looked convincing. The problem was, when you actually picked up a cube and followed its instructions, they didn’t work.
Here a precondition was missing, there the assumed orientation didn’t match the state in your hands. You’d point out the error, it would apologize and try a different explanation, but the new version would go wrong somewhere else. Several rounds of back and forth, and it never converged on a fully correct path.
I tried several mainstream models. Without exception.
In the end, I went back to that Stanford PDF. Two or three pages, following along step by step. A tutorial written by a human — got it right the first time.
This experience left me feeling conflicted.
Because I genuinely rely on LLMs heavily in my daily work, and they perform brilliantly in many scenarios. When coding, they’re a true force multiplier — looking up APIs, debugging, untangling messy logic, all in their wheelhouse. Translation, information synthesis, thinking aids — they do these quickly and well. Sometimes I ask a fairly deep question and the response comes back well-structured, insightful, far more nourishing than most human conversations.
In those moments, you genuinely feel this thing is impressive.
But this very impressive thing, faced with organizing OLL and PLL teaching steps — a task you could knock out just by following an algorithm chart — simply couldn’t get it right. Not completely clueless, just perpetually “almost there.”
Later I realized this isn’t a matter of “occasional mistakes.” It exposes something more fundamental about LLMs.
A 3x3 Rubik’s cube is essentially a strict state machine. 54 stickers, and every single turn changes the entire state. To solve it correctly, you must know precisely what the current state is at every step, whether the algorithm’s preconditions are met, and what state you’ll end up in after executing it. This is a problem that demands exact state tracking and step-by-step verification.
But an LLM isn’t actually “turning” a cube internally. It doesn’t maintain a cube object. It isn’t performing group operations. What it does is generate text that statistically “looks most like a correct answer” based on the vast number of cube tutorials in its training data. It “knows” that a certain OLL pattern most likely corresponds to a certain algorithm, but it won’t verify whether the current orientation actually satisfies the preconditions, nor will it check whether the result is correct after outputting the algorithm. When you tell it the last step was wrong, it doesn’t truly backtrack through a reasoning chain — it just keeps generating new text going forward.
It’s describing the solution, not executing the solution.
The reason the Rubik’s cube exposes this so thoroughly is its brutal characteristic: zero tolerance, instant verification. Right is right, wrong is wrong — all six faces are either solved or they’re not. There’s no room for “close enough.” In this environment, the LLM’s fundamentally statistical nature has nowhere to hide.
This made me rethink a question that had always been fuzzy: how should we actually understand the boundaries of LLM capabilities?
They’re powerful, no question about it. Coding, translation, thinking aids, information synthesis — in these scenarios their value is real and tangible. I benefit from it every day. But there’s a subtle problem: their task boundaries are unclear.
A traditional software tool has explicit boundaries — what it can do, what it can’t. LLMs are different. They’ll take on anything, answer any question, and most of the time the answer is decent. This makes it easy to let your guard down — if it can help me write complex code, surely organizing a few OLL algorithms should be a breeze?
And yet it’s precisely in these places where “it really shouldn’t go wrong” that it does.
This isn’t an isolated case. LLMs are fundamentally probabilistic systems; their output carries inherent randomness. This means the user must always maintain judgment over its output — in domains you know well, you can catch its mistakes; but in domains you don’t, you might not even realize it’s wrong.
So my current understanding is this: an LLM’s most appropriate role, for now, is still as a human assistant. An extraordinarily capable assistant, but an assistant nonetheless. You can’t just throw a task at it and walk away. You must carefully delineate its task boundaries in actual use — which parts can be safely delegated, which parts require human oversight. If you can’t draw that line clearly, those low-level but fatal errors will surface in the most unexpected places.
There’s a deeper layer of reflection too.
The Rubik’s cube experience gave me a vague sense that the current technical paradigm of LLMs may have some kind of structural limitation. Their language understanding and generation capabilities are already staggeringly impressive, but when faced with tasks requiring precise state maintenance and rigorous logical verification, their architecture seems inherently ill-suited. This probably isn’t something that “more training data” or “bigger models” can bridge — perhaps it requires some more fundamental paradigm evolution to cross this threshold.
What exactly that evolution would look like, I don’t know. But I believe that when a problem a two-or-three-page document can teach a human consistently trips up the most advanced LLMs — that fact alone deserves serious attention.
A 3x3 Rubik’s cube turned out to be the most intuitive litmus test for the boundaries of LLM capabilities.