Running the South’s Largest Hackathon in the Vibecoding Era
I was the Co-Director of Operations for HackGT 12, Georgia Tech's annual large-scale hackathon held on campus every fall. In the 12th iteration of the event, things seemed to be figured out: we had our usual sponsors, relationships with food and merch vendors, and established marketing channels. At this point, we knew what rules to bend and which administrators are more helpful than others. On top of that, the shared wisdom of the past 11 exec boards was, for the most part, neatly documented in a massive Notion.
The pre-event planning was fairly standard. As an operations member for HackGT 11, my transition into Co-Director was the usual ramp up: the tasks I used to do became what I delegated. As a Co-Director, you get exposed to the more finnicky organizational parts that were sort of abstracted away to general operations members: having to wake up to book classrooms several months in advance and telling admin white lies about attendance expectation, weaving around licensing restrictions, negotiating with sponsors, and trying not to commit financial fraud as a 501© non-profit.
With all this however, the most surprising shift, and maybe one that we should have foreseen, was how much LLMs have lowered the barrier for entry. I'll attempt to document my experiences and general advice on how to run a massive in-person hackathon, especially now that everyone can code.
The Vibecoding Experience
HackGT is, to my knowledge, the largest collegiate hackathon in the Southeast and in my unbiased opinion, one of the US's premier hackathons. In our most attended HackGT, we saw around 1000 participants show up and participate. The first signs of a change this year were the 1400 confirmations we received. We have a max capacity of (and only budgeted for) around 1100 participants, however, there are always a sizable amount of no-shows and so as usual, we allowed walk-ins day of. For HackGT 12, we had 950 people check-in in-person and over 300 send in emails about late check-ins. Despite having to turn away a massive crowd of walk-ins, we ended with a total of 1090 participants.
Participants are encouraged to form teams of 3-4 people and generally, not every participant successfully submits a project. Our all-time high was a submission of 180 projects given ~1050 overall participants. This year with a similar number of total participants we saw 273 project submissions (a >50% increase). Some theories:
- People use LLMs to generate project ideas faster, especially within the constraints of tracks: a lot of the projects I saw had really similar ideas. Though this has always been the goal, tracks and challenges generally shouldn't funnel into the same kinds of ideas.
- More individual/smaller teams: A complete one-person hackathon submission used to be a herculean effort and while still impressive, having LLMs generating code or agents working independently has made it a lot more viable.
- Quick iteration and bug fixing: I think I spent a majority of my first hackathon trying to understand how to use the Spotify API. I'm assuming that this isn't a common experience anymore - building out boilerplate and at the very least, knowing what tools/libraries/APIs to use is a solved problem. The time-constraint of a hackathon is less of a constraint now, knowing that most bugs are LLM-fixable.
- New Non-CS programmers: Georgia Tech as a campus is dominated by CS majors and a hackathon at the computing building is as prime as possible. However, I talked to a lot of engineers (industrial, electrical, BME especially), design majors, and business majors who now could contribute and see their ideas come together.
I don't view this as a negative. I think of hackathons primarily as a low stakes environment to spend concentrated time on something you're interested in and so building MVPs quickly or just experiencing how to translate ideas to code, even with LLM-assistance, is good for the overall community. Outside of my opinion, this feels like the new normal.
Hardware is Still, Hard
The Hardware track submissions seemed more aligned with previous hackathons. We provide access to multiple makerspaces and these were the teams that seemed to still consider the time a limiting constraint and it seems like the AI tools for hardware are not there yet, either in quality or adoption. A physical project definitely still stands out - a hardware project ended up winning our first place overall.
Agents are the Hot Thing
A reflection of my Twitter feed, a huge amount of projects were focused on agentic experiences. Part of this was on us: some of our sponsors were agentic AI startups and we gave away 1000+ copies of a book on building agents but overall, this seems like the natural transition from when every project was a chatbot. The best implementations in my opinion, used agents in new interfaces and showed utility over just autonomy.
Sponsors Decide the Vibe
As a participant, sponsors were just the people that paid for lunch in exchange for some resumes and mindshare among participants. Until I started organizing hackathons (and probably exacerbated by increasing unemployment), I didn't realize how much participants care about the sponsors.
The hackathon "career fair" was probably our largest crowd, with everyone trying to get a word in with the sponsors. The sponsor workshops, even without the incentives of our point system, were packed. We changed our track systems to include more sponsor challenges and these were extremely popular (most teams submitted to 2+ challenges along with a track).
- The sponsor tracks have to align with the event, minimize overlap, and importantly, invite cool projects. Having interesting prizes/interviews for winners is also a big draw. Some of our sponsor tracks were too siloed and caused a lot of similar projects. Similarly, since we had sponsors in the same domains, some of our workshops also covered the same ideas so some oversight on these is important.
- The mini-events that the sponsors host will generally be the most popular so encourage fun activities (we had a golf simulator), interesting speakers/stories and a chance for hackers to interact with sponsors more directly - these will often be important to the perception of the event.
- The main opening ceremony speaker was, surprising to me, a huge factor in our event's perception. Through MLH, we were able to get the COO of GitHub to speak and many participants noted that as a highlight of the entire event.
- Startups can be great sponsors! Even with tight budgets, they usually are easy to work with, student friendly and are more open to changes/appealing to hackers as much as possible. It also helps them get immediate access to 1000+ people to try their products.
Some Anecdotal Opinions on Operations
Every team needs generalists. The biggest takeaway I had from organizing HackGT was that preparation needs specialists but so much of the execution relies on generalists. Whenever there are issues day of, you need someone who has a big picture understanding of everything going on that can take over and help resolve the issue, or at least come up with a workaround. Members of the finance team who understood our room availability and scheduling were able to independently help out sponsors who requested to conduct interviews day of. Tech team members made quick design decisions to update logos day of. Even if someone doesn't know how something exactly works, if you have a high level understanding, you can quickly make yourself useful. Everyone on your main executive board should be able to pick up slack for other subteams.
Uniform decisions that make some people unhappy are better than non-uniform decisions that make only some people happy. The day-of issues are often specific: people who traveled several states to attend without an acceptance, participants who want to switch into beginner tracks because of their team, participants who had a falling out right before submissions, etc. Decision making in these situations is difficult since your immediate decision impacts their entire weekend. The best way I've learned to deal with this is to agree on some basic heuristic and make decisions to the best of your knowledge based on that heuristic. I was being bombarded with requests during check in but ultimately, we decided to uniformly turn away everyone who was not an accepted participant unless they had absolutely no alternative for housing/food. Following a loose heuristic prevented every issue from being propagated up to me - organizing members could just make these decisions themselves. Generally, these smaller decisions waste more time in getting made than the actual impact of the decision so we avoided fact-checking or trying to judge situations. Whenever we did have to make an exception, we made it clear that we were doing so - we want to accommodate people where possible without opening the floodgates. Overall, this made some people unhappy but prevented domino-effect complaints.
This leads into be ok with saying no. Whether participants, sponsors, or other stakeholders - everyone will try to take advantage of what is being offered to them and try to maximize what they can get. You need to be aware of what you can and can't provide and often that means having to apologize and say no.
A reliable tech system can help operations but you also need operations to help tech. Through the years, many participants and other stakeholders have noted our expansive tech setup. We have RFID badges to track check-ins and participation, an internal judging set up, a swag economy to track prize transactions and an app for the participants among other things. However, as will always be the case, some things break in production. For example, our judging system crashed at 8 in the morning, with none of our judges able to sign in and hundreds of participants waiting to be judged at 9. I think it is really important for operations to be prepared with reliable backups in case something breaks down (Google Forms for judging, readily available schedules, manual check ins, multiple communication lines with participants, etc.). Our 24 hour help desk was key to solving issues for participants.
Know what drives participants. We were able to influence participant behavior by adding extra points to some events, adding mini-prizes where possible, putting events in adjacent rooms, and inviting popular clubs to perform. This helped pack out some of the more quiet rooms.
Think about the "Hidden" Stakeholders. Janitors, performers, volunteers are all really important to the success of the event - you should make them feel appreciated (merch, food, clean-up) and try to make it as easy as possible for them to help you.
Document everything. This reflection only exists because of the notes I made throughout the event and a lot of the event would be hard to run without the Run of Show we made before that. Writing with a focus on transferring knowledge is the only reason we don't have to start from scratch every year.
Closing Notes
Planning a hackathon kind of took the fun out of it for me but being there day of reminded me why I wanted to do it in the first place. As a freshman, building a janky weather-based Spotify playlist app with a bunch of PhDs I met in the lobby gave me the push to try something new. CS is supposed to be about building cool things and I still think hackathons are the best way to capture that for a weekend.
As for HackGT, I'm proud of where we've taken it but there's undoubtedly more to do to make it the best in the world. This year was a reminder that CS is always evolving and as result, hackathons have to too. There are a lot of great opportunities to push the envelope from both an organizational and participant experience standpoint and I'm confident the vision of the next Hexlabs team will be even better.