Flagship project · AI engineering and repository research

Code Intelligence

A deployed, local-first code intelligence workbench for captured source, hybrid retrieval, relationship graphs, and grounded answers whose every claim is validated against the exact source it cites before it reaches the reader.

Make repository answers traceable to the code

Code Intelligence is my current flagship project: a deployed workbench that makes unfamiliar repositories inspectable through private, source-backed search and answers, without executing repository code and without presenting a model's interpretation as established fact.

The engineering problem extends beyond finding similar text. An answer may depend on a symbol declaration, an implementation in another file, or a caller that connects the two. An answer is only useful if a reader can follow each statement back to the exact source that supports it, so the workbench exposes relationships, citations, and research traces alongside every result.

V1 ships retrieval, inspection, and grounded answers together. Answers reached the release only after a frozen eight-question review moved from two passing answers to eight on the production model, and they ship with their measured limits stated rather than hidden.

A modular monolith with explicit evidence boundaries

FastAPI exposes a versioned /api/v1 interface and a dependency-free browser workbench through separate API and web modules. The application runs on a VPS, while model inference runs on a home server with an RTX 2070 reached over a private WireGuard link; no model port is public.

SQLite is authoritative for repositories, captured source, symbols, relationships, the FTS5 lexical index, accounts, and durable answer traces. Qdrant is a rebuildable semantic projection. Ollama serves nomic-embed-text embeddings and Granite 3.2 8B generation. Repository content is data, never executable input: parsing runs in isolated worker processes with memory, time, and output limits, and instructions found in source are excluded from model context.

  1. 01

    Register and capture

    Explicitly allowlisted repositories feed bounded scanning with ignore rules and content hashes. Tree-sitter parses Python, JavaScript, TypeScript, Go, and JSON, with dedicated parsers for Markdown, YAML, and XQuery and a text fallback.

  2. 02

    Index incrementally

    Source hashes and parser, chunker, and model fingerprints identify stale work. Symbols, references, and one-hop relationships (imports, calls, containment, test targets) are stored in SQLite; Qdrant holds the corresponding vectors.

  3. 03

    Retrieve and inspect

    Exact symbols, lexical search, and semantic similarity produce ranked evidence with per-channel diagnostics. Relationship context and source inspection support cross-file questions.

  4. 04

    Answer and validate

    A bounded research workflow gathers evidence for local generation. The service validates every claim against its cited source before delivery and persists the trace, so each answer can be reviewed after the fact.

Combine identifiers, language, and meaning

Exact and lexical search

Exact matching targets symbol declarations. SQLite FTS5 and BM25 search source, symbol names, and paths, with normalization for camelCase and snake_case identifiers.

Hybrid ranking

Reciprocal rank fusion combines retrieval channels while preserving exact-declaration priority. Debug output exposes terms, ranks, candidate counts, and timings.

Authoritative evidence

Semantic candidates are checked against active SQLite versions, so stale or pending vectors are rejected. Stored vector payloads are not treated as trusted source text.

Deterministic ordering

One defect surfaced only through answer evaluation: the semantic channel paged through Qdrant with offsets, and equal-score points made pages overlap, so identical queries could return evidence in different orders. Fetching candidates in one query with a deterministic score-then-ID order fixed it without a regression in the controlled lane.

Validate every claim before it reaches the reader

The Ask workflow plans searches and file inspections, gathers evidence, and asks the model for a structured answer in which every factual claim carries an exact source quote and citation. The service then validates the answer before delivery.

Citations must reference supplied evidence, and quotes must occur verbatim in the cited source. Inline code in a claim must appear in its quote or near it in the cited evidence. Claims may not place code in a component they do not cite, say a value is displayed without quoting the code that renders it, rest runtime claims on type declarations alone, or explain a non-rethrowing catch block without saying so. Abstentions must lead with the inability and name a concrete missing data source.

