DEV Community: Prakhar Gupta

Online Judge

Prakhar Gupta — Sat, 24 Oct 2026 10:56:54 +0000

OnlineJudge 🦥 — Making Competitive Programming Debugging Less Painful with Open-Source AI

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Anyone who practices competitive programming knows this feeling.

You submit your C++ solution. You wait for the verdict.

Wrong Answer.

You reread your code, check the conditions, inspect the loops, and try another test case. Somehow, the bug is still there.

Sometimes, the problem isn't the algorithm itself. It's a single incorrect boundary, an overlooked edge case, or a small logical mistake that takes far too long to find.

I wanted to make this process less frustrating.

Introducing SlothJudge 🦥, an AI-powered debugging assistant designed to help competitive programmers investigate failing solutions without doing all the repetitive debugging work manually.

The project builds on my experience developing an online judge:

🔗 Existing project: Online Judge on GitHub

The idea behind SlothJudge is to bring open-source AI into the competitive programming workflow and make debugging more efficient.

The planned workflow is straightforward:

Investigate bugs: Provide C++ code, a problem statement, and a verdict to receive possible explanations for the failure.
Find tricky cases: Generate edge cases that could expose weaknesses in the solution.
Suggest minimal fixes: Focus on the suspicious condition or logic rather than rewriting the entire program.
Explain the problem: Understand why a potential bug occurs instead of blindly copying a corrected solution.
Keep learning: Use AI as a debugging companion while retaining control over the final implementation.

The goal isn't to replace the programmer or reveal complete solutions automatically. It's to help programmers get unstuck and spend more time learning algorithms.

Demo

GitHub repository: https://github.com/rot44/Online-Judge

Live application: [Add your verified deployment URL here]

Video demonstration: [Add a screen recording here]

The demonstration will show a real debugging scenario:

Submit a C++ solution containing a known bug.
Provide the problem statement and failure details.
Ask SlothJudge to investigate the likely cause.
Review the diagnosis and suggested edge cases.
Fix the issue and verify the solution against the relevant tests.

The aim is to demonstrate how AI can reduce repetitive debugging effort, not merely generate code.

Code

The existing Online Judge project is available here:

rot44/Online-Judge — GitHub Repository

I'll use this project as the foundation for exploring a more intelligent competitive programming workflow.

The repository currently represents my existing Online Judge work. Any SlothJudge-specific AI features will be documented separately and demonstrated once implemented.

AI implementation branch or repository: [Add the link when available]

How I Built It

The objective is to integrate an open-weight language model into a debugging workflow rather than rely entirely on a proprietary AI API.

Planned technology stack

Frontend: A web interface for submitting code and viewing debugging reports.
Backend: Node.js and Express for request handling and prompt construction.
AI inference: Ollama for running a compatible model locally.
AI model: Gemma, Google's open-weight model family.
Target language: C++, with other languages as potential future additions.

Architecture

The workflow is designed around five steps.

1. Input collection

The user supplies the source code, problem statement, programming language, and failure information.

2. Context preparation

The backend constructs a structured prompt containing the relevant information. The prompt instructs the model to investigate likely errors and prioritize minimal, educational hints.

3. Open-weight model inference

A compatible Gemma model processes the request through Ollama. When configured for local inference, the code can remain on the user's machine.

4. Debugging report

The model's response is presented as a structured report containing a likely cause, an explanation, potential edge cases, and a suggested correction.

5. Human verification

The programmer reviews the suggestions and tests the code independently. The AI provides assistance rather than guaranteeing correctness.

This design keeps the debugging workflow focused on learning and makes the model replaceable as better open-weight alternatives become available.

Why Does Open Innovation Matter?

For SlothJudge, open innovation is about more than choosing a different model. It gives developers greater control over how AI fits into their everyday workflow.

1. Privacy through local inference

Source code can contain unfinished solutions, personal notes, or experimental implementations.

