RAG vs fine-tuning for your codebase¶

Every enterprise AI guide has the same section: retrieval-augmented generation (RAG) versus fine-tuning, with a decision tree at the end. Buyers evaluating CodeNavi ask two versions of the question. Which side is CodeNavi on? And should we fine-tune a model on our codebase instead? This page runs the standard decision tree on a codebase — not on a knowledge base of PDFs — and says what CodeNavi does on each side of it.

The short version¶

CodeNavi is retrieval for the coding agent you already use, with the retriever fine-tuned. The model that writes code — Claude, Codex, or a local model — is never trained on your code. It reads it, fresh, per question, with a file:line reference on every result. The one model CodeNavi did fine-tune is the embedder, Buric-E4B: once, by CodeNavi, on code retrieval, before shipping. Your code is embedded, never trained on.

Applied to a codebase, the guides' own decision tree lands on retrieval at every step:

The guides ask	For a codebase	Which way it points
Does the information change often?	On every commit	Retrieval. A fine-tuned snapshot is wrong by the next merge; a CodeNavi reindex is incremental and takes seconds
Must answers be traceable?	Yes — an agent has to open the file it is about to edit	Retrieval. Every result carries `file:line`; a weight cannot be opened
Is the goal tone, format or behaviour?	No — the questions are "where is this, what calls it, what breaks"	Not what fine-tuning is for
Is labelled training data available at scale?	Almost never — nobody has thousands of question → code location pairs for their own repo	Fine-tuning is not viable
Can you fine-tune the model at all?	Not the frontier models behind Claude Code or Codex CLI	Retrieval is the only way to give them your code
Domain expertise and current facts?	Yes	Hybrid — the section below

Why a model fine-tuned on your repo is not an agent's memory¶

The guides list code generation as a strong fine-tuning case, and for house style they are right (see below). As a substitute for retrieval — "the model just knows our codebase" — it fails on four counts:

It is stale on day one. Training captures a snapshot. The branch moves the same afternoon. Every merge widens the gap until the next training run, which costs GPU hours and an ML engineer. A reindex costs seconds and nobody.
It invents. A model that has memorised a codebase produces plausible function names, parameters and file paths that do not exist — with full confidence, because nothing in the weights says "I do not have this". Retrieval returns real chunks or nothing, and says when the match is weak.
It cannot cite. An agent needs the path and line to read, edit and test. A fine-tuned answer is a paraphrase of the training set; the agent still has to go and find the file.
It cannot forget. Once code is in the weights it is there for every user of that model, with no access control and no way to remove a file that should never have been included. The guides make this governance point themselves: a retrieval layer can be restricted or revoked; a trained model cannot. CodeNavi goes one step further and redacts secrets and PII at index time, so the agent never sees them at all.

And one count the guides do not list, because they assume a cloud platform: fine-tuning on private code means uploading private code — to a training service, or to a training rig you build and secure yourself. For client work under NDA, regulated code, or an air-gapped network, that constraint decides the question before the decision tree starts. It is also why CodeNavi exists.

Where fine-tuning belongs: the retriever¶

The guides recommend a hybrid — fine-tune for domain understanding, retrieve for currency. CodeNavi applies exactly that split, one level down:

The part that has to understand code is trained. Buric-E4B is a 4-billion-parameter embedder fine-tuned on code retrieval. Wiring a generic embedder API into the same pipeline measured about 30 points worse (search quality). A cross-encoder reranker re-reads every candidate against the query.
The part that has to be current is retrieved. AST-chunked, incrementally reindexed, scanned for secrets and injection before an agent can read it. The call graph behind find_callers and impact_analysis is recomputed from the source, not learned — see which RAG architecture is CodeNavi?.
The training happened once, at CodeNavi. The same model bytes ship in every release, connected or air-gapped. Nothing trains on your data, nothing phones home, and there is no per-customer model to manage.

That is the whole answer to "which side": fine-tuned retriever, retrieved code, untouched generator.

Where fine-tuning a generator is still the right call¶

Say it before the prospect does:

House style for generated code. A model fine-tuned on your conventions writes code that looks like yours without a style guide in every prompt. CodeNavi does not do this and does not try to. It pairs with such a model: the fine-tuned model writes; CodeNavi tells it where things are today.
Inline completion. Latency-critical, high-volume, no room for a retrieval hop. CodeNavi does not autocomplete — see the comparison page.
A stable, closed domain. Where the knowledge really does not move — a fixed protocol, a frozen legacy system nobody edits — the fine-tuning case is stronger. Most codebases are not that.

In all three, the fine-tuned model still needs to know what the code looks like today. That is the hybrid, and retrieval is the half that keeps it honest.

The usual objections to retrieval, answered for this product¶

The guides' "disadvantages of RAG" are real. Here is what each one costs in CodeNavi:

Objection	Here
Retrieval adds latency	A query takes a second or two (vector search plus reranking). For a known literal the agent rules say use `grep`. Retrieval pays off on the questions grep cannot answer
Ongoing infrastructure	One container, one GPU, one install command, one update command. How much work is it? has the real commands
Quality depends on the retriever	Yes — that dependence is the product. The numbers are measured and published, misses included, and re-measured by a regression harness on every change
Chunking and embedding are hard to get right	Done for you: AST boundaries across 15 languages, a code-specialised embedder, no knobs to tune

Judge it on your own code¶

The guides end with "pilot both and measure". Do that. Index your repo, ask your ten hardest "where is…" questions, and compare against what any model could have memorised last quarter. The trial exists for exactly that.