I worked on the platform as a consultant with HackerEarth, and after going through a lot of challenges I finally have a proper workflow. So I decided to write the guide I wish I had on my first day. This is a full walkthrough, screen by screen, with what each part does, how I actually used it, and the mistakes I made so you don't have to.

If you are a student, a fresher, or just someone curious about how LLMs perform on real coding tasks, this one is for you.

First, what is VibeCodeArena?

VibeCodeArena is a platform made by HackerEarth where LLMs go head to head on coding challenges in real time. The tagline on the homepage says it pretty well: watch LLMs go head to head, vote for the best, and level up your AI intuition.

The basic idea is simple:

1. Someone writes a prompt, like "build a wallet tracker" or "build a movie night planner".
2. AI builds the first version of the app. This is called the original challenge.
3. People like you and me take that challenge, open a sandbox, pick an LLM, and try to make the app better.
4. Every version gets evaluated and voted on, and the results feed into a leaderboard of both models and users.

So it's not just "ask AI to build something". It's more like a playground where you compete with AI, work with AI, and see which LLM is actually good at what.

Step 1: Browse the projects

The homepage has featured projects at the top, and when you scroll down you get the full list of projects.

The project list with the winning model, category, responses and score

Every row shows you four useful things:

• Projects: the prompt the app was built from
• Winning Model: whoever has the best version right now. This can be an LLM or a user
• Category: what kind of app it is, like Game, Hospital Management App, Wallet Balance Tracker App or Dynamic Pricing System
• Responses and Score: how many versions people have submitted and how good the best one is

You can search projects, filter by category, or filter by winning model. There is also a New Project button if you want to start from your own prompt.

My tip: when you are starting out, pick a project with a simple category and a clear prompt. A small HTML, CSS and JavaScript app is a much better first challenge than a full-stack app with a separate backend.

Step 2: Open a project and read the original challenge

When you click a project, you land on the original challenge page.

The original challenge: the full prompt on the left, the code on the right

On the left side you get two things:

• The full prompt. Read it properly, all of it. Click "Show more" if it is long.
• All Responses. A ranking of every submitted version, with its score and votes.

On the right side there are tabs for Code, Preview, Metrics and History, plus a Download button and the big Challenge button.

Let me give you a real example. One of the challenges I looked at was a Wallet Balance Tracker. The prompt said to use only HTML, CSS and vanilla JavaScript. Each transaction has a type, "add" or "spend", and an amount. Everything has to be stored in Local Storage under a fixed key, the app has to load transactions on page load, and if storage is empty it should start with a predefined list. And the important rule: "spend" should reduce the balance only if there is enough balance.

My tip: before touching anything, write down every rule from the prompt as a small checklist. Rules like "only if sufficient balance exists" are exactly the kind of thing AI quietly skips, and they are exactly what the evaluation catches. When you test the app later, you test it against this checklist.

Step 3: Click Challenge and open the sandbox

This is where the real work starts. When you click Challenge, a full sandbox environment opens.

The sandbox: chat on the left, a full VS Code style workspace on the right

On the left you have the chat with the LLM, with the original prompt at the top and a box at the bottom that says "Describe what you want to build today".

On the right you get a proper workspace. In this example, a document chase tracker built with Next.js and Express, the workspace runs on a HackerEarth OpenVSCode Server. You can see the project folders, like backend and frontend, a Makefile, and a terminal at the bottom. The terminal was already running the frontend with a make command, and you could see Next.js starting up on a local port.

At the top there are tabs for Code, Preview, Metrics, History and Activity, plus Run App and Submit Challenge.

My tip: the terminal is the first place I look. If the app does not start, the error is usually sitting right there. Copy the exact error into your prompt instead of saying "the app is not working". The LLM fixes it much faster when it can see the real error.

Step 4: Pick your LLM

Right under the chat box there is a dropdown where you choose which LLM you want to work with. In the screenshot below I had DeepSeek V4 Flash selected.

Choosing the LLM from the dropdown, and checking the app in Preview

This is the part that makes VibeCodeArena different from just using an AI tool on its own. Because everyone is working on the same kind of challenges, you start to get a feel for how different models behave. Some reply super fast. Some take more time but understand the problem better. Some are very confident even when they did not fix anything.

My tip: if you want to really understand a model, stick with it for a whole project. Switching models every two prompts makes it hard to tell who actually fixed what.

Step 5: Check the Preview on every screen size

The Preview tab shows you the running app. At the top you can switch between Desktop Auto, Tablet 768px and Mobile 390px, and there are buttons to open the preview in a new tab or refresh it.

In the setlist manager example above, built with Vue and Django, the preview showed a Track Library page with an "Add New Track" button and a search box that said "0 of 0 tracks shown".

My tip: empty states like "0 of 0" are your cue to test the main flow straight away. Add a track. Search for it. Refresh and see if it is still there. A page can look beautiful and still not save a single thing. And always check the mobile view, because that's where layouts usually break.

Step 6: Read the Metrics tab (seriously, read it)

This tab honestly became my best friend.