When the model runs locally and the application does not send inputs to external services, the debugging workflow can keep that code on the user's own machine.

This is particularly valuable for programmers who prefer not to send their code to a third-party AI API.

2. Reduced dependence on paid APIs

Debugging is iterative. A programmer may need several rounds of feedback before identifying the actual problem.

Local inference avoids per-request charges from a hosted model API. Users still need compatible hardware, storage, electricity, and the time to set up the model, but repeated requests do not incur a separate model API fee.

That makes frequent experimentation more accessible to students.

3. Freedom to experiment

An open-weight model allows developers to experiment with different model sizes, inference settings, and prompts.

For example, I could compare how different models handle:

Off-by-one errors in binary search.
Incorrect visitation logic in BFS and DFS.
Boundary conditions in dynamic programming.
Integer overflow and unusual input constraints.

These experiments could help determine which model is most useful for competitive programming rather than relying on assumptions about model quality.

4. A debugging workflow designed for programmers

A general-purpose chatbot can explain code, but a dedicated assistant can organize its output around the actual debugging process.

The prompts can prioritize minimal fixes, suspicious conditions, edge cases, and educational explanations.

The objective is to make the AI useful for learning rather than simply returning a complete replacement solution.

5. The possibility of offline use

Once the model, dependencies, and application are installed, the core workflow can operate without internet access, provided it does not depend on remote APIs or online judge services.

That means the debugging assistant can remain useful even when a hosted AI service is unavailable.

Open innovation does not automatically make a model more accurate than a closed model. What it offers here is control, flexibility, local execution, and the ability to experiment without being locked into one provider.

My Agent Session

Agent session: [Add your DevRelay session link here, if available]

I plan to share the development session to show how the project evolved, including prompt design, implementation decisions, debugging iterations, and lessons learned.

This section is optional and will be completed if I have a suitable session to share.

The Lazy Payoff

The whole point of SlothJudge is to reduce the repetitive work between receiving a failed verdict and understanding what went wrong.

Imagine spending 20 minutes manually inspecting a solution, trying random inputs, and rereading the same conditions.

A useful AI diagnosis might narrow the investigation to a single incorrect boundary condition or an edge case that was never considered.

That doesn't mean every bug will be fixed instantly. Some problems require substantial algorithmic reasoning, and AI-generated diagnoses can be wrong.

The aim is to reduce blind trial and error and give the programmer a more focused starting point.

To evaluate the project, I plan to test it against a collection of known C++ bugs and record:

Whether the model identifies the underlying issue.
Whether the generated test cases expose the bug.
The time taken to generate a report.
How useful the feedback is compared with manual debugging.

I'll report actual measurements once the evaluation is complete rather than claim time savings without evidence.

After all, a project about saving time should demonstrate that it really saves time.

Prize Categories

Primary target: Best Use of Gemma — $200

SlothJudge is designed to use Gemma as its open-weight debugging model through local inference with Ollama. This category is relevant once that integration is implemented and demonstrated.

Overall challenge: Hacktoberfest Open-Source AI Challenge Week 3 — $250

The project targets the Slow and Steady theme by exploring how open-source AI can reduce repetitive debugging work for competitive programmers.

The prize categories are goals for the submission, not a claim of eligibility or a guarantee of winning.

Final Thoughts

I'm interested in building tools that make learning to code less frustrating.

Competitive programming is already challenging enough. Spending excessive time searching for a tiny bug can make the experience even harder, especially when you're learning a new algorithm or technique.

SlothJudge explores whether open-weight AI can help programmers investigate failures, discover edge cases, and understand their mistakes while keeping control of their code.

The larger idea is simple: use AI to reduce repetitive effort without removing the learning process.

Build less frustration. Debug smarter. Stay lazy. 🦥

devchallenge #hf26challenge #opensource #AI #Cplusplus #CompetitiveProgramming #Gemma

Flora Quest

