From Collections to “Gen-AIex”: My Vibe Coding Journey at Funding Circle
At Funding Circle, our AI Native journey begun in 2025, when we established the technical and governance frameworks for the use of Gen AI. Now, we are expanding its application to transform the business. We are building an AI-native culture where Gen AI supports our Engineering, Commercial and Operational teams and this includes empowering Circlers (what we call our colleagues!) to explore how Gen AI can transform their day to day workflows.
Below you’ll hear from Alex Przytocki, Head of Collections and Debt Recovery, as he talks about both his personal and professional journey with Gen AI and the tools he has built to support his team AND the wider “vibe-coding” community within the business!
My day job is running Collections & Recoveries; setting repayment plans, keeping our loan book healthy and making sure our customers get treated fairly when things get tough. Nothing about that screams “future Gen AI Pioneer!”
It started back in December 2022, when OpenAI launched ChatGPT. Like a lot of people, I started using it for a bit of fun — daft, throwaway stuff, getting it to spin one sentence into an entire ridiculous short story just to see what it would do. Harmless novelty, nothing more.
Then I discovered what it could actually do. I went from being a decent, intermediate Excel user to something closer to a power user almost overnight; building things I’d never have attempted before, pulling data through into Google Sheets to analyse it properly, automating little bits of scheduling and reporting that used to eat up my week. That was just the beginning.
But somewhere over the last year, some colleagues have started referring to me as “Gen-AIex,” and it’s stuck.
How it started
It began the way most useful things at Funding Circle begin: with a problem nobody had time to solve properly. Call quality coaching in Collections & Recoveries was inconsistent, manual, and slow. A Manager listening back to calls, scribbling notes, hoping to get round to everyone before the next set of MI landed on their desk. I started tinkering with AI tools to speed up that process, mostly out of curiosity and a fair amount of stubbornness.
That tinkering became Hannah Call Coach — an AI call coaching tool that now listens, scores, and surfaces coaching opportunities across the team automatically. Seeing Hannah Call Coach featured as a case study on page 24 of this year’s Annual Report, complete with a quote from me on how it’s changed our approach to call quality, still catches me off guard a little. It didn’t start as a strategy. It started as “surely there’s a faster way to do this.”
Finding my “vibe”
The bit that changed things for me wasn’t a course or a certification — it was giving myself permission to just build. I’m not a Software Engineer by training. What I’ve learned to do is describe a problem clearly enough, and in enough detail, that an AI model can help me build a working solution around it. I make time for it because I’m genuinely curious what’s possible — where there might be an opportunity to improve something, or solve a problem differently. That curiosity is what keeps me iterating, breaking things, fixing them, and iterating again.
People have started calling this “vibe coding,” and it’s a genuinely different way of working than the traditional build cycle. Out of that habit came what colleagues now refer to as my “Vibe Coder Setup”; a way of working with AI assistants where I hand over context, constraints, and a clear brief, and get back working tools rather than a to-do list for someone else to build.
The Engine: My “Vibe Code Surgeon” Prompt
The biggest hurdle for non-engineers using AI is the “snippet trap” — getting back broken, disjointed patches of code that you don’t know how to stitch together. To solve this, I engineered a master system prompt. I call it the Vibe Code Surgeon.
Get Charlene Simpson’s stories in your inbox
Join Medium for free to get updates from this writer.
I load this set of instructions into my AI before starting any project. It acts as a strict set of guardrails to bridge the gap between my visionary ideas and a production-ready application. If you want to try vibe coding yourself, copy these four core rules into your AI prompt:
- The “Stop & Verify” Protocol: Standard AI models are eager to please and rush into generating code, often hallucinating. My prompt forces the AI to stop, analyse my request, output a bulleted plan, and wait for my explicit “Go” before writing a single line
- The “Full File” Guarantee: I ban snippets and diffs. If a file changes, the AI must output the entire file from start to finish. This eliminates version mismatching and allows me to simply copy, paste, and run
- Strict Modular Architecture: I force the AI to split the code logically (e.g., Code.gs for server logic, styles.html for CSS, scripts.html for JS). This prevents the creation of a monolithic, unreadable block of code and makes the tool scalable
- The “Sherlock Holmes” Debugging Loop: When things break, AI loves to make blind, destructive guesses. I instructed my AI: Never guess. If I report an error, the AI must pause, ask clarifying questions, and proactively offer to inject console.log trackers to pinpoint the exact failure point
This setup has become something other people across the business now use as a jumping-off point for their own builds, which is honestly the most rewarding part of all of this! Not the tools themselves, but watching other non-engineers realise they can build too!
Why this matters beyond my team
I could talk about the specific dashboards, scorecards, and automations I’ve built for Collections & Recoveries, but the real story isn’t the tools — it’s the mindset shift. A year ago, if someone on my team had an idea for a better way to track performance or spot risk earlier, the honest answer was usually “let’s raise it with Engineering and see where it lands in the queue.” Now, increasingly, the answer can be “let’s just build a version of it this week and see if it works.”
That’s a genuinely different way of operating for a business function that isn’t technical by trade. And I think that’s exactly the kind of change businesses need more of; not just in Engineering, but everywhere decisions get made and problems get solved.
The bit people don’t ask about: Governance
Here’s the part that doesn’t make for as good a story, but matters just as much as the building: none of this works if you trust the AI blindly.
Every tool that moves beyond my own desk goes through proper UAT before anyone relies on it — real test cases, real edge cases, a human checking the output against what actually happened, not just what looks plausible.
And I never take an AI’s first answer as fact. Every output, code, analysis, or a blog post like this one, gets checked against source data, tested, and challenged before it goes anywhere near production or goes out under my name. Funding Circle has a proper AI Governance policy now precisely because of this: the more useful these tools get, the more discipline they demand, not less. The “vibe” is in the building; the rigour is in what happens before anything ships.
What I’d tell someone starting out
- Start with a real, annoying problem. Don’t learn to vibe code in the abstract — learn it by fixing something that’s genuinely wasting your time
- Be specific. The quality of what you get back is almost entirely a function of how clearly you can describe what “good” looks like
- Expect to rebuild things. My early tools looked nothing like what they are now. That’s normal, not a failure
- Share what you build. The value compounds when other people can pick up your approach and run with it
I still spend most of my week doing the job I was hired to do — collections, recoveries, people, performance. But I’ve found that being willing to build has made me better at all of it. If you’re curious about where AI fits into a role that isn’t “technical” on paper, I’d say: it fits in more places than you’d think!
Did I utilise AI to help me write this blog? Absolutely — and every fact in it was checked before it went anywhere near “publish”!
