Mikk — I built a codebase graph for AI tools, would love honest feedback

[Ansh-dhanani]

Hey everyone,

I've been working on Mikk for a while and I think it's reached a point where real feedback would be more valuable than more solo iteration.

What it does:
Mikk parses your TypeScript or Go codebase using the actual compiler (TypeScript Compiler API, not regex), builds a full dependency graph, and exposes it to AI tools like Claude, Cursor, and Copilot via an MCP server. The idea is that before your AI edits a file, it knows what functions already exist there, what architectural constraints apply, and what else will break if it makes the wrong change.

The core output is mikk.lock.json — every function, every call edge, every import relationship in one structured file — plus a claude.md that any AI can read without MCP.

What's working:

• Full TypeScript and Go AST parsing with exact file + line numbers
• 12 MCP tools including mikk_before_edit (calls before any file edit, returns existing functions + constraints + blast radius)
• Semantic search using local embeddings — no API key needed
• mikk mcp install auto-configures Claude Desktop, Cursor, VS Code
• Architectural constraints you can define and enforce in CI

What I'm genuinely unsure about:

• Is the MCP tool surface the right abstraction, or would you rather interact with this differently?
• The lock file on large codebases can get big — I'm actively working on this but curious what size feels acceptable to you
• Is the constraint/contract system (defining module boundaries in mikk.json) something you'd actually use, or does it feel like overhead?
• What's missing that would make this part of your daily workflow?

I'm not looking for encouragement — I want to know what's wrong, what's confusing, and what you'd never use. If you try it and it breaks on your project, that's exactly the feedback I need.

npm install -g @getmikk/cli
cd your-project
mikk init

Repo: https://github.com/Ansh-dhanani/mikk

Thanks in advance — even a "tried it, here's where it broke" is genuinely useful.

[Nyrok]

The mikk_before_edit hook is a smart way to prevent the AI from making changes with unexpected blast radius. Solves the "AI doesn't know what it's breaking" problem at runtime.

The adjacent issue I've run into: even with rich codebase context, the prompt driving the edit can undercut it. If someone sends "refactor this function to be async", there's no constraints block telling the AI to preserve the call signatures that mikk.lock.json tracks. The model optimizes for the literal task and ignores the broader context it was given.

I've been building flompt to address this at the prompt level: decompose tasks into typed blocks (objective, constraints, output_format) so constraints are explicit before the AI acts. Works well alongside tools like Mikk that provide the runtime context. Open-source: github.com/Nyrok/flompt

[Ansh-dhanani]

Good point. I think Flompt works really well in situations where you're dealing with one-off prompts and building the context from scratch each time.

With a persistent MCP system like Mikk, though, most of what would normally go into a constraints block is already automatically injected before every edit things like module boundaries, blast radius, existing function signatures, etc. So the AI already has that information without needing to restate it each time.

In that sense, Mikk is trying to solve a similar problem but at a slightly deeper level not by structuring the prompt better, but by keeping the context persistent and always up to date.