Prakhar Gupta — Sat, 10 Oct 2026 12:02:46 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

FloraQuest-AI is a lightweight, offline-first web companion designed to get you off the screen and into nature in under 60 seconds.

Features:

Offline Specimen ID: Identify trail leaves, trees, and birds using open-weight vision models (MobileNet-v2) running directly in your browser.
Fall Foliage Route Scout: Generate 15–90 min trail loops with a 3-item sensory scavenger hunt.
Frost & Soil Radar: Know what to sow (garlic, winter greens, bulbs) before the first freeze.
Screen-Off Mode: Ambient forest breeze synthesizer to encourage pocketing your phone.

Demo

Open index.html in your browser.
Works 100% offline with zero API keys required.

Code

GitHub: https://github.com/SrujanTag/FloraQuest-AI

How I Built It

Open-Weight AI: Hugging Face @xenova/transformers running MobileNet-v2 directly on-device in WebAssembly.
Stack: HTML5, Vanilla CSS, Vanilla JS, and Web Audio API for offline forest sounds.
Local Fallback: Built-in offline trail database for zero-signal environments.

Why Does Open Innovation Matter?

Runs with No Signal: Deep in the woods or on trails, closed cloud APIs don't work. Open weights run on your device without cell reception.
Privacy: Photos and GPS location never leave your phone.
Zero Cost: $0 in API fees or server hosting costs.

My Agent Session

Built with Antigravity AI pair programming assistant.

Prize Categories

Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

Repo Chatter

Prakhar Gupta — Sat, 03 Oct 2026 18:21:19 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

Repo Chatter lets you paste any public GitHub repository URL and ask questions about its README in plain English. The app fetches the README, indexes it, and answers using only what the documentation says. Every answer shows the exact README chunks it was based on, so you can verify the source yourself. If the README doesn't cover your question, the app says so instead of guessing.

The app also tracks commit activity for each added repo through an hourly background job, and the interface uses a custom black-and-white design with a cursor-following glow and a scroll-driven landing page.

I built this for my teammate *@attlar *, who regularly digs through unfamiliar open-source projects to find a single install command or environment variable. Reading a long README for one detail is slow. With Repo Chatter, it's one question away.

Demo

🔗 Live app: https://repo-chatter.netlify.app/

Code

The full source is on GitHub:

loveyadav1015 / RepoChatter

Repo Chatter is an AI-powered RAG application that allows users to chat with public GitHub repository READMEs through a cinematic, monochrome interface, providing grounded answers with source citations and tracking commit activity.

Repo Chatter 🚀

Chat with any GitHub repository's README using AI-powered RAG — wrapped in a cinematic, monochrome interface.

Repo Chatter lets developers paste a public GitHub repository URL and instantly ask natural-language questions about its README — grounded strictly in the actual documentation, with source citations. It tracks repository commit activity in the background via a scheduled job, and presents it all through a custom black-and-white interface with a cursor-reactive glow and an illustrated scroll-triggered landing hero.

Built as a submission for OverEngineered — the Web Development Wing selection process.

🎯 Features

📚 Add Any Public Repo — paste a GitHub URL, README is fetched and indexed automatically
💬 Grounded Q&A — ask questions in plain English, get answers based strictly on the README (no hallucination — the model explicitly refuses to answer outside the provided context)
📍 Source Citations — every answer shows exactly which README chunks were…

View on GitHub

How I Built It

Frontend

React with Vite
shadcn/ui components
GSAP with ScrollTrigger for the scroll-driven hero
Tailwind CSS and Axios

Backend

Node.js and Express (ESM), organized into routes, controllers, and services
Raw PostgreSQL driver (pg) with parameterized queries throughout
node-cron for scheduled jobs

Database

PostgreSQL 16 with the pgvector extension
Exact k-NN similarity search, which is correct and fast enough at this scale

AI models

