I won $500 vibe coding at a hackathon
What my win means for the future of product prototyping (and hackathons-at-large)
I really don’t like the term “vibe coding” (and I’m not alone).
The practice, though, is fun. Rapidly prototyping software tools using Cursor (or more heavy-handed tools like Lovable and Bolt) can be exciting, especially if you’re someone who finds it easy to come up with ideas but hard to develop them into something practical.
Last weekend there was a hackathon going on at Music Biz in Atlanta. I was in town (representing my day job’s awesome tech) and saw this as a perfect opportunity to put a theory of mine to the test: is vibe coding going to completely change hackathons as we know them?
The answer: third place and 500 bucks. And given the prevalence of AI coding among the participants, a resounding yes.
What I did
My process wasn’t perfect and, as it often goes with vibe coding, I wasted a lot of time with repeat requests that my team of AI coders just couldn’t meet. Regardless, I want to show the full timeline of my work here. Here’s how it went down:
Hours 1-2
Ideation and ChatGPT PRD. I drafted up a quick description of what I wanted to build. The original idea was “…a toolkit that offers modern valuable tools and knowledge on music and the industry, where most are locally available for users in remote areas where it’s not typically available“. My original notes were sloppy and full of gaps that I expected my AI coding team to fill the gaps in on. I took these notes (and the hackathon’s goal PDF), passed them to ChatGPT’s Deep Research tool (which uses o3 primarily), and prompted it to research and generate technical requirements for another agent to act on. You can read my conversation with ChatGPT here.
First run in Cursor. I booted up Cursor and passed ChatGPT’s hitlist items to Claude 3.5 Sonnet (and occasionally 3.7 if it needed some more brain power). My general workflow philosophy here (and whenever I use Cursor) is to start a new agent chat for every single feature request. Add a feature? New chat. Fix a bug? New chat. Modify a button visually? New chat. This creates a nice paper trail I can always trace back, and ensures that my agent has the most token context available every time we chat.
Wasted a bunch of time, only to be saved by 4.1. I (not so quickly) learned that ChatGPT’s requirements were far too complex for getting an initial framework down and iterating on top. I abandoned the ChatGPT requirements and nudged my Cursor agent team to create a simple Nextjs foundation and a basic home page (that I described in detail). The intention here was to get the bones down (just a header, search bar, and tool cards) and build out the tools in separate pages bit-by-bit. Claude (my typical tried-and-true) continually failed to set up this simple home page, which wasted even more time. Eventually, much to my surprise, it was GPT 4.1 that was able to get the Nextjs framework set up properly with a nice minimal UI/UX on top. Now I was in business.
Hours 3-4
Iteration, iteration, iteration. For the next few hours, I chatted with my agent team in Cursor and built out the basic functionality. This included various visual tweaks to the app’s overall style and building out the structure for each tool. Initially I had planned for six tools in the toolkit, but I scaled that back to three to ensure each one would get enough time and polish: a music knowledge chatbot (“Knowledge Base”), a stem separator tool (“Stem Separator”), and an automatic music labeling and tagging tool (“Music Tagger”). I made sure each page matched similarly to the others (often by asking my agent to “look at the site and maintain the same style”). Overall, my most used agent model was still Anthropic’s Claude 3.5 Sonnet. Occasionally if that one got stuck, I’d jump over to Google’s most recent Gemini 2.5 Pro or OpenAI’s GPT 4.1. Every now and then I’d throw a hard problem into ChatGPT’s o3 if my Cursor agent team was having a hard time.
Integrating APIs into the tools. For this hackathon, numerous vendors were offering their APIs free-of-charge for use in the projects. I wanted to make sure I took significant advantage of this (and figured the more APIs I used, the more the judges may favor my product) and planned to incorporate at least one API per Field Note tool.
Muserk. The “Knowledge Base” tool was a basic AI chat interface (using GPT 4o-mini) for a user to ask music-related questions to. I wanted to integrate some more detailed music data into this, so that users could ask about things like streaming data and get detailed responses back. Muserk’s API was the quickest route to this, and I built in a function call for the bot to query their data when it deemed necessary.
AudioShake. The second tool, the “Stem Separator”, provided an easy way for the user to drop a music file and have the tool separate it out into its various stems (vocals, instrumentals, etc). AudioShake is know for their stem-splitting tech, so I figured their API was the move for this one.
Music.ai. For the third and final tool, the “Music Tagger”, I needed a library that could analyze a music file provided by the user and give back numerous tags (like mood, BPM, etc). Initially I was planning on using Cyanite, but I ran into some issues and pursued Music.ai instead. Luckily, Music.ai actually has Cyanite’s music tagging tech baked into their workflows (double the APIs!), so I was able to get the best of both worlds.
Each time I wanted to integrate an API into the tool (which involved numerous frontend changes and the creation of backend routes for these APIs), I would do the following in Cursor:
Send a link to the API documentation + a description of how I want the API used within the tool to Gemini 2.5 Pro. This model has great context length and handles requests requiring a lot of reading very well. The model would read through the docs and try and meet my request. Sometimes it would one-shot, sometimes it wouldn’t.
From here, I’d be back to iterating, generally using Claude 3.5 Sonnet. With the bones of the API implementation down from Gemini, this was typically a quick process and usually was more about making the frontend look nice and work well with the backend API implementation.
Hours 5-6
The next few hours were all about minor tweaks.
Bug hunts. For bugs that popped up (API disconnects, lint errors, frontend wackiness), I would start a new agent chat and tackle it individually. Once fixed, onto the next. (I’m eager to try out things like OpenAI’s new Codex and Google’s Jules which should be able to handle bugs async).
UI/UX design and adjustments. I went through the full experience a few times and made constant little adjustments to the frontend. Most of the work here was making sure the music upload and processing features for Stem Separator and Music Tagger were a good, smooth experience. Again, each feature (even stuff as small as a header font size change), would get a new agent chat in Cursor. No room for context cross-contamination!
Final polish. One last look through and things were ready to go. At the last minute, I decided to add a button on Music Tagger called “The Kitchen Sync” (a pun on sync licensing) that would take all the tags generated from a song, feed them to GPT 4o-mini, and generate a tongue-in-cheek suggestion for sync. This type of stuff gets big points when you’re demoing projects (as was the case here).
What I (and others) built
The end result of my six or so hours of vibe coding was a simple responsive web app called Field Notes.
I wanted to create a toolbox for musicians that are out and about or don’t have access to complicated computer systems, so the application needed to run on all sorts of hardware regardless of size and power. The best course of action for this was to utilize a flexible framework like React and have the majority of backend work sourced out to the various APIs.
Others built:
A tool that separated stems for a song, allowed you to upload a replacement for the stems (such as recording your vocals over top of the instrumentals), and then processed the new song and provided stats on what kind of licensing would be needed and how “original” the new song felt.
A dashboard for analyzing music samples (built with Lovable).
An MCP server for Musixmatch’s API (built with MCPify), with a companion dashboard that analyzed the lyrics for provided Spotify tracks (built with Replit Agent)
It was a smaller event (around 10 participants), but there was only one person that didn’t primarily use AI for coding (at least, as far as I could tell). Given my own extensive use of Cursor (both at this hackathon and elsewhere), I’m obviously not judging. It’s just hard to deny that the temptation of vibe coding is finding its way into hackathons, competitions created to encourage the very practice that AI coding bots make easy.
What this means for the future of hackathons
I think we’ll see a fracture. The growing hostility towards vibe coding amongst traditional developers is obvious, and it will be impossible for this not to find its way into the contest born out of these circles.
There will be casual hackathons, or “vibe coding hackathons”, that cater to all builders. No matter what tools or automations you use, you’ll be welcome, and the results will be full of abandoned API calls and half-function MCP implementations. In these contests, the role of presentation will become much more important. How well will the builders be able to demo their AI-generated products?
And then I suspect we’ll shortly see the rise of “AI-free hackathons”. A test of prowess among developers that want their competition to be free of messy AI code and shadcn-inspired interfaces. Perhaps the threat of vibe coding will push participants in these hackathons to develop even more niche tools, workflows, and APIs that keep the forefront of product engineering progressing faster than ever before.
Thanks to OpenPlay and Music Biz for hosting the hackathon. Exciting to see the music industry get more interested in focusing on the technical side of the tools that are being built to help creatives.