DEV Community

Cover image for Your Codebase Doesn't Need AI. It Needs Context.
Dhruv Jani
Dhruv Jani Subscriber

Posted on

Your Codebase Doesn't Need AI. It Needs Context.

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. grep 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 Add Google OAuth — and Waypoint runs a five-step pipeline:

  1. Keyword match — scans every file for relevance by path and content pattern
  2. Semantic retrieval — uses NVIDIA's NV-EmbedCode-7B embeddings to pull the top 15 semantically similar files via cosine similarity
  3. AI candidate selection — an LLM narrows that down to the 3-5 files that actually matter
  4. Source extraction — structurally parses the real code: functions, classes, imports, exports
  5. 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.

Mission-Brief Feature-1

Screenshot 2 — the analysis

Waypoint narrows an entire repository down to the files relevant to that task.

Mission-Brief Feature-2

Screenshot 3 — the Mission Brief

The output isn't a generic codebase summary — it's a task-specific route with files, traps, prerequisites, and evidence.

Mission-Brief Feature-3

Caption: The Mission Brief generated for adding a new configuration flag to Express.js — identifying the exact core files to touch, known framework traps, and the step-by-step route.

Never showing a blank screen: the AI router

One decision I'm genuinely proud of: Waypoint doesn't depend on a single AI provider staying up. It runs a waterfall — because apparently even AI needs a backup plan:

Primary → Fallback → Second fallback

  • Gemini 3.5 Flash for speed
  • DeepSeek V4 Flash via NVIDIA NIM for reasoning depth if Gemini rate-limits or times out
  • Gemma 4 31B via NVIDIA NIM — lighter, but it means there's always a third option before the app just fails

This isn't a hypothetical safety net. Gemini's free tier caps out at 20 requests a day, per model — fine for a polished five-minute demo, nowhere near enough for the number of test runs building and debugging actually takes. NVIDIA NIM's limits run per-minute instead of per-day, which is exactly why DeepSeek V4 Flash sits as the first fallback rather than the primary. Gemma 4 31B is the heaviest of the three — noticeably slower, but consistently the most thorough of the three, which is why it's the option of last resort rather than a weak one. Three providers, one mission: don't let the app go down because a free tier decided you'd had enough requests for the day.

The two 3D views

Beyond the Mission Brief, Waypoint has two ways to actually see the codebase:

  • Architecture Map — the 3D city. Buildings are files, height is lines of code, color is risk level. The taller the building, the more code you're probably about to regret touching.
  • Dependency Galaxy — a 3D force-directed graph showing how every file actually connects to every other file. Architecture Map tells you what the city looks like. Dependency Galaxy tells you who's secretly connected to whom.

Architecture Map
Architecture Map: the Express.js codebase rendered as a 3D city — building height represents lines of code, while color represents risk.

Dependency Galaxy
Dependency Galaxy: the same repository viewed as a network of file-to-file dependencies.

And then the entire thing white-screened.

Here's the one that actually made me sweat. Building the Architecture Map meant procedurally laying out a 3D cityscape — each file a building, grouped by directory — and for the floor plan we used d3-hierarchy's treemapSquarify layout, extruding the resulting 2D rectangles into 3D boxes with React Three Fiber.

It worked cleanly on most repos. Then, with no warning, loading a specific repo would white-screen the entire app — no error message, no fallback, the whole navigation state just gone.

The cause turned out to be a collision between D3's layout math and WebGL's geometry constraints. On repos with certain nested structures, or too few files, D3's padding calculations would subtract more space than the bounding box actually had — and the treemap would hand back leaf nodes with a width or depth of exactly zero, sometimes negative. Feed a negative dimension into a Three.js <BoxGeometry> and WebGL throws a fatal NaN vertex error. Because the 3D canvas lived inside the main React tree, that error bubbled straight up and unmounted the entire app.

A single negative pixel in a street calculation nuked the whole dashboard.

Fixing it took three layers: scaling the D3 canvas dynamically based on repo density instead of a fixed-size grid, clamping geometry on the Three.js side with a hard minimum size and a capped maximum height so nothing could ever go negative or infinite, and wrapping the whole 3D map in a React ErrorBoundary so a geometry failure degrades gracefully to a "Map unavailable" panel instead of taking the rest of the app down with it.

Turns out making a codebase look like a city is considerably easier than making the city behave like one.

For the curious: Waypoint doesn't need a GitHub repo Waypoint can analyze a local folder directly through the browser's File System Access API — no GitHub repo required, and no code leaves your machine until the AI analysis step. This wasn't an accident: during any hackathon, we try hard not to introduce a persistent database or auth if we can avoid it. It's better for privacy, and just as importantly, it means judges can try the tool immediately instead of creating an account first — which saves everyone time during judging.

What "Top 50" actually meant

