Mytrix — Devpost Story

Inspiration

Every developer has lived this moment: you join a project, or return to one after weeks away, and the code is right there — but the why isn't. Why does this service exist? Why was authentication rebuilt twice? What's actually risky to touch? That knowledge doesn't live in the code. It lives in people's heads, in Slack threads, in memories that fade.

Existing AI coding tools can tell you what a function does. Almost none of them can tell you why a repository is shaped the way it is — and the ones that try often just generate plausible-sounding prose that isn't actually tied to anything real in the codebase. We wanted to build something that earns trust the hard way: by proving every claim it makes, not just asserting it confidently.

What it does

Mytrix reconstructs a repository's memory in two distinct layers, on purpose:

Layer 1 — deterministic, zero AI. Given a public GitHub URL, Mytrix clones the repo and runs a pure static-analysis parser: detected languages, frameworks, package manager, build tools, dependencies (production and dev, separately), entry points, config files, environment variable names, Docker/CI presence, and full project structure. No model involved — just real inspection of real files.

Layer 2 — GPT-5.6, constrained hard. That structured data is handed to GPT-5.6 with one non-negotiable rule: every claim in the generated purpose, architecture summary, strengths, and risks must name a specific, real item from the parsed data — a file path, a dependency, a framework, a phrase from the README. If it can't tie a claim to real evidence, it's instructed to leave the claim out entirely rather than write something generic.

On top of that: an interactive knowledge graph built from the same parsed data (not a separate, disconnected feature), and an AI Mentor that answers repository-specific questions using only that same grounded context.

How we built it

We built this end-to-end with Codex across the full week — not just for scaffolding, but for real, iterative engineering:

• The entire Repository Intelligence Engine — detectLanguages, detectFramework, detectDependencies, detectEntrypoints, detectEnvironment, and more — was built with Codex from a precise specification: a single shared file-walk (not one per detector, to avoid redundant scans on large repos) and a strict output schema per detector.
• The Express backend — controllers, routes, and an atomic-write JSON storage layer (temp-file-then-rename, so a crash mid-write can't corrupt saved analysis) — and most of the React frontend, including the analysis flow, dashboard, and knowledge graph visualization.
• Real production bugs, diagnosed and fixed with Codex, not just written once and left:
  • An AI response schema that silently dropped evidence citations entirely — traced back to the prompt template and fixed with an explicit grounding rule plus contrastive good/bad examples in the prompt itself.
  • A hardcoded Groq model name (llama-3.3-70b-versatile) being sent to the real OpenAI API after we added a genuine GPT-5.6 key — a provider-selection bug that would have silently broken the Mentor feature in production if we hadn't caught it via the actual error logs.
  • A SyntaxError: Unexpected token 'export' that turned out to be a function accidentally declared inside another function's body — found by reading the file line-by-line rather than guessing from the error message alone.
  • A missing GET /api/projects route causing Saved Projects to silently fail and always show empty — traced through the frontend service call, to the route file, to a storage function that didn't exist yet.
  • A CSS/Tailwind mismatch where several components used Tailwind utility classes in a project that never actually had Tailwind's build pipeline wired in — converted those components to plain CSS rather than risk destabilizing a working build days before deadline by retrofitting a new toolchain.

Every fix was scoped precisely to the actual bug, verified against real console/terminal output, not assumed fixed.

Grounding, proven — not just claimed

The clearest evidence this actually works came from the Mentor itself, live, unscripted. Asked a question the parsed context couldn't fully verify, it answered:

"...the supplied context does not provide enough implementation detail to confirm how every described feature is built."

That's the model correctly declining to guess instead of hallucinating a confident answer — the exact behavior the whole architecture exists to produce.

Challenges we ran into

Keeping AI output honest was harder than making it sound good. Early versions passed valid JSON but wrote fluent, plausible, completely generic filler ("utilizes a popular and well-maintained tech stack") — technically working, substantively useless. Fixing this took rewriting the prompt with explicit contrastive examples and a hard instruction to omit ungrounded claims rather than soften them.

We also cut real scope under time pressure: a live AI chat interface and a full authentication system were both removed once it was clear they'd risk destabilizing a working demo. The Mentor became a grounded, cited FAQ instead of open-ended chat — deliberately, to keep every answer traceable to real evidence rather than free-generated text.

Accomplishments we're proud of

A working, deployed, click-through product — landing page to analysis to dashboard to knowledge graph to mentor — where every AI-generated claim about a real repository can be traced back to something real in that repository. Not described as trustworthy. Demonstrably trustworthy, on camera, unscripted.

What's next

The parsing layer is already fully decoupled from the UI — the same Knowledge Object that powers the dashboard today could power a Codex tool call tomorrow. The natural next step is packaging Mytrix's grounded analysis as a Codex plugin, so a developer gets a grounded project briefing inside their existing agentic workflow, not a separate dashboard to context-switch into.

Built With

• ai
• codex
• express.js
• llm
• mongodb
• node.js
• openai
• react-native