Skip to content
All articles

Guides

How to use AI at a hackathon: vibecoding that leads to victory

How to squeeze the most out of Cursor, Claude, and Copilot over the weekend, where AI helps and where it sinks teams, and what the jury asks about it.

3 min readКоманда Stavleak
How to use AI at a hackathon: vibecoding that leads to victory

Vibecoding is no longer something to be ashamed of: almost everyone codes with AI at hackathons, and the question has long ceased to be "is it allowed" but rather "how to do it to win, not drown in someone else's code." AI gives a huge head start in speed and just as easily leads a team into a dead end. Let's look at how to use it wisely.

Where AI really saves hours

It helps most with boring and repetitive tasks, where you already know what the result should be.

  • Project boilerplate, environment setup, configs that you usually copy from a previous project.
  • Boilerplate: forms, CRUD, API wrappers, interface layout.
  • One-off scripts, test data, parsing, formatting.
  • Quickly understanding an unfamiliar library or error instead of spending half an hour searching.

For these tasks, Cursor, Claude, Copilot, and similar tools provide a genuine, multi-fold advantage. Hand over the routine to them without regret.

Where vibecoding sinks teams

That exact same speed works against you if you turn off your brain.

  • Key logic that the demo depends on. If you don't understand what the model generated, you won't fix it at 3 AM.
  • Large, vague requests like "make me an app." The model outputs a mountain of code that is then impossible to assemble into a whole.
  • Blind trust. AI confidently writes plausibly incorrect code, and debugging takes longer than what you saved.

The rule is simple: hand over the boring stuff to AI, keep the important stuff under control, and understand it line by line.

How to prompt to avoid rewriting

  1. Provide context in small chunks, rather than "do everything at once." One screen, one function, one request.
  2. State what you already have and what your stack is, so the model doesn't reinvent the wheel.
  3. Ask to explain the generated code. If the explanation is vague, the code is too.
  4. Don't fight with the model in circles. If it doesn't work after two or three attempts, write it yourself—it's faster.

What the jury asks about this

Judges this season have seen hundreds of projects put together in an evening with AI, and they've learned to distinguish a team that built from a team that just pressed a button. During the pitch, they will almost certainly ask how the key part works. The answer "Cursor generated it this way" drops your score instantly. Understanding your project is more important than writing more of it. How to distinguish a real AI project from a wrapper is discussed separately.

Prepare before the start

Tools, accounts, and API keys should be set up at home, not during the first hour at the venue. At well-organized events, access to the necessary models is provided centrally: for example, on Stavleak, organizers distribute sponsors' API keys to participants directly in their personal accounts, so you don't burn your own limit or collect cards in chats. Which tools to install in advance is compiled in a separate guide, and you can find an event in the hackathon catalog.