Every hackathon has the same 90-second moment of dread: someone hands you a codebase you've never seen, and you have to make sense of it before the clock runs out.
File trees don't help. doesn't help.
You waste the first 30–60 minutes reading the wrong files, missing a hidden dependency, and stepping straight into a production trap nobody warned you about.
In other words: before writing code, you spend half your time trying to figure out where the hell the code is.
The idea wasn't "AI that writes your code." It was "AI that tells you where to look before you write it." For InnovaHack Chapter-1, my team built Waypoint — a dev onboarding platform.
Point it at any GitHub repo or a local folder, describe a task like "Add a new global configuration flag to app.set()", and instead of you reading the whole codebase to figure out where that even goes, it hands you a Mission Brief: exactly which files you'll touch, the traps waiting in them, what to learn first, and the order to do it in.
Waypoint made the Top 50 — one of the 50 chosen to advance to Round
2.
Here's how it actually works under the hood, what it took to build, what's next for it — and since I don't believe in only posting the highlight reel, what happened after we placed that made us walk away from the next round.
The problem: the cold-start tax Every time a developer joins a new codebase, or picks up an unfamiliar task in one they already know, there's a tax paid in wrong files read, missed dependencies, and traps hit blind.
For me, that moment came when I wanted to contribute to Forem — the open-source project that actually powers DEV.
I didn't know a line of Ruby on Rails, and between learning the language, understanding the framework, and preparing for interviews, I didn't have the time to read an entire unfamiliar codebase just to figure out where one feature belonged.
I never ended up making that contribution.
But the problem stuck with me.
It's also a pattern for our team more broadly: we deliberately pick a different domain of tech for every hackathon instead of getting comfortable in one stack.
It's less strategic than it sounds — mostly it just means Tarkash-Labs has ended up with a fairly scattered, fairly interesting portfolio of projects across domains that have nothing to do with each other.
A file tree tells you where things are.
It tells you nothing about what matters for the thing you're trying to do right now.
That's the actual gap Waypoint closes — not "here's a map of the codebase," but "here's the route for your specific task." It's a map, not a GPS.
Waypoint is supposed to give you the latter.
How a task becomes a Mission Brief Type in a task — the README's own example is — and Waypoint runs a five-step pipeline: Keyword match — scans every file for relevance by path and content pattern Semantic retrieval — uses NVIDIA's NV-EmbedCode-7B embeddings to pull the top 15 semantically similar files via cosine similarity AI candidate selection — an LLM narrows that down to the 3-5 files that actually matter Source extraction — structurally parses the real code: functions, classes, imports, exports Mission generation — produces the brief itself: files to touch (with reasons), known traps, prerequisites, a step-by-step route, and an evidence log of what was analyzed and why Five steps in.
One question answered: “Where should I actually start?” That evidence log matters more than it sounds like it should — it's the difference between "trust me" and being able to see exactly which files the recommendation is grounded in.
The goal isn't to make the AI sound confident.
The goal is to make it show its homework.
Screenshot 1 — the input/task The task starts with a question, not a file path: tell Waypoint what you're trying to change.
Screenshot 2 — the analysis Waypoint narrows an entire repository down to the files relevant to that task.
Screenshot 3 — the Mission Brief The output isn't a generic codebase summary — it's a task-specific route with files, traps, pr