I spent 20 hours watching AI videos and still couldn’t build a simple workflow.
Not a multi-agent system.
Not some advanced orchestration layer.
Not an enterprise AI deployment.
I was just trying to connect n8n to my email and generate daily email status reports.
And I couldn’t even get the nodes configured correctly.
So naturally, I went to complain to a tech product manager at Ovidius.
His response?
“I’m not surprised.”
At first I thought he was roasting me.
But then he reminded me of something I’d been told once before:
Watching AI content is not the same skill as building AI systems.
And honestly? I think companies are about to learn this lesson the hard way.
The AI Illusion Problem
Right now, everybody is consuming AI content.
- YouTube tutorials
- LinkedIn carousels
- “Build an AI agent in 15 minutes” videos
- n8n workflows
- Claude Code demos
- Automation threads
I’ve watched all of it.
And to be fair, so had Janiek, an IT Manager at Ovidius.
He estimated he’d consumed around 200 hours of AI and automation content before really getting hands-on inside production workflows.
His takeaway was blunt:
“Nothing compares to getting your hands dirty.”
That was probably the most important thing said in our entire conversation.
Because passive consumption creates the illusion of competence.
But production environments expose reality fast.
The 80/20 Trap Companies Don’t Understand
One of the most interesting things Janiek described is what happens when companies move from prototype to production.
According to him, this pattern keeps repeating itself:
Someone internally gets excited about AI.
Usually a curious employee.
Sometimes a junior operator.
Sometimes “the grandson convincing the CEO,” as he joked.
They build a lightweight prototype.
And honestly? It works.
It gets maybe 80% of the desired result in 20% of the time.
That’s where the confusion starts.
Because leadership sees the prototype and assumes the hard part is done.
But in reality, the remaining 20% is where all the actual engineering lives:
- edge case handling
- testing infrastructure
- environment configuration
- staging vs. production deployment
- authentication
- feedback loops
- QA
- reliability
That’s the part most companies still fundamentally underestimate.
And it’s also the part hiring teams don’t yet know how to evaluate for.
Quality Engineering Is A Big Deal
The richest part of our conversation was around quality engineering.
Janiek said something that stuck with me:
“Quality means something different for every project.”
And that’s the problem.
Most clients know bad output when they see it:
- “This feels generic.”
- “This isn’t what I meant.”
- “The workflow breaks sometimes.”
But they often cannot define upfront what “good” actually looks like.
So what happens?
Testing becomes reactive instead of operationalized.
Ovidius delivers testing batches.
Clients fall behind reviewing them.
Feedback loops stall.
The backlog compounds.
And suddenly everyone feels like the project is slowing down for “no reason.”
But there is a reason.
Quality engineering isn’t a checkbox at the end anymore.
It has to be embedded into the build itself.
That was one of the clearest themes from this conversation, and I think it maps directly to what’s about to happen in hiring.
The Hiring Problem Nobody Is Talking About Yet
The more Janiek described his role, the more I realized:
This is basically the same communication problem recruiters deal with.
He sits between:
- business stakeholders
- engineers
- client expectations
- delivery constraints
Recruiters sit between:
- hiring managers
- candidates
- business expectations
- technical evaluation
Different environments.
Same translation problem.
The business talks in outcomes:
“We want automation.”
Engineering talks in inputs and outputs:
“What exactly should the system do?”
And the person in the middle has to bridge the gap.
That’s why I think hiring for AI roles is going to get even messier:
Because companies are trying to hire for two completely different skill sets at the same time:
- someone who can identify operational bottlenecks inside the business
- someone who can technically architect and build solutions
Those are not automatically the same person.
And most companies still don’t know how to evaluate either one.
“AI Engineer” Is Becoming An Overloaded Title
One thing Janiek mentioned that I found fascinating:
Companies are already spinning up standalone Data & AI departments.
Not innovation committees.
Not side projects.
Actual departments.
And many of them are forming organically because someone internally became “the AI person” by experimenting early.
But once leadership starts allocating budget and headcount, the expectations change immediately.
Now the company wants:
- governance
- production reliability
- QA
- documentation
- ROI
- workflow ownership
- integration support
- business alignment
That’s no longer “a guy who knows ChatGPT.”
That’s operational infrastructure.
The Best Advice From The Entire Conversation
Toward the end of the interview, I asked Janiek how someone non-technical actually ramps up in this space.
His answer was refreshingly simple:
Stop only watching videos.
Start building things.
Break things.
Debug things.
Figure out why they broke.
That’s where the learning happens.
He also gave a framing I thought was incredibly useful:
“Context engineering.”
Meaning:
If your AI agent were a new employee…
- what SOPs would they need?
- what context would they need?
- what documentation would they need to succeed?
That mental model is probably more practical than half the AI advice circulating online right now.
Final Thought
I think we’re entering a phase where companies are realizing AI implementation is not just a tooling problem.
It’s a communication problem.
A workflow problem.
A quality problem.
A hiring problem.
And honestly, a management problem.
The people who succeed in this era probably won’t be the loudest AI influencers.
They’ll be the people willing to sit inside broken workflows long enough to understand how systems actually operate.
And according to Janiek?
That starts by simply getting your hands dirty.