The State of Hackathons

I just completed my first hackathon, and here is how it went. This hackathon was hosted by the Claude Builder Club at Georgia Tech. Unlike a traditional 24 or 36-hour time frame for a hackathon, this one was just 3 hours. Claude being in the club's name meant it would be the central theme. I joined a random team of five other people. Before beginning, they released the prompt that would serve as the theme of the hackathon. Simply put, build a food-health app that more effectively engages users in healthier behaviors, including, as an example, a feature that could be a personal coach. My team started talking about how we could make the basic premise very unique because the prompt was a bit structured, and there were close to 40 teams competing. As we were listing out multiple features, we realized that creating a pet or mascot that serves as a mirror of the status of your health for the day was the angle we could take.

As a team, we split up with two, one group working on more of a roadmap, myself and one other teammate just coming up with a framework and seeing Claude's initial output, and the last two working on the pet design, as it was quickly understood that the user interface (UI) would need to be top-notch to also help us stand out. This was mostly the process for the three hours, and as we neared completion, we had a working prototype built and a pitch made. We built the app in React with code setup to integrate the Claude Vision Application Programming Interface (API) and Apple HealthKit API to get the data. Our demo pitch included all the information, plus a live demo of the judges using the app.

On the Format

After that introductory walkthrough, here are my thoughts. My team did not win during the competition, and there are a couple of items of feedback I would give for the hackathon, plus a couple of thoughts to consider as we progress with the notion that these are how hackathons are evolving. With the time being only 3 hours, I understand making the prompt more one-dimensional so judging can be relatively similar across the many submissions, but this prompt did not seem to really connect with what can be done with the tools given, nor was it connected much to the ones who gave the prompt, which was NBC. I realized that I was not really invested that much in the idea. I understand that this might not be the point of this type of hackathon, but as someone who wants to make tools that can innovate or make quality tools to improve the experience of a user, I just felt like this prompt failed to trigger this sense I had.

Now I will say there were some very clever ideas, and it has gotten me to think outside the box when faced with a problem-solving time, but my point stands about the lack of creativity from this prompt. I really enjoyed many aspects of the hackathon, meeting with my group, and just getting to know them better.

Shipping Fast vs. Learning Deep

Lastly, I want to talk about the state of hackathons from my perspective. As might have gone through your mind, what actually is happening during these hackathons? Well, from my perspective, there wasn't much actual learning. Shipping fast is the name of the game, and much of this was simply waiting for Claude to finish outputting and start the next prompt. The API implementation was not working properly during the demo due to the time crunch and what needed to be fulfilled in the presentation. Projects, I have been told, can really help one stand out when in the employment process, but all these taught me was creating solutions and implementing rapidly (as a skill that is worth value but cannot stand in for pure technical abilities).

I am not saying that Claude and tools like this are not the future because I can clearly see their use and potential, I am just saying for learning anything technical this is not the spot to do that, which meant that when my usage ran out during the hackathon, I had to stop monitoring Claude's generated code because typing by hand was going to be insufficient. I wonder what companies of these large language models (LLM) and coding agents have their engineers do since they probably use AI to help build these products. I assume what separates them is the responsibility of knowing what is being generated and being able to speak up if a problem arises. Some fixes that could improve on this genre of hackathon is having engineers reviewing code quality to help young builders steer in the right direction.

Overall, my mindset from this hackathon has shifted to being able to understand my personal projects code because these are ideas I started with passion and because prompting is for everyone, but knowledge is for those who desire it.