This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend
What I Built
My friend has been learning to code for about six months. Whenever he hit an error, he would paste it into an AI chatbot, copy the corrected code, and move on.
The problem: the code was fixed, but he wasn't always learning how to debug it himself.
So I built DebugCoach, an AI debugging tutor that teaches instead of immediately giving away the answer.
DebugCoach takes a user's code and error message and guides them through a progressive hint system:
ERROR
↓
HINT 1
↓
THINK
↓
HINT 2
↓
THINK
↓
HINT 3
↓
TRY
↓
SOLUTION
The first hint is conceptual and spoiler-free. Each additional hint gets more specific. Only after the full hint progression does DebugCoach reveal the complete solution, explain the mistake, identify the underlying concept, and provide a practice question.
For example, take this off-by-one error:
numbers = [10, 20, 30]
for i in range(len(numbers)):
print(numbers[i + 1])
Instead of immediately fixing i + 1, DebugCoach progressively guides the learner toward realizing that index 3 doesn't exist.
I built this specifically for my friend because I wanted to solve a real problem I had watched him experience: using AI to fix bugs without understanding why they happened.
Demo
🎥 Demo: [https://youtu.be/VWFA8CnQMMQ]
The demo shows the complete DebugCoach experience, from submitting broken code to receiving progressive hints and finally seeing the solution.
Code
🐛 DebugCoach
An AI debugging tutor that helps you fix your code — without immediately giving you the answer.
Most AI tools hand you the solution the moment you paste an error. DebugCoach doesn't. It guides you through progressive hints so you actually understand what went wrong.
Paste Code + Error
↓
💡 Hint 1 → think
↓
💡 Hint 2 → think harder
↓
💡 Hint 3 → almost there
↓
🎓 Solution + Explanation + Practice Question
Built for the Hacktoberfest Weekend Challenge 2026.
Tech Stack
Layer
Technology
Frontend
React 19, Vite
Backend
Python, FastAPI, Pydantic
AI
Open-weight model (Llama 3 / Mistral via Groq)
Dev tooling
Amazon Q Developer
Project Structure
DebugCoach/
├── backend/
│ ├── main.py # FastAPI app, CORS, /analyze endpoint
│ ├── ai_service.py # Model calls, JSON parsing
│ ├── prompts.py # Hint level prompts + solution prompt
│ ├── schemas.py # PydanticThe repository contains the complete React frontend and FastAPI backend.
Project structure:
DebugCoach/
├── backend/
│ ├── main.py
│ ├── ai_service.py
│ ├── prompts.py
│ ├── schemas.py
│ └── requirements.txt
│
└── frontend/
└── src/
├── components/
│ ├── HintCard.jsx
│ ├── SolutionCard.jsx
│ └── ProgressBar.jsx
├── App.jsx
├── api.js
└── App.css
How I Built It
DebugCoach is built around an open-weight model, Qwen 3, served through Groq.
- Frontend: React 19 + Vite
- Backend: Python + FastAPI
- Validation: Pydantic
- AI: Qwen 3 (open-weight) via Groq
- Coding agent: Amazon Q Developer
The core AI integration lives in backend/ai_service.py. The hint engine uses a different prompt depending on the hint level:
- Hint 1 (Conceptual): Explains the general concept without giving away the answer.
- Hint 2 (More Specific): Can reference variables, loops, boundaries, or other relevant parts of the code.
- Hint 3 (Almost the Answer): Points toward the exact expression or line causing the problem without giving the corrected code.
- Final Solution: The user can then reveal the complete solution, including the underlying concept, what went wrong, corrected code, an explanation, and a practice question.
The model returns structured JSON so the React frontend can reliably decide whether to show another hint or the final solution:
{
"hint": "Think about the largest valid index.",
"question": "What happens when i reaches the last position?",
"concept": "Off-by-one error",
"hint_level": 1,
"is_final": false
}
The architecture is intentionally simple:
React
↓
FastAPI
↓
Hint Engine
↓
Qwen 3
↓
Structured debugging response
I also used Amazon Q Developer during development to help scaffold the FastAPI backend, build React components, work with Pydantic schemas, and debug issues such as CORS and model-response parsing.
Why Does Open Innovation Matter?
I chose an open-weight model because it powers the core tutoring experience. Here is what that makes possible that a closed API wouldn't.
1. Privacy
Users paste source code into DebugCoach. That code could come from a personal project, a university assignment, or other work they don't want to send to a proprietary AI system.
Because the model is open-weight, DebugCoach can be adapted to run locally with a tool such as Ollama, so the entire AI experience can run on the user's own machine:
React
↓
FastAPI
↓
Local inference
↓
Open-weight model
The user's code can stay on their computer.
2. The Model Is Swappable
I isolated the AI integration inside ai_service.py. The frontend, API, schemas, and hint engine don't need to know which model is being used.
That means I can experiment with different open-weight models without rebuilding the application, and the project isn't tied to a single proprietary provider.
3. The Model Can Be Customized
Because the model is open-weight, there's room for future experimentation. A future version of DebugCoach could be tuned specifically for beginner programmers and debugging pedagogy, getting better at:
- Giving progressive hints
- Explaining common programming mistakes
- Teaching debugging concepts
- Adjusting explanations for beginners
- Supporting additional programming languages
The model isn't just an API I consume. It's something I can experiment with, replace, run locally, and potentially customize.
My Agent Session
Here's what a DebugCoach session looks like for the off-by-one example. This is an illustrative walkthrough of how the hint flow plays out:
numbers = [10, 20, 30]
for i in range(len(numbers)):
print(numbers[i + 1])
Error: IndexError: list index out of range
Hint 1 (Conceptual): Think about the largest valid index in a list. How does counting positions in a list start?
Think: The learner pauses and tries to work out what the valid indexes are.
Hint 2 (More Specific): Look at your loop. What is the last value i takes, and what does i + 1 become at that point?
Think: The learner traces the loop by hand.
Hint 3 (Almost the Answer): The problem is in the expression inside print(). At the final iteration, it asks for an index that doesn't exist.
Try: The learner attempts the fix on their own.
Solution: DebugCoach reveals the corrected code, explains why numbers[3] fails on a 3-item list, names the concept (off-by-one error), and gives a practice question to reinforce it.
The goal is that the learner finds the bug themselves, with the answer as a last step rather than the first.
Top comments (0)