I picked up a creativity book expecting a light read between semesters. What I got instead was something that quietly rearranged how I think about engineering itself.
Here's the thing nobody tells you when you start out in AI/ML: the syllabus teaches you tools. It teaches you Python, it teaches you models, it teaches you the math underneath. What it doesn't teach you is the thing that actually separates a good engineer from someone who just knows how to use tools — and that's the part this book is about.
Creativity isn't invention. It's problem-solving.
Most people hear "creativity" and think of inventing something out of nothing. The book reframes it completely: creativity is your ability to find possible solutions to a single, specific problem. That's it. Not magic, not talent you're born with a habit you build.
And the habit starts somewhere uncomfortable: asking questions out loud.
I noticed this about myself and about a lot of us in tech: we stay quiet when we don't understand something. We Google silently. We assume. We nod along in lectures and figure it out later, alone, at 1 AM. But that silence is exactly where creativity dies. If you never voice the question, you never get pushed toward the answer that isn't the obvious one.
Connecting dots is a skill, and it's literally what AI is built on
One line from the book stuck with me: creative people don't always have more ideas. They just notice connections that others skip past.
Sit with that for a second as an AI/ML student. Recommendation systems connect your past behavior to future choices. Language models connect patterns across billions of sentences. That's not magic; that's structured dot-connecting, done at a scale humans can't do manually. The systems we're all trying to build are, in a strange way, just automated versions of the exact skill this book is asking me to practice by hand.
Everyone looks. Very few actually observe.
This might be the idea I've carried with me the most. Hardas talks about slowing down enough to notice what's already in front of you the details everyone else walks right past.
Translate that into engineering terms and it becomes almost uncomfortable: before you build any AI solution, you have to actually understand the problem. Not skim it. Not assume you already know it because you've seen something similar before.
The best AI models don't fail because of bad algorithms. They fail because someone didn't observe the problem carefully enough to begin with. Creativity and good engineering both start with paying attention.
The line that stayed with me
"Engineers who can think creatively will build things AI can't automate."
This book didn't teach me to be an artist. It taught me to be a better engineer.
That distinction matters more than it sounds like it does. As a second-year student watching AI automate more of the "tool-use" layer of engineering every semester, the actual differentiator isn't going to be who can write code fastest. It's going to be who asks better questions before writing any code at all.
I'm building VaultAI and learning ML engineering in public — sharing the real process, struggles included. If this resonated, I'd love to hear what you're reading right now that's changed how you think about your own field.
Top comments (0)