Problem and solution
01/Problem
02/Solution
03/How it works
The system, end to end.
- 01next →
Index
Build a typed symbol graph of the repo.
- 02next →
Locate
Locate candidate symbols per request.
- 03next →
Score
Rank by recency, similarity, and use.
- 04next →
Compose
Build a tight, grounded context window.
- 05loop
Respond
Model reasons against actual files.
04/Architecture
Components and data flow.
How the moving parts fit together. Solid arrows are synchronous calls; dashed arrows are queued or batched.
- 01
Editor / CLI
- 02
Indexer (TS / Python / Go)
- 03
Symbol graph store
- 04
Retriever
- 05
Context composer
- 06
Model adapter
- 07
Local model fallback
05/Technology
The stack.
- AI / ML
- GPT-class modelsLocal GGUF fallbackCodeT5+ embeddings
- Frontend
- VS Code extensionCLI
- Backend
- RustNode.js
- Database
- SQLiteLanceDB
- Infrastructure
- Local-firstDocker
- APIs
- OpenAIAnthropicOllama
06/Engineering decisions
What we picked, and why.
- 01
Symbol graph instead of chunked text
Choice
AST + references, not raw file slices
Alternatives
- Sliding window chunks
- Vector-only retrieval
Why
Chunked retrieval pulled in stale or wrong-version code. The symbol graph made references exact.
- 02
Local model fallback
Choice
Route simple requests to a local GGUF model
Alternatives
- All requests to hosted models
Why
Cut cost on routine edits and kept private repos fully on-prem when needed.
07/Evaluation
What we measured.
- 01
61%
Acceptance rate
- 02
0.9s
Latency p50
- 03
34%
Local fallback share
08/Challenges
What almost broke us.
- 01
Multi-language repos
What happened
Different AST strategies per language.
What we did
Pluggable indexer adapters with a shared symbol schema.
09/Results
Used daily by ~40 engineers. Reduced 'wrong API' rejections by 38% in the first month.
10/Future improvements
- ›Incremental indexing
- ›Test-aware suggestions
Have an interesting AI problem?
Let's build something.
If you're working on something that needs real AI engineering — not just a demo — let's talk.