A hackathon that delivered better solutions, not better products
What I saw when finance experts started building their own tools during a two-day workshop, and why dismissing vibe coding might cost you the most interesting solutions on the horizon.
The expert closest to the pain is now steering the build directly instead of losing intent through three layers of translation. This has massive implications for why, how and what products are going to be built in the near future.
I wanted to write about what I witnessed during a workshop I organised for a group of domain experts in the financial sector. To preach about AI changing everything around us is one thing, but to experience this change first-hand feels like a different game. My “students” weren’t discussing the pros and cons of AI. They were using AI in a way that felt like it had reshapes their profession and their industry entirely.
Why are we experiencing this shift now?
I got to see domain experts roll up their sleeves and focus on getting things done: building their own interpretations of how a problem should be tackled. If you’re in finance, your past 5, 10, 15, 20 or more years were probably spent in Excel or Tableau.
Side note: did you know Excel is actually 40 years old??
Suddenly it’s 2026 and you’re exposed to technology that gives you the freedom to create something that makes your job easier, more pleasant, faster and more proactive. You use AI as your copilot to build custom solutions that suit you, not the other way around.
Just not so long ago, or even now still, a domain expert wouldn't talk to a developer unless they had to. Maybe there was a big transformation programme at the company level, like upgrading an ERP system or implementing Salesforce, where a finance person was reduced to the role of stakeholder, typing requirements into a spreadsheet that got forwarded to a PM or PO. Communication with developers or IT in general was mostly about requirements or the issue tickets. A finance expert wouldn't debate database design with a developer. Why would they? Well, now it's totally normal.
That’s what triggered this article. Back when I was working as a PO or PM, I never saw a finance expert have a real technical conversation with a developer. And here I am today, sitting in a room full of finance experts talking about GitHub, databases, deploying, debugging... and it’s not them telling that to developers. It’s them doing the job themselves.
I’d argue we only got here because of vibe coding.
How are products going to be built?
The main point I want to make is that there’s so much negativity around vibe coding, but it doesn’t get enough credit for actually bringing us closer to better solutions, not better products.
In the recent episode from Lenny’s Podcast with Tony Fadell, co-creator of iPod and iPhone, he criticised vibe coding and argued that we're not building special things anymore because building has become so commoditised. He used a comparison of H&M and a luxury brand which is now happening to software because of what vibe coding has caused. I have a different take. As more domain experts become builders, we'll see even better solutions.
Not necessarily better products. Better solutions. Is that a difference?
There can be, if you're focused on building something as an expression of tech, design, architecture, know-how or the bells and whistles, rather than building for the user it's supposed to serve, their pain points, their problems, and the single outcome the user actually cares about: solve my problem.
The starting point for my students during the workshop wasn’t a discussion about the best architecture framework or programming language they’d use. They started with preparing the context about the job their solution needed to do, the problem it needed to solve, the output it needed to deliver. This context was needed, so that the entire “how it gets built” piece could be controlled by AI. As they knew the problem deeply, they knew the end user, they knew exactly what was coming in and going out, what a good versus bad result looked like, and what compliance and security rules the solution needed to follow.
Only once the prototypes started taking shape did they get interested in design, look and feel, the intuitive layout. But the design of Excel was not what drove them to build something better-looking. The functional limits of Excel, and the bad consequences those limits led to (manual errors, slowness, poor collaboration), were their starting point.
And that's what sometimes other products out there are missing: beautiful design that totally fails to help the user. A carousel of features, while the user only ever uses the "eco" option (thinking about my AI-powered washing machine here). If my cutting edge technology iRobot still stops after 5 minutes of vacuuming, this is not a solution for my problem, but a really irritating and faulty product. There’s a lot of criticism around “lack of taste” and “AI slop” that vibe coding produces. But if we obsess over design and sophistication without first solving the core problem, without actually moving users from A to B, we’re not doing a great job either.
AI is also not going to write us better code. This is often the main criticism of vibe coding (Tony mentioned the example of leaked Claude Code output showing how poorly AI codes). Still, beautiful code doesn’t always translate to a beautiful solution.
What gets built in the near future?
It’s not just that AI made coding accessible and brought development costs to near zero. Working with those 15 finance experts also made me realise they’re not only gaining the ability to build. They have a huge distribution advantage, which is often harder to crack than the building itself. Because they’re operating inside their own sector, mostly B2B (working with or for a client), getting a prototype or early production version in front of users is actually easier than figuring out the marketing, content and channel strategy to acquire them from scratch.
Conclusion: the power of domain expert + AI
The main takeaway I want to leave you with, especially if you’re a business that has always struggled with digital transformation: don’t underestimate the power of pairing a domain expert with AI. Don’t dismiss it because of the negativity vibe coding has received in the media. You might be blown away by the results and what it means for your team, your speed of releasing things, your creativity.
The pairing of a domain expert with AI is your route to software you could not get before at any price, because the person who could specify it was never the person who could build it, and too much was lost in the space between them.
Think about it for a second (if you’re a leader yourself): would a real risk in this shift be bad code written by AI or actually never seeing the solutions that only your experts can see, because you kept waiting for them to be translated into someone else’s language first?
Developers are right to call out vibe coding’s shortcomings, because they’re measuring it against their own standards. But vibe coding calls for a different way of working (with AI rather than a fellow developer) and is likely meant for a different type of solution altogether: highly custom use cases rather than huge, scalable systems.
In the end, AI should not only improve efficiency (generate more, faster = the automation trap), but also improve impact. The better measure is whether the customer’s problem actually goes away, and whether the people doing the work are better off for it.
Over two days I heard the same sentence from people who had never built anything in their lives: I did not know I could make this. That sentence is worth more than clean code. It is what a solution sounds like when the person who owns the problem is finally the one building it.
Now, it’s their job to ensure the end user experiences the same magic.