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.