Embeddings: sentence-transformers/all-MiniLM-L6-v2, an open-weight model that produces 384-dimension vectors, served through the HuggingFace Inference API
Generation: Mixtral 8x7B, an open-weight mixture-of-experts model, served through Groq for fast inference

Both models are open-weight, but the current deployment calls them through hosted APIs rather than running them on my own servers. Each model call sits behind a service adapter, so moving to a self-hosted model is a change to one module.

Infrastructure

Docker Compose for the local stack (database, backend, frontend)
Netlify for the static frontend
Render for the backend and the managed PostgreSQL database

How the RAG Pipeline Works

Repo Chatter has two flows. Ingestion runs when a repo is added. Retrieval and generation run when a question is asked.

Ingestion: when a repo is added

flowchart LR
    A[GitHub URL] --> B[Fetch README<br/>GitHub REST API]
    B --> C[Chunk<br/>~500 chars each]
    C --> D[Embed each chunk<br/>384-dim vectors]
    D --> E[(repo_chunks<br/>pgvector column)]

Retrieval and generation: when a question is asked

flowchart LR
    Q[User question] --> EQ[Embed question<br/>same model]
    EQ --> R[Retrieve top 5 chunks<br/>cosine distance]
    E[(repo_chunks)] --> R
    R --> G[Generate grounded answer<br/>Groq, Mixtral 8x7B]
    G --> A[Answer + source chunks]
    A --> H[(chat_history)]

Step by step

Fetch: the backend retrieves the README through the authenticated GitHub API. Authentication raises the rate limit well above the 60 requests per hour allowed for anonymous calls.
Chunk: the README is split into fixed-size chunks of about 500 characters.
Embed: each chunk is converted into a 384-dimension vector.
Store: chunks and vectors are saved to the repo_chunks table.
Embed the question: the question goes through the same model, so it lives in the same vector space as the chunks.
Retrieve: pgvector returns the five chunks with the smallest cosine distance to the question.
Generate: the model receives the question and those chunks, with instructions to answer only from that context.
Respond and log: the answer and its source chunks are returned to the frontend and saved to chat_history.

When the README doesn't cover the question, the response looks like this:

{
  "answer": "I don't know, this isn't covered in the README.",
  "sourceChunkIds": ["..."],
  "sourceChunkTexts": ["..."]
}

Commit Tracking

An hourly node-cron job keeps commit data current for every tracked repository:

flowchart LR
    T[Hourly tick] --> L[Load tracked repos]
    L --> F[Fetch commits since last_fetched<br/>GitHub API, paginated]
    F --> I[Insert into commit_logs<br/>ON CONFLICT DO NOTHING]
    I --> U[Update commit_count<br/>and last_fetched]

First run: fetches up to 100 recent commits, with pagination handled explicitly.
Later runs: fetches only commits newer than last_fetched.
Deduplication: a unique constraint on (repo_id, commit_hash) means reruns never create duplicate rows.

Database Design

Table	Purpose
`tracked_repos`	Repo URL, owner, cached README, fetch and embed timestamps, commit count
`repo_chunks`	README chunks with 384-dim pgvector embeddings
`commit_logs`	Commits fetched by the cron job, unique on `(repo_id, commit_hash)`
`chat_history`	Each question, its answer, and the source chunks it cited

Why Does Open Innovation Matter?

Open models are what made this project practical.

Cost: the embedding model is open-weight, so re-indexing a repo doesn't add a per-chunk charge on someone else's bill.
Reproducibility: because I can pin a specific model version, retrieval behavior stays consistent over time. A closed API can change under you without notice.
Flexibility: the service adapters let me swap in a different open model, or self-host one, without rewriting the retrieval or generation logic.
Inspectability: with open weights, I can test how the model behaves and read exactly what the retrieval step sends to it.

Prize Categories

Best Use of Render ($200 USD) : The Express backend (RAG ingestion, retrieval, generation, and the hourly commit job) and the managed PostgreSQL database both run on Render.