There were 8,666 registered teams across the hackathon, but the number of teams competing in our Open Innovation track isn't something I know. So I'm not going to manufacture a denominator. Waypoint was simply one of the 50 teams selected to advance to Round 2.

Top 50 gave us a waypoint, not a finish line.

GitHub logo Tarkash-Labs / WayPoint

Waypoint prepares developers before they code. Paste any GitHub repository, describe your task, and instantly get the files that matter, known risks, learning prerequisites, and an execution route—turning hours of code exploration into minutes of focused development.

Waypoint Logo

🧭 Waypoint

The Context Engine That Prepares Developers Before They Write a Single Line of Code

Waypoint is an AI-powered developer productivity tool that analyzes any GitHub repository or local project and generates task-specific Mission Briefs — telling you exactly which files to touch, what traps to avoid, and the optimal execution route, before you start coding


🎯 Problem Statement

When a developer joins a new codebase or picks up an unfamiliar task, they waste 30–60 minutes reading the wrong files, missing hidden dependencies, and hitting production traps. Waypoint eliminates this cold-start problem entirely.

💡 Solution

Waypoint uses a Retrieval-Augmented Generation (RAG) pipeline with semantic embeddings to deeply understand a codebase and then generates:


















Feature What It Does
🎯 Mission Brief Files you'll touch, known traps, prerequisites, and a step-by-step execution route for your specific task
🎓 AI Onboarding Role-based learning paths (Frontend, Backend, Bug Fixes, Architecture) with contextual





The part I want to be honest about

Placing Top 50 wasn't the end of the story — it was supposed to be the start of Phase 2. And this is the part most "we won a hackathon!" posts leave out, so I'm not going to.

Instead, Phase 2 taught us something we didn't expect to learn at a hackathon: sometimes the thing you need to debug isn't your code.

Here's what happened, as plainly as I can lay it out:

  • Phase 2 required a real fee to continue.
  • The ₹1,000 fee was presented as a pay-to-continue cost, justified by a claimed ₹45,000+ package of credits, swag, and mentorship.
  • A chunk of those credits were for things like n8n and .xyz domains — already free or near-free for students and first-time users through those companies' own existing programs.
  • This was a national-level hackathon, and Round 2 was in-person in Mumbai, meaning travel out of state for teams like ours.
  • No accommodation was provided, for a round that lasted a matter of hours.
  • When people in the group chat asked basic accountability questions — what the fee actually covered, how the ₹45,000+ figure was calculated, whether travel support was possible — the chat was muted instead of answered.

For us, that wasn't worth paying to continue. Not because Waypoint wasn't worth continuing — a Top 50 finish says otherwise — but because the claimed value didn't add up to something we felt justified paying ₹1,000 for.

If you're deep in hackathon season this year: paying to continue is one decision. An organizer who won't stay answerable for what that payment covers is a completely different, much simpler decision. Walk, regardless of how far you've already placed.

What's next

For now, Waypoint is paused — not abandoned. We know where we want to take it next: tighter retrieval, a real backend proxy so it's not stuck behind a dev-only CORS workaround, private repo support. Realistically, it's waiting on our next funding round, which comes in one of two forms: actual seed funding, or my co-founders finishing their job hunts and having bandwidth again. Whichever hits first, we're calling it Series F — for Friends.

Right now we've got Waypoint's idea and questionnaire submitted to Eureka! — E-Cell IIT Bombay's startup competition — under the AI & Deeptech track. No idea yet how far it goes, but it felt like the right next room to walk into.

Sometimes the most useful waypoint is the one that tells you not to keep going.

Have you ever walked away from an opportunity even after earning your way into it? I'd genuinely like to hear what happened.


Transparency note: the AI pipeline behind these screenshots

(Dev Note:* For the demo screenshots in this post, we ran Waypoint against the Express.js repository to show a realistic architectural task. Also, a quick transparency note on the AI pipeline: as of August 24, 2026, NVIDIA NIM officially deprecated the nv-embedcode-7b-v1 embedding model and sunset the free-tier API endpoint for deepseek-v4-flash. Because this triggered a cascading 410 Gone error across our semantic search and LLM fallback router, the screenshots above were generated locally by temporarily bypassing NIM and routing the entire pipeline through Gemini 3.5 Flash as a hotfix. We'll be migrating to NVIDIA's newer embedding models and a partner-hosted DeepSeek instance for production before our Eureka pitch.)*

Top comments (1)

Collapse
 
dj29 profile image
Dhruv Jani

Okay, now I genuinely want to know — how do YOU enter a codebase you've never seen before?😂

File tree? grep? Docs? AI? Asking the senior dev? Randomly opening files until something starts making sense? 💀

Because that first 30 minutes of “where the hell am I supposed to start?” is exactly why we built Waypoint.

What's your usual approach?