Onboard new joiners faster.

The true cost of onboarding isn't the paperwork or the laptop setup. It's the three weeks it takes a new engineer to build a mental model of the codebase, and the three weeks of everyone else's time it drains while they do it.

It starts as they join. The new hire opens the repo, stares at 40 directories, and starts asking questions. Good questions, actually. What owns the auth flow? Where does this API call go? Why does the billing module import from user-core? The answers are all there, but they live in crazy Confluence documents or inside the head of whoever's been here longest. So the new hire books time with that person. Then more time. Then more.

This is expensive in two directions at once: the new hire is slow, and your senior engineers are interrupted.

Enola fixes the second half of that equation. It gives your new joiner a structural map of the codebase they can ask themselves, before they touch a single file, and without pulling anyone away from what they were doing.

What enola actually does

Enola is a local MCP server that parses your repositories and builds a deterministic graph of what's in them: modules, symbols, routes, database tables, imports, call edges, and the relationships between them. Every fact in that graph is deterministic — not from an LLM guessing at the structure, not from documentation that may or may not be current. Run it on the same commit twice, you get the same graph.

On top of that graph, it exposes tools your AI coding agent (Claude Code, Cursor, Copilot, Opencode — anything MCP-compatible) can use to answer questions with exact answers.

The install is a single command:

curl -fsSL https://raw.githubusercontent.com/enola-labs/enola/main/install.sh | sh

Add it to your MCP client config:

{
  "mcpServers": {
    "enola": {
      "command": "enola"
    }
  }
}

Then point it at the repo:

That's the whole setup. The snapshot takes seconds even on large codebases.

The questions every new joiner asks

Here's what a new engineer actually needs to know in their first week. Not "how do I set up the dev environment" — that's in the README. The harder stuff: how does this thing actually work, and where do I start?

"Give me the overview — what is going on here?"

Enola answers this from the llm_context.md it generated — a compact, token-budgeted architecture summary that includes the detected architectural pattern, the most critical modules by dependency weight, entry points, and routes. The new hire gets structured guidance instead of a directory listing and a prayer.

"I need to build a feature. Where do I start?"

This is usually a 45-minute conversation with a senior engineer. With Enola, the agent can traverse the dependency graph from existing route handlers, identify the relevant modules, and give a concrete answer: touch these packages, in this order, because this is how the existing endpoints are structured.

"What are the landmines?"

Enola runs Tarjan's algorithm on the import graph and pattern-matches the directory structure against known architectural shapes (hexagonal, Go-standard, Next.js). If there are cycles or layer violations, they surface immediately — with every module in the cycle listed as evidence. A new hire doesn't need to know what Tarjan's algorithm is. They just need to know don't import from this package inside that layer.

"What does this module actually do?"

explore returns a markdown summary: all the symbols with kinds and line numbers, direct dependencies, and everything that depends on the module in reverse. A new hire can build a precise mental model of a module in the time it takes to read a paragraph.

What this looks like in practice

Say you're onboarding someone onto a Go backend with a Next.js frontend and a separate auth service — three repos, none of them small. Under the old model, they'd spend a week just figuring out where the auth boundary is.

With Enola, the process looks like this:

"Generate an architectural snapshot of /repos/backend"
"Generate a snapshot of /repos/frontend with append mode"
"Generate a snapshot of /repos/auth-service with append mode"

Three commands. Enola builds a cross-repo graph, links the HTTP routes between services, and surfaces the dependency edges between them. Now the new hire can ask:

And get back the exact call chain: the Next.js route component, the API client call, the backend endpoint that receives it, the auth service method it delegates to. Not a diagram someone drew once and never updated. The actual path, extracted from the actual code.

What you still need to do

Enola isn't a replacement for a good README, a thoughtful architectural decision record, or a first-week pairing session with a senior engineer. It doesn't know why decisions were made and when, but it knows what decisions exist in the code right now.

What it eliminates is the structural exploration. The "which module owns this?", "what imports from where?", "what breaks if I touch this?" questions that used to require a 30-minute Slack thread.

Your senior engineers still matter enormously. Enola just means new hires arrive at the hard, high-value questions faster, instead of spending their first week on the ones a graph could answer in a second.

Get started

Point it at your repo. Then hand your next new hire these prompts and get out of the way:

1. "Give me a tour of the main modules, how they relate, and where to start reading."
2. "I need to add [feature X]. Which packages should I touch, and in what order?"
3. "Are there any cyclic dependencies or layer violations I should know about?"
4. "What would break if I change [module Y]?"

Those four questions used to cost four meetings. Now they cost four seconds.

FAQ

How can I onboard new engineers faster?

The fastest way to onboard a new engineer is to give them a queryable map of the codebase instead of relying on senior engineers to answer structural questions one at a time. Tools like enola generate this map automatically by parsing the actual code, so new hires can ask questions like "what does this module depend on?" and get an exact answer in seconds.

What is a codebase knowledge graph?

A codebase knowledge graph is a structured representation of a codebase's modules, symbols, routes, database tables, and the relationships between them — built by parsing the code rather than guessing from documentation. It lets both humans and AI agents query the actual structure of a project instead of re-deriving it from scratch each time.

How long does it take a new engineer to learn a codebase?

This varies by codebase size and team support, but it commonly takes one to three weeks for a new engineer to build a working mental model of a mid-sized codebase, much of which is spent interrupting senior engineers with structural questions. Tools that expose the dependency graph directly can compress this significantly by answering those questions on demand.

Does enola send my code anywhere?

No. enola runs entirely locally as an MCP server. The graph it builds stays on your machine; no source code is sent to an external service.

curl -fsSL https://raw.githubusercontent.com/enola-labs/enola/main/install.sh | sh