I’ll admit: When I first started hearing people talk about “vibe coding,” I wasn’t convinced it was for me.
My thought is, if I can’t read the code, how can I trust what I’m building?
I’ve always believed technical fundamentals matter. Understanding architecture matters. Knowing how systems connect matters. So instead of jumping straight into AI-assisted building, I started learning software fundamentals because I thought that was the foundation I needed before creating anything.
Then I found myself with a problem I wanted to solve. Over the past year, I’ve spent a lot of time helping people in the QA community with their resumes. I was answering similar questions every week around resume structure, automation experience, interview preparation, and why candidates weren’t getting traction. I wanted to create something that could help more people get high-quality feedback without requiring me to jump on a call every time. I wanted to build a resume scanner specifically for QA professionals.
And that’s when I finally decided to try something I had been skeptical about.
Vibe coding.
A big reason I gave it a shot was because of Jamie, a Talent Engineer who had been encouraging recruiters and talent professionals to experiment more with AI, automation, and building.
For months, Jamie had been talking about how these tools allow non-technical people to start creating things they previously couldn’t.
I wasn’t fully buying it.
Until I tried it myself.
The project that changed my perspective
I used Claude to help me build what I needed.
And no, it wasn’t as simple as typing a prompt and magically having a finished product.
I got stuck.
I had to think through architecture decisions. I had to refine prompts. I had to adjust my fallback logic. I had to connect APIs and read documentation when integrating Gemini.
But I finished it. And I remember thinking: “Wow. I actually built something.”
Not enterprise software. Not something designed to replace engineers.
Something simple. Something useful. Something that solved a real problem.
That was the moment I realized maybe I had misunderstood vibe coding.
The point wasn’t becoming a software engineer overnight. The point was removing enough friction that people with domain expertise could finally turn ideas into reality.
And honestly, I started wondering: Was I using “I need to understand everything first” as a reason not to start?
That question led me back to Jamie. After building my own project, I wanted to understand his experience better and ask why he believed so strongly that this was the future of how people would work.
Meet Jamie: The TA who became a builder
Jamie’s journey into AI building is actually a perfect example of what’s changing.
He didn’t start as a traditional engineer. Throughout his recruiting career, Jamie naturally gravitated toward operations. He started as “the spreadsheets guy,” then moved into process improvement, data analysis, Python, SQL, dashboards, automation, and eventually AI.
The pattern was simple: he kept finding problems he wanted to solve, and technology became the way to solve them.
The next wave of AI builders won’t all come from engineering backgrounds. Many will come from operators who understand business problems deeply and now have tools that allow them to create solutions.
What Jamie is actually building
One thing I appreciated about Jamie’s perspective is that he wasn’t talking about AI in theory.
He’s building.
One example he shared was candidate packs, which create a repeatable way to package candidate information into a polished output for hiring teams.
You can see an example here: https://www.linkedin.com/feed/update/urn:li:activity:7450821436325126144
Behind the scenes, the workflow uses Claude, skills, GitHub, and Vercel. The recruiter triggers the workflow, and the system handles the technical pieces behind the scenes.
The important part isn’t the tools. It’s the workflow. A recruiting problem became a buildable solution.
Another project Jamie discussed was hiring manager enablement.
Hiring manager inconsistency has always been a challenge in recruiting. And I can agree with that. Different interview styles, different evaluation standards, and different expectations can impact hiring outcomes and the overall candidate experience.
Jamie described using interview note takers, Claude, schedules, and Slack workflows to evaluate interviews against scorecards and provide feedback.
Instead of only measuring candidates, companies can start measuring the quality of the hiring process itself.
That type of visibility changes the conversation. AI isn’t just helping recruiters move faster. It can help companies understand where their process is breaking.
Jamie also shared a content digest project he built that automatically populates weekly: https://www.thereclab.ai/digest
The opportunity and the risk
The biggest benefit Jamie sees with vibe coding is simple:
More people can become builders.
Not everyone is going to create enterprise software. But people can create custom automations, workflows, and data connections that previously required engineering resources.
That creates leverage.
But Jamie also highlighted the other side.
With more people building, there is more opportunity for things to go wrong.
Data issues. Legal concerns. Quality problems. Technical mistakes.
The answer isn’t ignoring AI.
And I think the answer here is creating structure around what is being built, who is using it, who will maintain the solution and adoption plan.
Build vs. buy: Jamie’s approach
One question I wanted to ask Jamie was how companies should think about building versus buying.
His approach was practical.
Buy the platforms that already exist, but choose tools that can be customized.
Companies probably don’t need to build their own ATS from scratch. But they can build workflows, automations, dashboards, and data connections around those systems to create a competitive advantage.
Final thoughts
My biggest takeaway from this experience wasn’t that AI turned me into an engineer or a “vibe coding enthusiast”.
It didn’t. And I still have a lot to learn.
The takeaway was that AI gave me enough leverage to finally build something I had been thinking about for a long time.
And maybe that’s the real opportunity. Expanding who gets to participate in building.
Jamie challenged a belief I had.
I tested it myself.
And I walked away realizing that sometimes the biggest barrier isn’t the technology. It’s convincing yourself you’re allowed to start.
A big thank you to Jamie from PromptMates for taking the time to share his perspective and for constantly encouraging people in talent and recruiting to experiment, build, and learn.
If you’re looking to upskill recruiters with AI or bring AI expertise into your talent operations team, you can learn more about Jamie’s work here: https://www.thereclab.ai/