Hosting a vibe-coding hackathon
I recently hosted a general “Data & AI” hackathon at Schibsted, for all and any employees who wanted to join. It got me thinking about how vibe-coding, and hackathon success.
Hackathon participants tend to fail in one of three stages: ideation, scope, and interest.
Interest needs the idea of a hackathon to captivate the participant. While many in tech will know what a hackathon is, those outside of tech won’t - and therefore will probably not be that interested. Vibe-coding is a great way to make hackathons more accessible. But the framing and naming is still tricky. If you managed to get people of all industries to a hackathon, you’d be able get them to make some interesting prototype with vibe-coding. The real challenge is getting them there in the first place. I don’t have a good answer for this, though I try to get a “champion” within each unit to encourage people to join. Someone they know, respect, and trust.
Ideation is where most teams drop out after showing up. If they can’t come up with an idea they like, they won’t really want to take part. I picture it as the same dilemma of those who work in an industry they’re passionate about vs job where they’re just there to survive. If you are passionate about an industry, you’ll be highly engaged. If you’re just there to survive, you won’t want to do anything other than show up. If someone is unable to come up with an idea they’re passionate about, they won’t want to take part.
Breaking the barrier of ideation usually comes down to making the participant aware of the possibilities. I usually sit down with them, ask them what they do, and what they’re passionate about. Most of the time, it’s just a matter of linking what a person has been thinking about to something they could feasibly do in a specific time-frame. A great thing about vibe-coding: it reduces massively the time needed to successfully pull off an idea.
Scope doesn’t usually make people drop out, but it can be demoralizing so that they don’t end up demoing what they did. Participants try to tackle everything possible, setting the scope way too big to accomplish something meaningful in the short time a hackathon typically has. There’s always unexpected blockers. I spent one entire hackathon upgrading packages from Python 2 to Python 3 - I was meant to be making a multiplayer Spotify DJ. As a facilitator, your goal is to help the participants to narrow the scope and prioritize. Don’t let people spend time upgrading packages if that’s not what they had in mind at the start. If there are demos involved, visual elements are more appealing than looking at code or backend things.
Vibe-coding can be very accessible to people, but the problems of people new to hackathons are amplified by ambition, goals, and both too much of them and too little of them. If you’re facilitating a hackathon with non-tech people, make sure to help the participants filter through their ideas into something that could work.
Sidenote: during this hackathon, I only had 1.5 hours for myself. I decided to make an entirely vibe-coded Turing-complete Scratch clone. I’ve called it VibeCatLine.
Here’s FizzBuzz in it:
