I recently decided to learn how to solve the Rubik’s cube. As a self-confessed geek, it felt like something I should be able to do.
I found a pretty good website that breaks it down into eight steps, from “the Daisy” all the way through to “Finish Him!”. I memorised the moves. Pretty soon I could solve it without looking at the website.
It was incredibly disappointing.

I was just mechanically following “algorithms” I’d memorised. No skill, no insight. Pattern match, apply algorithm, repeat.
So I thought, this can’t be how speed cubers do it. Steps 1-3 are painfully tedious. There must be a faster way.
This led me to F2L, solving the first two layers simultaneously. The first resource I found suggested memorising 42 algorithms - my response - yeah, I’m not doign that…
Then I found a few suggestions on solving F2L “intuitively”, which sounded more my style. Maybe this approach would actually involve some thinking.
It’s definitely faster and requires a bit more brainpower, but ultimately? Still pattern matching. I wanted to understand why the algorithms work, not just memorise better ones.
Frustrated, I did what everyone does now. I asked ChatGPT.
After the obligatory “That’s a brilliant insight!” it gave me this analogy:
- Beginner: following GPS directions
- Intermediate: memorised routes
- Advanced: understand the map
- Expert: improvise new routes instantly
I keep coming back to this because it maps so well onto the junior-to-senior engineer journey.
You start out following instructions. At some point you start pattern matching. This problem looks like that problem I solved last year. Eventually the memorised playbook isn’t enough and you start synthesising new solutions from first principles. You develop taste. Judgment. The ability to look at a system you’ve never seen and know where the problems are going to be.
That last part is what I find interesting about coding agents right now. They’re very good at levels one and two. Following instructions, applying known patterns at scale, faster and more consistently (well, most of the time…) than any person could.
And sometimes watching an agent churn out code gives me that same Rubik’s cube feeling. It works. It passes the tests. But I’m just sitting here approving it. What am I even doing here?
But then you hit a problem where the agent can’t see what you see. It solves the ticket but puts the logic in the wrong place. It writes code that works today but will be a nightmare in six months. And you remember what you’re doing here. That’s the difference between mechanically producing a solution and deeply understanding the solution.
For now, experienced engineers are the ones providing the taste and judgment that makes the difference between code that works and code that works well.
I’m never going to be a speed cuber. But maybe, with the help of agents, I might end up being a speed coder…