Why I Still Learn the Hard Stuff (Even When AI Can Do It)

When Vercel first dropped v0.dev, I looked at it immediately.

For those who haven't used it, it’s a generative UI tool. You describe what you want, and it spits out the interface code.
And honestly? Even back then, it was good. Really good.

It was doing, in seconds, what used to take me hours of CSS tweaking and component structuring.
That wasn’t just impressive; it was a moment.
One of those quiet moments where you realise something fundamental has shifted.

But the funny thing is… that wasn’t the moment that changed how I work.

The real shift came later.

As AI started landing in the tools I use day to day, I started noticing something important:
these models are powerful, but they don’t understand the full picture.
Not the way a human does.

And that gap, that missing context, is exactly why I've doubled down on learning the hard stuff.

---

The End of "Donkey Work"

Some people worry that relying on AI means we’re losing our skills.
I don’t see it that way.

Let AI write the boilerplate.
Let it spin up forms, generate CSS, scaffold APIs.

That's not craftsmanship, that's labour.
It’s necessary, sure, but it’s not what makes an engineer valuable.

By offloading that to AI, we get more time for what actually matters:

• system design
• debugging deep logic
• architectural trade-offs
• understanding performance, constraints, and domain knowledge

It’s the difference between being paid to type and being paid to think.

---

Ingredients Over Recipes

This shift reminds me of my time in the kitchen.
I’ve written about being a Jack of Many Trades, and the parallels between cooking and engineering keep showing up in my work.

Anyone can follow a recipe.
But a chef understands ingredients: the chemistry, the balance, the why behind each decision.

Coding is exactly the same:

AI can give you the recipe, but only you can understand the ingredients.

And that matters, because here’s the part no one talks about:

AI gets things wrong with extreme confidence.

Recently at work, I was doing transcription work for a feature.
I asked AI for help structuring a pipeline to process the audio.
It looked correct (clean code, good structure) until I realised:

• it didn’t understand the project context
• it made wrong assumptions about the input format
• it suggested an approach that didn’t scale with the volume of data
• it glossed over the accuracy requirements we actually needed

It gave me a recipe.
But I needed someone who understood the ingredients.

And that someone had to be me.

---

Why I’m Learning the "Hard" Stuff

This is why I’ve been diving deeper into backend architecture, systems design, and DevOps.

Not because I want to replace AI, but because I want to guide it.

I’ve been teaching myself:

• distributed systems basics
• caching layers and invalidation strategies
• message queues and event-driven design
• deployment pipelines
• containerisation
• database design and optimisation
• observability (logs, metrics, traces)

These are the things AI can create pieces of, but can’t fully reason about.

And here’s the truth I’ve learned:

When you understand the fundamentals, AI becomes a force multiplier.
When you don’t, it becomes a liability.

If you know how the system works end-to-end, you stop being “just a feature builder” and start becoming someone who designs resilient, scalable, thoughtful solutions.

You move from laying bricks to designing the building.

---

The Bottom Line

If a junior developer asked me today:

“Why should I learn how this works when Claude can write it in seconds?”

I’d answer:

Because the AI is your junior, not your senior.

It can write the code,
but you still need to:

• validate it
• contextualise it
• catch its blind spots
• understand when it’s confidently wrong

We don’t learn the hard stuff because we need to write every line ourselves.
We learn it so we can make the decisions that actually matter.

Because AI can build the thing,
but it still needs you to understand why you're building it.