I learned to build. Then I learned to ask why.
A non-tech person’s lessons from building with AI
Over the last few months, I’ve been experimenting with AI to solve some very real operational problems at work.
I don’t come from a technical background. I come from content, marketplace operations, vendor problems, spreadsheets and the occasional thought:
“Surely there has to be a better way to do this?”
AI suddenly made the distance between seeing a problem and building something to solve it much smaller.
And that’s where the fun started.
My first approach was simple
Problem → Idea → Build → Test → “It works!”
I started experimenting with internal tools and automations around onboarding, content workflows, campaign packages, menu processing and repetitive operational tasks.
Then came the education.
Something worked perfectly on localhost — and struggled after deployment.
A workflow worked beautifully — until it encountered something unexpected.
An automation executed an action — but I couldn’t always tell where every vendor was in the overall journey.
Suddenly I was learning words I’d barely used before:
State management. Exception handling. Dependencies. Tech stacks. Vendor lifecycle. Orchestration layers. Execution systems.
The interesting part?
I encountered the problems before I learned their names.
That has probably been the most useful way for me to learn.
But my biggest learning wasn’t technical
It was one word:
WHY?
I’ve always been quick to ask:
“Can we automate this?”
Now I’m trying to ask three questions before I build anything:
1. Why does this need to exist?
What actual user or business problem are we solving?
2. Why can’t the existing process or system solve it?
Is the real gap technology, workflow, integration, ownership, data — or something else?
3. Am I solving the root problem, or automating a workaround?
Because making a broken process faster doesn’t necessarily make it a better process.
And I’m starting to realise that “build something” is only one possible answer.
Maybe we should remove it, fix it, use something existing, integrate, extend, automate — and build only when building is actually the right answer.
AI made HOW easier. That makes WHY more important.
That’s probably my biggest takeaway so far.
AI has made it incredibly easy for someone from a non-tech background like me to experiment, prototype and learn by doing.
But AI can also help me build the wrong solution remarkably quickly.
So I’m trying to change my starting point from:
“How can I build this?”
to:
“Why does this need to exist?”
I’m still learning. I’ll definitely break things again. And I’m sure there are plenty more technical terms waiting to confuse me.
But I’m starting to understand that technical fluency isn’t necessarily about knowing how to write every line of code.
For me, it’s about understanding enough to ask better questions, challenge assumptions, understand constraints and connect business problems with technology.
One unintended consequence…
Apparently I’ve taken the learning slightly too far.
I missed my cycling session and somehow turned it into a production incident:
rideBike() → FAILED
Runtime: Still sleeping
Server: Bed
Root cause: Netflix
Exception handling: Snooze button
State: BLOCKED
ERROR: User dependency unavailable.
In the end…..
One thing has definitely changed in how I approach problems:
Don’t start with the solution. Start by understanding the problem.
Sometimes the answer is automation. Sometimes it’s integration. Sometimes an existing system needs to be used differently. And sometimes the process itself needs fixing.
My new rule is simple:
Understand the WHY. Find the real gap. Then decide the HOW.
Because the goal isn’t to build more tools.
The goal is to solve better problems, in better ways.