The Metrics tab: scores by category and every issue by severity

The Metrics tab evaluates the app across five categories: Security, Code Quality, Correctness, Performance and Accessibility. For each one it shows a score and a count of issues by severity: Blocker, Critical, Major, Minor and Info. It also shows token usage (total tokens, tokens in and tokens out), and below that it lists the actual major issues with the file they are in.

Here's why it matters. On one movie night planner project, the overall score was 94%. Sounds amazing, right? But when I looked closer:

• Correctness was 88, with 36 major issues
• Code Quality was 86, with 20 major, 19 minor and 30 info issues
• One of the major issues was a missing self parameter in a Python file called env.py

So a high overall score was hiding a lot of real problems. If I had only looked at the 94%, I would have thought the app was basically done.

My tip: treat the Metrics tab as your to-do list. Start with Blockers and Critical issues if there are any, then Majors, especially Correctness. Leave Minor and Info for the end.

Step 7: The prompting loop

Once you know what's wrong from the terminal, the preview and the metrics, you start prompting. This is the loop I followed on every project:

1. Audit first. My first prompt was always some version of "check what's already built, what's working and what's missing". Never ask it to build from scratch, because the app already exists.
2. Fix errors first. If the app does not run, nothing else matters.
3. Fix the main flow. Can a user do the main thing the prompt asked for?
4. Then the UI. Contrast, spacing, dark mode, mobile layout.
5. Check after every reply. Preview, terminal and metrics. Every single time.

A real example from my work: one app had a catalog that kept loading forever. My prompt was exactly how I would say it: "why loading catalog is showing for so much time and even after refreeshing and clicking on retry it's not loading". The LLM changed something and said it was fixed. It wasn't. So my next prompt was "still the issue persit of the loading catalog problem please find a fix and load the data". That's when it finally looked at where the data was coming from, instead of just changing the spinner.

Another one: in dark mode, the text on the show details screen turned white and you couldn't read it. I described exactly what I clicked, what I saw and what I wanted, and asked it to fix it for all screens, not just one. It fixed it everywhere in one go.

My tip: describe what you see, not what you think the bug is. And one problem per prompt. Every time I put four requests in one prompt, two got done properly and the rest got rushed.

Step 8: Edit the code yourself when it makes sense

You don't have to do everything through prompts. The Code tab and the workspace let you edit files directly.

I mostly prompted, because that's where you learn how the LLM thinks. But if something is a one line fix and you already know exactly what it is, like a wrong colour value or a typo in a label, it can be faster to just fix it yourself. Use your judgement.

Step 9: Submit the challenge

When the app runs, the main flow works, the major issues are handled and the UI looks right, click Submit Challenge. Your version gets evaluated and goes into the responses list for that project, where it can be scored and voted on.

My tip: before submitting, do one last pass with your checklist from Step 2. Go through every rule in the prompt and test it in the preview. It takes five minutes and catches a surprising number of things.

Step 10: Check the leaderboard

The leaderboard ranks both models and users using an eval score, an Elo rating, win percentage against the average, a confidence level and a trend.

The models leaderboard

In the snapshot I looked at (16 Oct 2026), DeepSeek-v4-Flash was the top model, followed by Gemini 3.1 Flash Lite Preview and Claude 3.5 Sonnet.

Models and users ranked together

The users leaderboard

The coolest part for me was that the top users had higher eval scores than the top model. That makes total sense once you have used the platform: a user's submission is a human and an LLM working together, and that combination beats the model alone.

Mistakes I made (so you don't have to)

• Trusting "fixed". The LLM said "issue resolved" so many times when nothing had changed. Always check the preview.
• Vague prompts. "Fix the UI" gets you a random UI change. Say exactly what is wrong and where.
• Too many asks at once. One problem per prompt.
• Polishing too early. I once spent time on styling while the main page didn't even load properly.
• Small changes breaking big things. Sometimes one small change messed up something that was working before. Keep prompts small, and re-test the main flow after bigger changes.
• Losing track across projects. I was handling 3 to 4 projects at a time. Keep a few lines of notes per project: what's fixed, what's pending, what you asked last.

Quick FAQ

Do I need to know coding? You can prompt without writing code, but knowing the basics helps a lot. I could guide the LLM properly only because I understood how a web app works and what a broken data call looks like.

Can I edit the code manually? Yes, through the Code tab and the workspace.

Which LLM is the best? It depends on the task, and the leaderboard keeps changing. Try a few, and stick with one per project so you can actually compare.

What's the most useful feature? For me, the Metrics tab. It turns "something feels wrong" into an actual list of issues.

Final thoughts

VibeCodeArena taught me that working with AI is less about typing code and more about thinking clearly. Reading the prompt properly, spotting what's broken, explaining it in simple words and checking the result. Those are the same skills that make someone a good developer anywhere.

I went in thinking I would learn about LLMs. I came out a better debugger and a much clearer communicator. If you try it, start small, read the metrics, and never trust "fixed" without checking.

If you have questions about any step, drop them in the comments and I will try to help.