Disclosure: The project implementation and engineering decisions described here are my own. I used AI assistance to edit and restructure portions of this article.
We’ve all seen it: an AI assistant gives a confident answer about a codebase, but the suggestion doesn’t fit the project. It may miss a dependency, overlook a convention, or propose a change that makes sense in isolation but not in the system where it needs to live.
The problem isn’t always the model. Sometimes it simply doesn’t have the right context.
I think about it like a volleyball team. A player can have an excellent serve and a powerful spike, but individual skill isn’t enough. They need to understand the formation, read their teammates, and adjust to the play already in motion. A coding assistant needs a similar awareness of the project it has joined.
That idea led me to build Jambavan, an experimental, local-first AI coding assistant inside VS Code. It connects to an Ollama model, gathers selected repository context, creates project notes, remembers developer feedback, and proposes code changes for review. It is not an autonomous coding system, and I want to be clear about that distinction.
The name Jambavan comes from the Ramayana. Jambavan is the wise King of the Bears who guides Rama in his search for Sita. I liked the idea of an assistant that helps a developer understand a problem and make a better decision without taking control away from them.
I built the extension with TypeScript and the VS Code Extension API. The chat interface lives in an Activity Bar webview, but the webview does not read workspace files directly. It sends messages to the extension host, which gathers context, calls the configured Ollama endpoint, and returns the answer to the UI.
The basic flow is:
VS Code chat → extension host → bounded workspace context → Ollama /api/chat → answer and context list
That separation matters. The extension host is responsible for deciding what information to include; the model doesn’t get unrestricted access to the repository just because I asked it a question.
The model name and Ollama URL are configurable. The defaults are qwen3.5:9b and http://localhost:11434. The key engineering question turned out not to be how to connect a chat window to a model. It was how to choose the information the model should see—and how to handle what it returns.
Sending an entire repository with every prompt is wasteful and can bury the useful details in unrelated material. Jambavan assembles a limited context based on the request. In the chat flow, that can include up to 15 repository paths, up to 800 characters of project guidance, up to 1,800 characters from the active file, up to two selected files with 900 characters each, repository notes, and a limited amount of recent conversation.
Those numbers are implementation limits, not a claim that this is the ideal context size for every project. I chose them to keep the request focused and predictable while I learn what information helps most.
I also show a collapsible list of the context items supplied with each answer. That small UI detail has been useful for debugging. If the answer is wrong, I can ask: Did Jambavan include the relevant file? Was project guidance missing? Did it only send an excerpt that left out an important function?
The list shows what went into the request; it cannot prove which parts the model relied on internally. Still, the visibility makes the system easier to investigate than a chat box that hides its inputs.
I wanted Jambavan to retain a map of the codebase so I wouldn’t need to explain the project from scratch in every conversation. Its scanner examines supported source, text, configuration, and documentation files. It skips common generated and dependency directories, ignores files above its size limit, and caps the repository inventory at 1,000 files.
For each eligible file, it calculates a SHA-256 hash. If the hash matches the version already in the index, the scanner skips the summarization request. If the file changed, Jambavan sends a bounded excerpt to Ollama and asks for a short summary. The summarization prompt tells the model to treat repository text as untrusted data, summarize only what the source supports, identify the file path, and avoid inventing behavior. That is a useful boundary, though it is not a substitute for verifying the source.
The core decision is small. This excerpt is from the current implementation in repoKnowledge.ts:
const sha256 = createHash("sha256").update(bytes).digest("hex");if (index[candidate.path]?.sha256 === sha256) { unchanged += 1; continue;}
The hash doesn’t tell Jambavan what the code means. It simply tells the scanner whether the file has changed, so unchanged files don’t need to be summarized again.
The scanner also has explicit processing limits. It considers up to 1,000 eligible repository files, skips files larger than 100 KB, and sends a maximum of 6,000 characters from each changed file to Ollama. Each generated summary is capped at 900 characters, and changed files are processed in batches of up to 20.
After each summary is completed, Jambavan saves its hash and summary and regenerates the readable notes. A successful scan can continue through additional batches while changed files remain. If a scan is cancelled, summaries already saved are retained.
Jambavan writes the results to two locations:
The notes are a navigation aid, not a source of truth. A summary can be incomplete or wrong, so I still need to check the original file before acting on a recommendation.
Repository notes capture information about the codebase, but they don’t capture every preference that emerges while working with an assistant. I added local conversation history and three feedback actions: Helpful, Not helpful, and Remember.
Chat history and saved choices live in VS Code extension storage, separately from the repository notes. When I ask a new question, Jambavan uses keyword overlap to select a small number of relevant saved choices and can include them in the prompt.
The current memory store can retain up to 100 chat messages and 100 saved feedback choices for a workspace. When I ask a new question, Jambavan ranks saved choices using keyword overlap and selects up to five matches, with the combined text capped at 2,500 characters.
This is intentionally simple. It isn’t semantic search, a vector database, or model training. It doesn’t change Qwen’s weights. If I describe the same idea using different words, keyword matching may fail to retrieve a relevant preference. Making memory inspectable, editable, and easier to clear is still on my roadmap.
For now, the point is to preserve selected context between interactions without claiming the model has learned in the machine-learning sense.
Explanations are relatively easy to discard. A source-code change can quietly break something. I didn’t want Jambavan to overwrite a file as soon as the model returned text, so I built an edit workflow around review.
When I enter /edit followed by a request, Jambavan reads the active file along with bounded project guidance and repository notes. For supported, smaller files, it asks the model for a complete replacement, validates the response, and opens a VS Code diff. The original file remains unchanged until I choose to apply the proposal. If I apply it, the editor buffer changes; I still review and save it myself.
The extension also checks whether the active file changed while the model was generating the proposal. It rejects empty or suspiciously shortened outputs rather than treating every response as valid code. The current full-file workflow is limited to files of 7,000 characters or fewer, and Jambavan does not run tests or terminal commands after an edit.
If a full-file proposal fails its validation checks, Jambavan tries a focused fallback. For other supported requests, it asks the model for an anchored edit: an operation such as inserting before or after one exact, existing line. The extension only applies that proposal to a temporary copy if the anchor is unique, then opens the result in a diff.
One failure made me add a more specific recovery path. When I asked Jambavan to add an index to a SQL table, Qwen sometimes failed to return the structured edit the extension expected. A stronger prompt alone wasn’t a sufficient fallback.
I added a narrow SQL index handler. It checks that the active SQL file contains the requested table definition, verifies that the requested columns are declared, and rejects the request if an equivalent index is already present. If those checks pass, Jambavan prepares the index change and opens it in a diff for review. This handler supports a specific table-definition pattern; it is not a general SQL migration engine.
That distinction is important: the fallback is deliberately constrained. It doesn’t give the model unrestricted permission to modify a file. It handles one predictable kind of request when the model’s formatting fails, while keeping the developer in the approval loop.
The first scanning approach assumed the work would finish in one uninterrupted run. During testing, Ollama returned a response-header timeout after several files had already been summarized.
The problem wasn’t only that a request failed. It was that a long-running batch needed a better strategy for receiving output and retaining completed work.
I changed the scanner to consume streamed responses from Ollama. More importantly, it now saves each completed file’s summary and hash to the index and updates JAMBAVAN_NOTES.md before moving on. If a later request fails, summaries that were already saved remain available. A subsequent scan can use the hashes to skip unchanged files.
The scan therefore isn’t treated as a single all-or-nothing operation. It can preserve completed work and make a later scan more efficient by skipping files that have already been summarized and haven’t changed. That is a familiar idea from data engineering: make each unit of work observable and recoverable instead of assuming the happy path will always succeed.
I chose Ollama because I wanted to experiment with an assistant that could run on my machine. Local inference can avoid sending prompts to a hosted model service when the endpoint is genuinely local, and it can avoid some network round trips. It may also reduce per-request API costs for workloads that would otherwise use a paid remote model.
Those benefits aren’t automatic. Local models can be slower or less capable than hosted alternatives, and hardware, electricity, maintenance, and model upgrades still have costs. I haven’t benchmarked Jambavan against a hosted coding assistant, so I won’t claim it is faster or cheaper overall. My goal is to explore which everyday tasks a local model can handle usefully and where a remote model might still be the better option.
Privacy also depends on the full data flow. Jambavan’s default Ollama URL is local, but the URL is configurable; prompts go wherever that configured endpoint points. Chat history and saved choices live in VS Code extension storage, while generated repository notes are written into the workspace. During scanning, Jambavan skips files whose names look sensitive and redacts several common secret formats from excerpts. That is a basic precaution, not a comprehensive secret detector. Developers should inspect the context list and avoid putting credentials in prompts or source files.
For me, local-first doesn’t mean that every task must stay on-device. It means I can make that choice deliberately instead of making remote inference an unavoidable default.
Jambavan is an early prototype. You can explore the source on GitHub. To run the current development version, you’ll need VS Code, Node.js with npm, Ollama, and the configured model available locally.
F5 runs the development version in a temporary test window. The project is not yet packaged as a regular VS Code extension. It also does not have an automated test script, does not execute shell commands, and does not monitor GitHub directly. Local workspace changes become visible after they are present in the checkout.
There are still a few things I want to improve in Jambavan. I want it to do a better job of finding the right files for a question, give me more control over what it remembers, and eventually help me run tests and understand failures — with my permission before it executes anything.
I’m not trying to build all of this at once. I’d rather add one feature, test it, see where it breaks, and then move on to the next. Just calling something an AI agent doesn’t make it a good one. It needs to behave predictably, and I need to be able to trust what it’s doing.
Building Jambavan has reminded me of a lesson from data engineering: model output is only one part of a dependable system. Context selection, persistence, validation, failure handling, visibility, and user control determine whether that output becomes useful in practice.
The code is available on GitHub. I’m still building, testing, and discovering where the design needs to improve. That’s part of the project, not something I want to hide.
For me, the bigger question is this: Can I build an AI coding assistant that understands my project well enough to be a useful teammate, while still leaving the important decisions in my hands?
That’s what I want to find out with Jambavan.
Jambavan: My Own Local AI Coding Assistant was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.