Cursor Hackathon: A Reflection

Last November, I participated in the Cursor Hackathon in Ho Chi Minh City. It was one of the largest in-person hackathons I have ever attended, with over 700 participants and more than 65 projects submitted. I won first place with Hoggle - Hogwarts for Muggles, which lets normal humans practice Harry Potter spells using AI.

The hackathon was super fun, and I was surprised to see how big the Cursor community is in Vietnam. I was very happy to meet fellow builders who managed to create creative and powerful applications in just 3-4 hours.

This post notes down my ideation and building process, along with some reflections I have about the event.

Ideas are cheap? Not quite

I used to be a big believer that ideas are cheap, execution is everything, and I think it’s still partly true, especially for building startups. But with this half-day hackathon, the idea was everything.

The requirement was to build anything easy to demo in two minutes, and you needed to build it within the hackathon time, which lasted four hours.

My list of ingredients for an impressive demo includes:

• Multimodality AI: Standard text-in-text-out with LLM would be boring. So the final product must have real-time image/audio/video processing/generation.

• Object tracking (optional)

• Impressive UI

• Fun (non-negotiable)

Before going to the event, I had two main ideas:

• A browser extension that detects scam calls in real-time, which solves a very pressing problem in Vietnam.

• A game that allows users to make spells and magic tricks, because I just rewatched Now You See Me a few days before.

On the event day, I needed to take a very long ride from my friends’ graduation ceremony to the hackathon venue, which made me late for the hackathon. Looking back, I was fortunate to be late. Driving allowed me to think more deeply about the two ideas. Both were solid and would be very impressive for a demo, and they were both buildable.

However, I thought that someone else would have come up with an idea similar to the first one, so I chose the second, which checked all the boxes:

• Audio processing to identify the spells users make

• Object tracking to track users’ hands

• Image generation: my list of spells includes Accio, Lumos, and Wingardium Leviosa from Harry Potter, plus one special spell Cursor, which generates 3D objects from what users draw with their hand (I didn’t deliver this exact spell eventually, which will be covered below)

• Augmented reality to allow users to hold a wand and show spell effects (light up the wand, make objects fly, etc.)

• It’s fun!

I used an hour on my motorbike picturing every detail, which laid a solid foundation even before I arrived at the event.

Building (prompting + test + pivot + iterate)

My main flow was:

• Start with plan mode, chat in plan mode to make it very detailed, and manually update the plan

• Use agent mode to build an initial version from the plan

• Use different Cursor tabs in Agent mode to modify different parts of the project in parallel

I used a mix of Gemini 3 and Claude Opus 4.5 for planning and long, complex running tasks, and Composer 1 or Auto for simple fixes.

Since the game includes standard spells from Harry Potter, which LLMs have knowledge about, and the special Cursor spell, I built the game without the Cursor spell first, since it would be easy to add when the core game logic and UI are stable, and I didn’t want to inflate the LLM context.

This was the original prompt for the plan mode:

build "Hoggle" (Hogwarts for Muggle) that teaches muggle spells:
- it's a gui app using python

- use google-genai 1.52.0

- teaches 3 spells:
+ Accio: brings object to you
+ Lumos: light up wand tip
+ Wingardium Leviosa: make objects fly

- it first shows the spell, what it does, and allows user to practice

- in practice mode, uses OpenCV to detect user's hand and action. use VR to put a wand into the user's hand. capture user's voice and send it to gemini to verify that user make the spell correctly

- if the spell is correct, perform the action (ie. light up tip of wand for lumus, bring an object (fake 3D object) to user for accio, and make object fly for Wingardium Leviosa)

- if the spell is wrong, give feedback. eg should be Wingardium Levi'osa, not Wingardium Levio'sa

The first version built from this plan did not look good (it looked more like a website than a game), and lots of things did not work properly. This was like only 5% done. I spent the next ~3 hours using Agent mode to fix bugs and add new features with different Cursor tabs in parallel.

I decided not to use worktree, and only use a single git branch with git commits as checkpoints after finishing major features or fixing important bugs.

Home screen of the final product

Most of the time, I had 2-5 parallel conversations with Cursor, which was limited by my ability to context switch, and the number of independent parts the the app that could be modified in parallel without any conflict (Gemini/Elevenlab API calls, game logic, spell logic, UI).

I didn’t care about code quality for this hackathon, so I used a very simple Cursor rule, technically telling it how to run the commands to test the app correctly:

---

alwaysApply: true

---

- activate environment with `source .venv/bin/activate` before running any python command

I could not get lots of things done in a short amount of time, so I need to revise my approach a lot as time goes by and put in some workarounds to have a cool demo. This is a non-comprehensive list:

• I removed Accio - the summoning charm which brings objects back to the caster - since the time for the demo is too short for 4 spells + a good story, and the effect is very similar to Wingardium Leviosa.

• I hard-coded to make the first try of Wingardium Leviosa always fail, and the feedback is similar to the conversation between Ron & Hermione in the movie.

• The initial plan was to place a 3D object of the Elder Wand in users’ hand, but it was not rendered properly when users rotated their hands, so I used OpenCV to draw a 2D wand with calculated coordinates instead.

• For the Cursor spell, generating 3D objects with Gemini API was not as straightforward as I thought → I downloaded some 3D objects and only asked Gemini to classify the drawing and display the returned object name, but again, object rendering was not perfect → I switched to 2D (PNG with transparent background).

• Last minute, I decided to ask Gemini to return “cat” for the Cursor spell, so I would tell everyone that I was trying to draw a dog. Again, just for the sake of the demo.

Reflections

Done is more important than perfect

With more than 700 participants and 1-4 people per team, there should be around 200-300 teams, but there were only 65 projects submitted at the event, plus some late submissions.

Even with AI, it’s still extremely hard to build something properly in 4 hours, myself included, as my final product was very different from what I initially planned.

But, regardless of how small the chance of winning with a not-as-planned product is, the chance of winning without submission is 0.

This applies to many other things outside hackathons as well, including delivering real-world software, where oftentimes it’s better to reduce scope than push back the timeline.

It’s important to know what’s important

In early 2025, I won my company's hackathon during our offsite in Bangkok. There was another team that had the same idea as my team, and their approach was more technically challenging. But with the goal of integrating AI into the company’s product, our project has a better UI and integrates seamlessly with the Momos platform, and our demo was more impressive, so we won.

For this Cursor hackathon, the most important part was the 2-minute demo. So all the decisions I made were to make this demo as fun and impressive as possible, even though sometimes it means compromising product quality (like hard-coding stuff).

Since time and resources are limited, you need to know what is the most important thing and focus on it.

AI is progressing fast, but humans remain vital

Before the burst of AI coding tools, it was rare to see a technical hackathon that lasted less than 24 hours. Now things are changing rapidly. I was able to put together a game in 3-4 hours that would take me a week to build without AI.

While there are some lags in the effectiveness of AI between green-field (like hackathons) and brown-field (large legacy system) projects, I expect things would change a lot in the future.

As of now, humans remain vital in the software development process.

For this hackathon, technical people still had a big advantage since they are familiar with the development workflow and make better high-level architecture decisions.

Even in a professional work context, different people using the same tools will produce different outputs, both in terms of quality and quantity. Writing code is just one among many responsibilities of software engineers. I expect AI will enable us to do more, not less, in the short and medium-term future.

---