QA-Pilot: a Svelte chat front end for asking questions about a GitHub repository

What QA-Pilot is for, and who should care

Reading an unfamiliar repository is mostly a search problem. You have a question about how authentication works or where a route is registered, and the answer is spread across a dozen files. QA-Pilot takes that question in a chat box and answers it from an index of the code. You either enter a public GitHub URL and let the server git clone it, or you click the New Source Button, then Upload next to Confirm, and pick a folder on your machine. The second path matters because it avoids cloning entirely: files are uploaded to the QA-Pilot server and indexed as they arrive.

The intended audience is a developer evaluating an unfamiliar codebase, or someone who wants to keep the whole loop local. The README is blunt about the project's status: it describes QA-Pilot as a test project to validate the feasibility of a fully local question answering setup using LLMs and vector embeddings, and states it is not production ready. That is unusually direct for a README, and it should shape how you read the feature list.

How the indexing and chat pipeline is put together

The repository layout tells most of the story. A Svelte front end lives in svelte-app/, a Python service sits behind it in app.py and qa_pilot_run.py, and provider adapters are collected in qa_model_apis.py. The core requirements file pins FastAPI and uvicorn for the HTTP layer, GitPython for cloning, langchain-text-splitters and langchain-chroma for chunking and vector storage, and chromadb as the vector store. Ollama embeddings are the default embedding path, which is why langchain-ollama appears in the core list while every other provider SDK is pushed into requirements-models.txt.

That split is the most interesting design decision in the project. A minimal install gives you FastAPI, Chroma, GitPython and Ollama. If you want OpenAI, Anthropic, Mistral, ZhipuAI, Tongyi, Moonshot, Nvidia or LocalAI, you install requirements-models.txt and add a key to .env. Chat history is stored in PostgreSQL, which is why psycopg2-binary is a core dependency and why a connection check script exists at the repository root. The codegraph feature is separate from the chat index: parser.go is compiled into a binary that inspects Python and Go files, and the README notes that uploaded sources support both chat and the existing Python and Go codegraphs.

Installing QA-Pilot and asking your first question

The README points to deploy/README.md for what it calls the tested Python 3.13 and LangChain 1.x environment with pinned dependencies, Ollama setup and a systemd service, and says the older instructions below it describe the original environment. Start with the deployment guide if it is present in your checkout. The original path, reproduced here, uses conda and a Python 3.10.14 environment.

git clone https://github.com/reid41/QA-Pilot.git
cd QA-Pilot
conda create -n QA-Pilot python=3.10.14
conda activate QA-Pilot
pip install -r requirements.txt

After that, the README instructs you to install PyTorch with CUDA from the official PyTorch site, then set up a provider. Ollama is the path of least resistance and serves both chat and embeddings in the current dependency set.

ollama pull <model_name>
ollama list

Configuration is a local override file. Copy config/config.ini to config/config.local.ini, which is gitignored, and set the model provider, the model name, the variables and the Ollama API URL there. Hosted providers instead need keys in .env, for example OPENAI_API_KEY or ANTHROPIC_API_KEY. Once the service is running, open the chat UI, create a session, and either paste a GitHub URL into the dialog and press Confirm, or use New Source Button, then Upload next to Confirm, to send a local folder. The upload path accepts .py, .md, .js, .html, .css, .ts, .sh, .go, .java and .svelte files, skips .git, .venv and node_modules, and creates an independent snapshot and session, so local edits require a fresh upload.

The upload limits and the disclaimer are the real constraints

Two things will stop you before anything else does. The first is scope: an upload is capped at 2,000 source files, 10 MiB per file and 50 MiB total, and only non-empty UTF-8 text in the listed extensions is indexed. A monorepo with a large vendored dependency tree will not fit, and neither will a repository written in a language outside that list. The second is the disclaimer, which tells you not to use models for analyzing critical or production data, not to analyze customer data, and not to point the tool at a private or sensitive code repository. Those are the project author's own words, and they are the strongest signal in the README about intended use.

There is a subtler failure mode in the upload path. Each upload creates an independent snapshot and session, so the index does not track your working tree. If you upload a folder, then edit a file and ask about it, you are asking about the old bytes. The README states this plainly, but it is easy to forget mid-session. The git clone path has the same character: it indexes what was cloned, not what you later commit.

How QA-Pilot differs from a general code assistant

A tool like Sourcegraph Cody or GitHub Copilot Chat is wired into your editor and your working tree. It sees the file you have open, it follows your edits, and its answers are grounded in the current state of the code in front of you. QA-Pilot works the other way around. It is a separate web application with its own database, its own vector store and its own snapshot of the repository. You leave your editor, open a browser, and ask questions against an index that was built at upload or clone time.

That is a worse fit for day-to-day editing and a better fit for a specific task: sitting down with a repository you have never seen and interrogating it. The multi-provider design also separates it from editor plugins, which typically tie you to one vendor. QA-Pilot lets you run Ollama locally with deepseek, llama3.1, phi3, llama3 or gemma2, or point it at OpenAI, Anthropic, Mistral, ZhipuAI, Tongyi, Moonshot, Nvidia, LocalAI or llamacpp. The README even lists llmman, a local runner that serves the Ollama API on port 17434. If your constraint is which model you are allowed to use, that flexibility is the reason to pick this over an editor plugin.

Maintenance, licence and what an upgrade costs you

The last push to the default branch was on 2026-09-14, and the repository is not archived. The README's own release log, however, stops in July 2024, with entries for langchain 0.2.6 and moonshot support, so the visible changelog is far older than the last commit. The gap between those two dates is the thing to watch: recent commits exist, but the release notes do not describe them, so you cannot tell from the README what changed in the last two years.

Upgrades are not trivial. The README says the deployment guide covers a tested Python 3.13 and LangChain 1.x environment and notes that installing every historical model SDK is no longer required, which implies the dependency set was reorganized at some point. The core requirements file now pins langchain-classic, langchain-community, langchain-chroma and langchain-ollama at major version 1 or 0.4, a different generation from the langchain 0.2.6 mentioned in the release log. Anyone moving between those versions should expect the provider adapters in qa_model_apis.py to be the fragile part.

QA-Pilot is licensed under Apache-2.0. That permits commercial use and modification, and it includes a patent grant. It also requires you to keep the licence and notice files and to state significant changes. This is a description of the licence text, not legal advice; if you plan to redistribute a modified QA-Pilot, read the LICENSE file in the repository and talk to someone qualified.

Editorial conclusion

Adopt QA-Pilot if you want to read a repository you did not write and you are comfortable running Python 3.13, LangChain 1.x and either Ollama or a hosted API key, and if the code you point it at is not private or sensitive, because the README explicitly warns against that. Skip it if you need a supported, production-grade code assistant: the disclaimer states the project is not production ready, and the upload path caps you at 2,000 files, 10 MiB per file and 50 MiB in total. Before committing time, verify three things in the repository: that deploy/README.md resolves to the pinned environment it claims, that your chosen provider appears in config/config.local.ini, and that your PostgreSQL instance is reachable through check_postgresql_connection.py, since chat history depends on it.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. reid41/QA-Pilot on GitHub