Failures go back to the model as one combined correction message, within a time budget, for up to two retries. If every attempt fails, the service may return the earliest attempt with only the rejected claims removed, but only when everything else validates and the summary does not repeat a removed claim. The removal is shown to the user and recorded in the trace.

Validation establishes that each statement is tied to source that supports it; it does not make the model infallible. That is why answer quality is measured separately, on frozen questions with human-reviewed judgments.

Move between the graph, source, and answer

The browser workbench connects repository selection, source exploration, relationship graphs, search, answers, and evaluation results. The graph maps imports, calls, references, and test targets, with filters and a bounded visible slice to keep larger repositories navigable.

Search exposes exact, lexical, semantic, and hybrid modes with filters and diagnostics. The source explorer and research trace let a reader follow an answer back to the captured implementation instead of treating generated prose as the end of the workflow.

Separate pipeline regression from model quality

Controlled retrieval lane

Twenty frozen questions over synthetic fixtures run in exact, lexical, semantic, and hybrid modes across 16 reports. CI compares every run against a committed, outcome-aware baseline and fails on any regressing case. Semantic modes use token-hash vectors, so they test the pipeline, not embedding quality.

Live answer lane

Eight frozen questions over two real TypeScript and JavaScript repositories, including two runtime questions that must abstain. A case passes only if every claim is supported by its cited evidence, the answer is adequate, and every expected fact is covered.

Reproducible review

Generation runs at temperature 0 with a fixed seed, so unchanged inputs reproduce identical answers. Reviews bind to each answer's SHA-256, so any change to an answer invalidates its review.

From 2/8 to 8/8

The improvement came from general mechanisms: control-flow notes, structured abstention, the retrieval ordering fix, semantic checks routed through retries, and the disclosed fallback. Each was replayed against every stored answer to confirm it rejected only real errors. No frozen case, expectation, or review rule was relaxed, and two experiments that did not help were reverted.

Offline verification

501 tests pass, with Ruff, formatting, and mypy clean, and the controlled lane reports no regressions in the pinned CI image.

Keep the workbench accessible and inference private

The application provides administrator-managed accounts with no public registration, role-based authorization, revocable sessions, and CSRF protection for writes. Session cookies are HttpOnly, Secure, and SameSite=Strict, and only ports 80 and 443 are public.

The deployment at code.asmale.me requires sign-in and ships through the established GitLab CI/CD pipeline. Live readiness reports SQLite, Qdrant, and Ollama healthy, and the API reports the Granite 3.2 8B production profile that passed the answer review.

Release gates were recorded rather than assumed: coverage closure mapped every documented capability to tests, and production readiness verified live configuration, GPU placement, health, the private inference path, the route boundary, public ports, and cookies, with the owner attesting to the host-side checks.

An inspectable system with measurable limits

The shipped V1 joins incremental indexing, hybrid search, code relationships, validated grounded answers, evaluation, and a browser workbench into one repository research workflow. It is the main project through which I am extending full-stack and backend experience into AI engineering.

Model choice was measured, not assumed. The originally deployed Granite 4.1 3B model was about ten times faster per attempt but scored 0/8, so production moved to Granite 3.2 8B. The cost is latency: answers take about one to four minutes, because the model and its 16,384-token context need 7.8 GB and run split between CPU and GPU on an 8 GB card. Answers are served one at a time and rate-limited.

Current limits are stated plainly. Live answer coverage is eight questions on two repositories, with no Python, Go, architecture, or configuration case and no ambiguous prompts. Five of the eight answer reviews were assistant-authored, with the owner confirming the three judgment calls. The claim-removal fallback changes model output, though it only removes claims and always discloses the removal. The live backup and restore was owner-attested rather than captured.

The central lesson is that answer quality depends on the entire evidence pipeline. A retrieval ordering defect surfaced only through answer evaluation, and keeping retrieval, generation, and validation separately measurable is what made each fix verifiable.