Show the full transcript (2,512 words)
Hey guys, I'm Johnathan, and over the last year, I've gone to five of the most prestigious hackathons in the world at universities like Stanford, Columbia and Yale, and I've won a prize at each and every single one. Claude, Code and Codex obviously help me move fast, but it's not as simple as just pasting in a single prompt into your AI agent and going to sleep. So whether you're a student trying to make your first project or a multiple-time hackathon participant that wants to win, this video will help you. If Claude has felt dumb to you at times, like explaining things in the most unintelligible way possible or outputting straight AI slop in its designs, then it's likely that you're just missing a critical part of the setup. In this video, I'll walk you through the secret workflow that I use to win against over 1,000 other competitors and teach you the four step process that most other contestants are not aware of to ideate and create actually good projects. By the end, you too can go and win some hackathons or just create really polished projects that you're proud of.
The first and single most important step is to think backward. Imagine you've already won the hackathon. Look, maybe it's a specific track, a sponsor that you really like. Now, how did you do it? What crazy demo did the judge see that instantly made them go, "Yup, this one is a winner." For me, at TreeHacks 2025, it was a 6-foot tall autonomous food delivery robot. We didn't even shoot for any specific track, but we knew immediately that this project, if completed, would win something. At TreeHacks 2026, it was a 3-foot tall smart mirror. At YHack, it was an AI agent that works with you on your computer and at Columbia, it was the image of four agents working in parallel, virtual machines on the cloud. The trick I use is to pick the craziest cool thing you can think of and then check if it's possible. Ash, relax. I originally wanted to scrape the data of all participants and make a deepfake clone of them and make those clones go on dates with each other, but I realized that might not be possible in 24 hours. So keep thinking until you come up with the coolest demo that's still technically feasible. I ended up scraping people's emails to rebuild their closets and find clothing recommendations for my smart mirror instead.
And of course, it's important to generally know what's going on in the world. I'd like to scroll Twitter a lot for this and I also find great UI inspiration on Twitter. For example, for Second Self, the project that won first place in Personal AI at YHack, I pulled the core idea from a Twitter post that I saw the month before. One good tool for saving these posts is called Cosmos. It's kind of like Pinterest, but I use it for cool inspiration from all across the web. This is not sponsored by the way.
Now that you know what to build, the next part is how to build it. Obviously, you need to use an AI agent of some sort to code. Nowadays, it's not fast enough for you to just code by hand. If you want to win something, you have to use AI. And not only should you just use AI, but even just typing the prompts by hand is too slow. I use a smart voice-to-text tool called Wispr Flow to prompt about four times faster than I can type. This lets me move so much faster, even though I'm a really fast typist. Wispr Flow isn't just normal dictation. It actively polishes the mistakes, the restarts, the ums and ahs that happen naturally when you talk.
Um, like, can you like create a feature to basically let users bring in their credentials or their browser profiles? And then see how like it got rid of all my ums and ahs, and it kind of knows what I'm trying to get at even though I stumbled a lot there. Can you refactor the Barnard CS major so that Math UN 2015 can be double counted for linear algebra, and not UN, as two separate courses? Um, actually, wait, no, don't exclude groups between the two courses, because that's point. They can make three things. One... both math requirements are completed. Um, yeah. It also formats your prompts by pulling in bullet points or punctuation like you just saw with the numbered list. I find that talking naturally encourages me to think more freely, and this leads to me dictating a lot more context to my agent than if I were to type the same thing. And so this enables my agent to have more context on what I want and then do a better job. Wispr Flow works anywhere that you type. So I use it inside Claude, Cursor, Codex, uh, with their desktop and even on my phone, uh, with the iOS app. It's available on iOS and Android.
Yo Alex, you down to go to Butler? Actually no, let's go to Joe's in like five minutes. You down?
The good news is that Wispr Flow is completely free to use. And the great news is that the link in my description will get you one month of Wispr Flow Pro with unlimited words for free. Thank you so much to Wispr Flow for giving you guys this free link and for sponsoring this video. It really means a lot.
And to use an agent well, it's important to know, or at least vaguely understand, how these agent harnesses work. And by Agent Harness, I mean things like Claude Code, Codex or like Cursor. The harness is basically a wrapper over the underlying model, that handles memories, context management, routing, etc. For example, Claude Code is a harness, Codex is a harness, and Cursor Agent is also a harness. On top of the harness, you need an agent IDE. There are a lot out there, but they essentially let you manage many parallel agents at once, which is super important for developing quickly at the hackathon. I use one called Superset. Within Superset, I can create new workspaces and each workspace lives in its own git worktree, which is basically like multiple copies of the code, where I can work on a separate feature in each copy. And this lets me move a lot faster. I like Superset because it has its own integrated browser and shows all my code diffs and files in one application, so I can really see what the Agent is doing for each of these separate features. And then on top of that, there are Skills and MCPs that really help, too. Think of skills like a cheatsheet that the agent can read when it needs to do certain tasks to keep it consistent and reliable. The most important skill that I use is one called /interview. This is actually one that I created myself, and it's very simple. It just encourages the agent to keep asking me questions on anything that is unclear with my prompt until we're on the exact same page about what to do. And then it saves that as a document to refer back to later to prevent deviating from the original vision later down the line. Skills are also how I fix the problem of Claude speaking unintelligibly and producing slop designs. /better UI is an open source skill that I found that performs a UI audit of your entire app. It recommends interface improvements, animations and just general polish. /animate is a skill by LottieMotion that applies best practices of motion design and animations to add Polish animations into your app. I use these two skills to add a lot of polish and just the overall feeling of quality to whatever I make at the hackathon. /agentation is a secret skill that not very many people know about. It lets you annotate your website and feed those comments along with the ID of the actual element you're referring to back into your agent so that the agent has context on what you're talking about. I find that this speeds up my design process by at least three times, and it also lets me be a lot more clear and specific about my intentions. /ste is a skill I created that instructs Claude to adhere to something called Standard Technical English. This is basically like a language rule that just helps reduce a lot of the gibberish and slop that Claude says when it tries to explain something to you. I've noticed that Claude likes to become hyper technical and explain a lot of things that don't really make sense using words like "levers," "knobs," "counterfactual," a lot of stuff that just reads like, "It makes no sense." And adhering to Standard Technical English has really helped me fix this error with Claude. I personally usually start my projects by using the /interview skill to write a master plan on exactly what I want to build. For Opticon, the project that won Columbia's hackathon, I spent 2 to 3 hours writing the plan with my friends and having Claude interviewing me on it relentlessly. After writing a huge document, I had to split the work into independent tasks and then ran one sub agent for each task. It ran for the next 5 to 6 hours and then I manually refined for one hour with /agentation. And then I went to throw my own birthday party and went to sleep, got 7 hours of sleep, came back the next morning and won the hackathon. We essentially won a 24 hour hackathon in only 8 to 9 hours just by being very thorough with the skills and the planning process. You've also probably noticed that Claude is better at front-end design, whereas Codex is better at back-end. And since I use both, a nice skill I use is /codex which basically lets Claude spawn in a Codex sub agent when I want Codex to handle a specific feature or review Claude's work. Agents are also much better at copying than at coming up with something completely original. Pointing the agent at an example of a design you like really helps get a good starting point where you can start iterating with the skills we just discussed, like /agentation or the UI ones.
MCPs, if you don't know, are a way to connect your AI agent to external tools and services to give the AI more capabilities for the task that it's doing. For example, letting it manage your database or connecting it to your payment provider. I personally use the Supabase and Neon MCP servers to let Claude create databases automatically, apply migrations or create new tables for any feature that I'm building. I also use a Stripe MCP to set up payments for any apps that I like to work on. In general, though, agents are getting much, much better very quickly. And so sometimes having too many skills and MCPs can actually limit the AI by forcing it to adhere to certain procedures that were needed in the past to keep dumber models on track, but may stop smarter models from reaching their full potential. I recommend typing /skills in the Claude terminal and turning off all skills that aren't critical. Claude also has a system called plugins, which basically lets people bundle a bunch of skills and MCPs into one thing that you can install really quickly. If you're curious about my workflow in particular, I'm working on a plugin myself to bundle everything that I use into one thing that you can install in just one line. So comment "plugin" if you want it and I'll send it to you.
Now that you have a great idea, a great implementation, your agents are cooking, the next step is to not sleep. Most hackathons are 24 to 36 hours long and honestly, if you want to win, you can't sleep that much. For 24 hour hackathons, I tend to just pull an all-nighter and for 36 hour hackathons, I like to sleep 5 hours on the first night and then don't sleep the second night. Red Bull and anything caffeinated is really helpful for this. But for me personally, I lowkey don't even need caffeine because vibecoding just gets me going. Honestly though, it gets really bad around the 4 AM mark, so I recommend eating something around then or taking shifts with your teammates.
The next and final step is judging. At this point, you've come up with a killer idea and you've spent the last 24 to 36 hours grinding on your project. Now all that's left for you to do is pitch it to the judges. At this point, your goal is to yap for as long and as much as possible. You want to talk to the judges for as long as possible. Not only does this make them like your project more and give you more time to explain all the technical intricacies and all the things that you had to consider while building your project, but it also keeps the judges away from competitors. This might seem kind of cutthroat, but that's just how the competition goes. At this point, your amazing project idea and your beautiful technical implementation should just be enough to just blow the judges away and you'll see them get visibly engaged as you give your demo. At this point, it's up to you to really highlight all the technical intricacies of what you did and all the challenges you had to overcome. That way, you'll leave a lasting impression on the judges. Why? At YHack, I talked in depth about my motivations for building Second Self, the project that I worked on, the state of the world of AI and where I thought it was heading and why I built this project, and then most of it on a live demo of the product itself. Live demos are particularly impressive at hackathons because people tend to fake a lot of stuff that they can't get done in time. So showing a live demo that actually works will show them how much effort you put into the project and the fact that the project actually works. Finally, you'll probably fall asleep around the time of the awards ceremonies going on from just a lack of sleep over the last two days. But hopefully, you'll wake up to your name on the big screen and a nice prize in your pocket. Anyway, those have been my top tips for how to win a hackathon and the exact four step workflow that helped me win five out of five hackathons in the last year. Let me know what you think and if it was helpful and I'll see you guys in the next one. Peace.
Video
Video
