How to rotate a cube
·
When I was around 14–15 years old, I taught myself Intel assembly language (8086/8088 mostly). Not from YouTube or Stack Overflow, as neither existed back then, but through books. I went to the big city, and on the fifth floor of the bookstore, there was a large collection of computer books, including books about assembly. I bought a book about programming in assembly, an introduction to VGA/PS2 video systems, and some other ones. Finally, I downloaded a large tutorial from a BBS, which I read through edit.com on my machine during the evenings.
It was a time when things did not move fast. I spent weeks trying to get a few pixels on the screen rotating in a seemingly 3D space, and even more weeks making a cube that rotated. But finally, it was there. A cube with a different color on each side, rotating around on my screen.
Today, I asked Claude Code to do the same. It took it 20 seconds to come up with a rotating cube running in a browser, with each side a different color (with a bit of transparency, which I didn’t ask for, but oh well).
Does this mean that all the work I did when I was young is obsolete now? Should I, for one, welcome our LLM overlords? Well, no. But this isn’t a pro- or anti-LLM blog post, though.
During my weeks of struggle, I learned many things: how a VGA system works, how to program in assembly, how to project a pixel from a 3D coordinate system onto a 2D screen, and how to rotate a pixel around an origin. How to quickly draw lines from point A to point B. And how to fill shapes quickly. Among many other things.
Now, obviously, I’m still waiting for the day when I can tell my co-workers: “Don’t worry! I know how to rotate a pixel!” But the idea here is that I gained knowledge from the beginning, rather than just skipping through to the end.
I do this a lot. I don’t like not knowing things in computerland. So pretty much everything (JavaScript and functional languages excluded) has my interest. And I believe this is important. I think we should be able to understand the foundations of the things we work with each and every day. We should not get to a point where we do not understand how things work, because that would make us operators, not engineers. And when things break, or when we want to make even better things, we need engineers, not operators.
LLMs have made it very easy to skip all the hard work and just return the results. Acceptable in many cases, but we are losing a lot of foundational knowledge in the meantime. Right now, we are maybe 2–3 years into the AI boom, but what will happen in 10 years? How many developers, or maybe even lawyers or people in other professions, will no longer know much about their profession and just let an LLM do the work in the hope that it spits out correct results? Who validates those results?
That doesn’t mean I don’t love working with LLMs. I actually love it. Instead of focusing on a single thing for days or weeks, I can now devise a plan and let Claude Code do the majority of the work. My job has moved from Architect/Lots of Development/QA to Architect/QA. I just need to verify the results without doing the actual typing, and that can be much quicker than actually generating the code.
It also means I can do multiple things at once without losing control of the context. I hear that this is not possible, but I have seen online poker players play at 10 tables at the same time without losing any control over what to play where and what the situation is at each table. It takes practice and patience and is not something we do, or did, a lot, but LLMs allow us to do this.
But is that sustainable for larger and more complex projects? It depends. I think this can only be done when you are able to understand the foundations. If you only care about the result, then fine: let Claude rotate a cube on your screen and call it a day. But if you need software that needs to be maintainable, efficient, robust, and whatnot, you MUST stay in charge.
I think most engineers will stay engineers, but I am worried about new and younger developers becoming engineers in the future. With LLMs, nobody in their right mind will spend weeks trying to rotate a pixel and, by extension, understand the foundations of what we work with every day. That is worrisome.
As an experiment, i’ve asked Claude Code to rewrite the blog post. It came up with the following:
The Rotating Cube
On LLMs, learning, and the importance of knowing how things work.
When I was around 14 or 15 years old, I taught myself Intel assembly language. Mostly 8086 and 8088. There was no YouTube, no Stack Overflow, and certainly no ChatGPT. There were books, BBSes, and a lot of trial and error.
I remember going to the big city, where a bookstore had an entire floor dedicated to computer books. The fifth floor, to be precise. It was heaven. Shelves full of books about programming, hardware, graphics, and all sorts of things I barely understood but desperately wanted to learn.
I bought books about assembly programming, VGA graphics, and whatever else looked interesting. At some point, I also downloaded a rather large assembly tutorial from a BBS, which I spent countless evenings reading through EDIT.COM on my computer.
Things moved slowly back then.
I spent weeks figuring out how to get a few pixels to rotate in something resembling 3D space. Then I spent even more weeks trying to turn those pixels into an actual cube.
And eventually, there it was.
A rotating cube on my screen. Each side had a different color. Nothing particularly impressive by today’s standards, but to me, it was absolutely amazing.
Fast-forward a few decades.
Today, I asked Claude Code to do exactly the same thing.
Twenty seconds later, I had a rotating cube running in my browser, with each side a different color. It even added some transparency, which I hadn’t asked for, but oh well.
Twenty seconds.
Something that had taken me weeks, perhaps months, of reading, experimenting, debugging, and occasionally wanting to throw my computer out of the window.
Does that mean all the work I did back then has become obsolete? Should I, for one, welcome our LLM overlords?
Well, no.
But this isn’t going to be a pro- or anti-LLM blog post either.
The journey matters
During those weeks of struggling with my rotating cube, I learned an enormous amount.
I learned how VGA graphics worked. How to program in assembly. How to project a point from a 3D coordinate system onto a 2D screen. How to rotate points around an origin. How to draw lines between two coordinates, and how to fill shapes as efficiently as possible.
And plenty of other things along the way.
Obviously, I’m still waiting for the day when I can confidently tell my co-workers, “Don’t worry, everyone! I know how to rotate a pixel!”
That day hasn’t arrived yet.
But that’s not really the point.
The important thing is that I learned all those things while trying to accomplish something relatively simple. I didn’t just end up with a rotating cube. I ended up understanding many of the things required to make that cube rotate.
And that knowledge didn’t disappear when I stopped writing assembly code.
It became part of the foundation on which I built everything else.
Engineers, not operators
I’ve always been curious about how things work. Particularly when it comes to computers.
There’s very little in computerland that doesn’t interest me. Well, JavaScript and functional programming languages perhaps, but we all have our limits.
I like understanding things. Not necessarily knowing every little detail, but understanding the foundations. What’s happening underneath? Why does something work the way it does? What happens when it doesn’t?
I believe that’s an important quality for an engineer.
We work with incredibly complex systems every day. Operating systems, networks, databases, compilers, browsers, distributed applications, and countless other pieces of technology.
Nobody can understand every single detail of every single system. That’s simply impossible.
But we should at least strive to understand the foundations of the things we’re working with.
Because if we reach a point where we no longer understand how things work, we’re no longer engineering them. We’re operating them.
And there’s an important difference.
An operator knows which buttons to press to make something work.
An engineer understands enough of the underlying system to figure out why those buttons sometimes don’t work, how to fix things when they break, and how to build something better in the first place.
We need both, of course. But when something goes horribly wrong, or when we need to create something that doesn’t exist yet, we particularly need engineers.
The problem with skipping the hard parts
LLMs have made it incredibly easy to skip the hard work and jump straight to the result.
And in many cases, that’s perfectly fine.
Not every problem deserves weeks of research. Not every piece of code needs to be written by hand. Sometimes you simply need a rotating cube, and spending twenty seconds generating one is a perfectly reasonable thing to do.
But I think we’re losing something in the process.
We’re losing opportunities to build foundational knowledge.
We’re only a few years into the current AI boom. What happens in another ten years?
What happens when an entire generation of developers has grown up with tools that can generate almost anything they ask for?
And this isn’t limited to software development.
Think about lawyers, doctors, accountants, engineers, and countless other professions. What happens when people increasingly rely on systems that produce answers without necessarily understanding how those answers were produced?
Who validates the results?
Who recognizes when something is subtly wrong?
And perhaps more importantly, who will have the knowledge required to recognize that something could be wrong in the first place?
An LLM can produce code that looks perfectly reasonable. It compiles, the tests pass, and everything seems to work.
But is it correct? Is it secure? Will it scale? Is it maintainable? Does it even solve the actual problem?
Those are questions that still require understanding.
And yet, I love working with LLMs
Now, before anyone gets the wrong idea, I absolutely love working with LLMs.
I use them extensively, particularly Claude Code.
And they have genuinely changed the way I work.
Previously, my job involved a combination of architecture, a lot of development, and quality assurance.
These days, it’s increasingly architecture and quality assurance.
I can devise a plan, describe what needs to be built, and let Claude Code do much of the implementation. Instead of spending hours or days typing code, I spend more time reviewing it, validating the results, and making sure everything fits into the bigger picture.
And that can be significantly faster.
It also allows me to work on multiple things simultaneously.
Some people argue that this isn’t possible, that you can’t maintain enough context to work effectively on several complex tasks at once.
I’m not entirely convinced.
I’ve seen professional online poker players play ten tables simultaneously, keeping track of the players, the bets, and the situation at each table.
That’s not something you can just sit down and do. It takes practice, experience, and a particular way of thinking.
I think working with multiple LLM-driven development tasks is somewhat similar.
You learn to switch contexts, keep track of the important decisions, and recognize when something needs your attention.
It’s a skill that we haven’t really needed to develop before, at least not in quite the same way.
LLMs make that possible.
And I find that genuinely exciting.
But who’s in charge?
The question is whether this approach remains sustainable when working on larger, more complex projects.
And I think the answer is: it depends.
If all you care about is getting a result, then sure. Ask Claude to rotate a cube on your screen, admire the result, and call it a day.
Nothing wrong with that.
But if you’re building software that needs to be maintainable, efficient, secure, reliable, and robust, things become more complicated.
You need to understand what you’re building.
You need to understand the architectural decisions being made, the trade-offs involved, and the implications of seemingly small changes.
You need to recognize when the generated code is unnecessarily complicated, when an abstraction doesn’t make sense, or when something that works perfectly today will become a nightmare to maintain tomorrow.
And you need to be able to challenge the LLM.
Not because LLMs are inherently bad at writing code. Quite the opposite. They’re becoming remarkably good at it.
But because generating code and taking responsibility for a software system are two very different things.
The LLM can do the typing.
It can suggest solutions, implement features, write tests, and help investigate bugs.
But ultimately, you need to remain in charge.
And remaining in charge requires knowledge.
Who will build the next generation of engineers?
I don’t think experienced engineers are suddenly going to forget everything they know because they started using LLMs.
Most of us have spent years, sometimes decades, building up our knowledge. We’ve made mistakes, debugged obscure problems, rewritten terrible code, and spent countless hours figuring out why something that should work simply doesn’t.
That experience doesn’t disappear overnight.
What worries me is the next generation.
The developers who are just starting out.
Because let’s be realistic: nobody in their right mind is going to spend several weeks learning how to rotate a pixel when an LLM can generate an entire rotating cube in twenty seconds.
And why would they?
From a purely practical perspective, it makes absolutely no sense.
But those weeks weren’t wasted.
They taught me far more than how to rotate a cube. They taught me how to investigate problems, how to reason about systems, and how to understand things from the ground up.
That knowledge has been useful throughout my entire career.
And I wonder how future engineers are going to develop that same understanding when the tools they use make it so easy to skip the difficult parts.
I’m not suggesting we should stop using LLMs or deliberately make development harder than it needs to be.
That would be ridiculous.
But I do think we need to find ways to preserve the learning that traditionally happened while struggling with difficult problems.
Because the struggle was never really about producing the result.
It was about understanding how to get there.
And that’s something we shouldn’t lose.
After all, the world probably doesn’t need another engineer who knows how to rotate a pixel.
But it certainly needs engineers who understand what’s happening when they do.