DevQuest AI
Don't study. Build.
Inspiration
Learning to code is exciting at first, but almost every developer eventually hits the same wall: they don't know what to learn next, how to practice effectively, or where they're actually improving.
Most learning platforms solve this with more content — more courses, more tutorials, more paths to pick from. But content isn't the bottleneck. Feedback is. Someone can understand frontend concepts perfectly and still freeze on backend architecture. Someone else can know the syntax cold and still lack the problem-solving instinct that only comes from getting something wrong and being told exactly why.
We didn't want to build another course platform. We wanted something closer to a mentor — one that knows what you're weak at, gives you a real problem to expose that weakness, tells you specifically what broke, and doesn't let you move on until it's actually fixed.
That became DevQuest AI.
What it does
DevQuest AI replaces passive learning with a loop: build → get evaluated → get targeted → build again.
1. Personalized engineering sprints Learners define a goal (Backend Developer, Frontend Engineer, AI Engineer) and DevQuest generates realistic engineering challenges scoped to their level — not textbook exercises, but the kind of problem a real engineering team would hand a junior dev. "Build a rate-limited API gateway that handles burst traffic" is a sprint. "What is a rate limiter?" is not.
2. An evaluation engine that explains, not just grades After a submission, DevQuest doesn't return a pass/fail score. It identifies what specifically worked and what didn't — for example, correctly implementing a token bucket algorithm, but leaving a race condition under concurrent load unaddressed. This is the part of the product we spent the most time on, because vague feedback is exactly what makes existing tutorials useless for skill-building.
3. An adaptive loop that closes the gap it just found This is the core mechanic: the specific weakness identified in evaluation becomes the seed of the next sprint. If concurrency handling is the gap, the next challenge is a different concurrency problem in a new context — not a repeat, not a hint, a fresh test of the same underlying skill. The learner doesn't move on because they finished; they move on because they've actually closed the gap.
4. An AI mentor that asks questions instead of answering them When a learner is stuck, the mentor doesn't hand over a solution. It asks the question that leads them to find it themselves — "what happens if two requests hit this at the exact same millisecond?" — because the goal isn't finishing the sprint, it's not needing the sprint anymore.
5. A skill map that reflects real mastery Every sprint updates a skill dashboard — not points or streaks, but a genuine picture of which competencies are solid and which are still being actively targeted.
How we built it
Frontend
- React + Vite for a fast, component-driven UI
- React Router for navigation across the dashboard, sprint rooms, and mentor view
- Monaco Editor for an in-browser coding environment, so learners never leave the platform to write code
- Lucide React for iconography
- Custom CSS design system built around a dark, focused, dev-tool aesthetic — deliberately closer to an engineering workspace than a course catalog
Backend
- Node.js + Express serving REST APIs
- Handles sprint generation requests, submission evaluation, progress state, and mentor conversation context
AI layer — the core of the product, not a bolt-on
- Sprint generation: prompts an LLM with the learner's stated goal, current skill map, and most recently identified gap to produce a scoped, realistic engineering challenge rather than a generic problem
- Evaluation: submissions are analyzed against the specific competencies the sprint was designed to test, producing structured, specific feedback (what worked, what didn't, why) instead of a single score
- Adaptive targeting: the weakest-scoring competency from the evaluation step is fed directly back into the next sprint-generation call, so the loop is genuinely closed — the AI isn't just generating content, it's deciding what to generate based on what it just observed
- Mentor: a guided-questioning system prompted specifically to withhold direct solutions and instead surface the next reasoning step, so the model supports independent problem-solving rather than replacing it
Development approach
- Designed the core loop first (sprint → evaluate → adapt) before any UI
- Built frontend architecture around that loop, not around generic "pages"
- Built backend APIs to support sprint generation, evaluation, and state
- Integrated the AI layer and iterated heavily on evaluation-prompt quality, since vague evaluation would have broken the entire adaptive mechanic
- Connected the skill-tracking system to real evaluation output, not simulated data
- Tested and refined the end-to-end experience
Challenges we ran into
Making evaluation actually specific. Early versions of our evaluation prompts produced generic feedback ("good job, consider edge cases"). That's worthless for an adaptive system — if the gap identification isn't precise, everything downstream (the next sprint, the skill map) is adapting to noise. We spent significant time getting evaluation output structured and specific enough to be genuinely actionable.
Designing personalization that doesn't overwhelm beginners. A system that surfaces every weakness at once is discouraging, not motivating. We had to think carefully about pacing — targeting one gap at a time rather than listing everything wrong.
Building a mentor that resists just answering. The default behavior of most LLM integrations is to solve the problem when asked. Getting the mentor to consistently ask a guiding question instead took real prompt iteration, not a single instruction.
Full-stack integration under time pressure. Connecting sprint generation, evaluation, and the skill dashboard into one coherent state — with real API communication, not mocked data — surfaced the usual real-world issues: environment configuration, error handling, and keeping the frontend in sync with backend state.
Accomplishments we're proud of
- Built a complete, working full-stack application — frontend, backend, and a genuinely closed-loop AI system, not three disconnected pieces
- Designed an evaluation engine that gives specific, actionable feedback instead of a score
- Made the adaptive loop real: the AI observes a weakness and generates the next challenge to address it, rather than following a fixed curriculum
- Designed a mentor that supports problem-solving instead of replacing it
- Solved a problem we've personally hit — knowing what to build next, not just what to study next
What we learned
Evaluation is the hardest and most important part of an adaptive system. Everything else — personalization, the skill map, the sense of progress — is only as good as the evaluation step underneath it.
AI is most valuable as a collaborator, not an oracle. The mentor is more useful when it withholds the answer than when it gives one.
Product thinking matters as much as implementation. Deciding what to build (a closed feedback loop) mattered more than any individual technical choice.
Iteration on prompts is real engineering work. Getting the evaluation and mentor prompts to behave consistently took as much iteration as any backend feature.
What's next for DevQuest AI
- Deeper personalization — using a fuller history of a learner's submissions, not just the most recent gap, to shape sprint generation
- AI code review as a standing feature — ongoing feedback on code quality and best practices, not just pass/fail on sprints
- Real-world project arcs — multi-sprint projects that mirror how actual engineering work is scoped, not just isolated challenges
- Deeper skill analytics — tracking growth over time, not just current state
- A developer community layer — letting learners see (and learn from) how others approached the same sprint
DevQuest AI is built on one belief: developers don't get better by consuming more content. They get better by building real things, getting specific feedback on what broke, and being pushed toward exactly what they haven't mastered yet — again and again, until they have.
Log in or sign up for Devpost to join the conversation.