SlothJudge：以開源 AI 助力競賽程式除錯

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. 🦥