Why we built this
In 2024, Kevin and I started HackQuest because we kept watching the same thing happen. Developers who were good at their jobs, people with years of production experience, would decide to switch stacks and spend weeks reading tutorials and watching videos. Then they would write code and it would be wrong in specific, predictable ways. Not because they were incapable, but because the training they had done did not generate feedback on actual code.
The gap is not knowledge of the language. It is the distance between recognizing correct code and producing it. You can read about Go error handling and understand it completely. Writing it correctly under time pressure, while also thinking about the feature you are building, is a different skill that you only build by writing code and having it corrected.
The standard tooling for this does not work well. Video courses walk you through examples that you watch. Coding exercises give you toy problems disconnected from anything you actually care about. Code review from a senior colleague is excellent but dependent on someone else's availability and limited by what they choose to explain. None of these things close the feedback loop between "I wrote code" and "here is the specific concept I got wrong."
What HackQuest does
HackQuest grades pull requests. Not for whether the code should merge, but for what concept the developer is still missing. You submit a PR to a practice branch, and we read the full diff, identify concept-level errors (not just syntax), and queue the next lesson based on what you got wrong.
The key word is concept-level. Most automated code analysis tools work at the syntax or static analysis level. They can tell you that you forgot to check an error return. HackQuest tells you that your error handling code reflects a pattern common in developers coming from exception-based languages and that the specific mental model shift required is treating errors as values that travel through the call chain. That distinction changes what the next lesson is.
We also track recurrence. If the same concept gap appears in three consecutive PRs, the lesson priority for that concept rises. A developer who keeps making the same class of error is not missing a correction. They are missing the underlying model that would make the correction stick. The lesson that addresses the model is different from the lesson that addresses the symptom.
Who it is for
HackQuest is built for working developers making a stack switch. Not beginners learning to code. Not developers exploring a language as a hobby. We built this for the developer who is already skilled and who needs to become productive in a new stack within a specific timeframe, usually because their team has adopted it or because their next role requires it.
This audience has specific constraints. They do not have unlimited time to spend on tutorial paths. They already have strong programming intuitions and they want feedback that respects those intuitions rather than starting from zero. They learn faster when feedback connects to what they already know: "here is how Go's error model differs from Python's exception model and why that difference matters" is more useful to them than a general introduction to error handling.
The product targets the six-week window. Based on what we built toward and what we observed in early use, a developer who submits real PRs with regular feedback can get from "knows the syntax" to "writes idiomatic code that passes review without concept-level comments" in roughly six weeks of consistent work. That is not a guarantee and it depends heavily on how much code they write. But it is the timeframe we design for.
What the first version includes
When we launched in mid-2025, HackQuest supported Go, TypeScript, and Python as the primary graded stacks. Those three represented the most common switching patterns we had seen: Python developers moving to Go, JavaScript developers moving to TypeScript, and full-stack developers adding Python. We have expanded since then and currently support 15 stacks, with more in development.
The core workflow is straightforward: connect a GitHub repo, open a PR against your learning branch, and receive graded feedback within two hours on the Pro plan. The feedback is line-level, concept-attributed, and connected to a lesson that addresses the gap. The lesson queue adapts after every PR.
There is a free tier with three PR reviews per month. This is enough to get a real sense of how the product works and what it surfaces. For developers who are seriously trying to complete a stack switch on a timeline, the Pro plan with unlimited reviews is what makes sense.
What we are still figuring out
We want to be direct about where we are and what is still being worked out. The concept graph that maps PR errors to lessons is built from our understanding of the most common learning patterns. It covers the most frequent gaps well. The edge cases are harder: unusual error patterns, niche library usage, code that is unusual but correct. We have seen cases where our grading flagged something as a concept gap that was actually a deliberate stylistic choice by an experienced developer. We are working on improving the confidence signaling so that feedback is clearly marked when we are less certain.
The adaptive sequencing is also an ongoing problem. The dependency model we use to order lessons works for the core concepts but is imperfect at the edges. We have found cases where lessons were sequenced in an order that was logically consistent but practically awkward, where a developer needed a concept from lesson seven to fully understand lesson four. We are iterating on the dependency graph based on what we observe in user paths.
We are a small team. That means we can ship fast and that we read every piece of feedback that comes in. It also means our support surface is limited and some things move slower than we would like. If you run into something that does not work well, the best path is [email protected]. We respond.
The bet we are making
The bet behind HackQuest is that the most efficient way to learn a new programming stack is to write real code and get specific feedback on it, as fast as possible. Documentation is necessary but not sufficient. Toy exercises build syntax familiarity but not production intuition. Human code review is the best feedback source but is constrained by availability and varies in how thoroughly it explains underlying concepts.
Automated PR grading at the concept level is not a replacement for any of these. It is a way to make the feedback loop fast and consistent enough that a developer can iterate on their mental model week over week rather than month over month. We think the timeframe difference matters. Six weeks of consistent feedback versus six months of occasional human review is a different experience for someone trying to become productive on a new stack.
If you are making a stack switch and you want feedback that connects to your actual code rather than a prescribed curriculum, start with the free tier and see what it surfaces. The first graded PR is usually the most useful one.