DEV Community: AMIT KUMAR SINHA

Vector : local code summariser

AMIT KUMAR SINHA — Sun, 25 Oct 2026 16:07:11 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Everyone has opened an unfamiliar repo and spent the first hour just trying to work out what it does. Vector is my lazy answer to that hour.

Vector is a local code summariser. Give it a file, a GitHub repo, or an entire project folder, and it tells you what the code is for before you read any of it. Every file gets a TL;DR, its purpose, key functions with line ranges, dependencies, and gotchas. For a whole project it also writes an overview: tech stack, architecture, a directory map, entry points, how to run it, and an ordered "start reading here" list.

The laziest part is watch mode. Point Vector at a folder, edit a file, and a fresh summary shows up on its own a few seconds later. You never have to ask.

It's for anyone who reads more code than they write: students inheriting a messy assignment, Hacktoberfest contributors landing in a new repo, and anyone who has ever said "wait, what does this module do?"

Demo

https://vector-frontend-dxot.onrender.com

Code

https://github.com/amitsinha-cell/vector.git

How I Built It

The open pieces

Gemma 4 E4B is the default model. I also use Gemma 4 E2B as the light option and Qwen2.5-Coder 7B as "deep mode."
Ollama runs inference locally.
tree-sitter splits code by structure (functions, classes), not by size.
FastAPI + SQLite (FTS5) handle the backend, caching, history, and search.
watchdog powers the folder watcher.
The frontend is React + Vite + TypeScript, started in Lovable. I built the backend with Antigravity, and the specs and design decisions were mine.

My hardware is the whole story. I built and tested this on an HP Victus laptop with an RTX 4050 (6 GB VRAM, 50W TGP). That is not a big machine, and it shaped every decision:

Structure-aware chunking. Small models get lost in long files. Vector parses the file, summarises each function or class, then rolls those up into a file-level summary. If parsing fails, it falls back to overlapping line windows.
Hierarchical project mode. A whole folder will never fit in one context window. Vector summarises files, then directories, then the project. Only the top-ranked files (entry points, manifests, most-imported modules) get full LLM summaries. The rest get a one-line description built from their function and class names, with no model call at all.
Cache by content hash. The cache key is the file's contents plus the model and prompt version. Re-uploading an unchanged folder returns almost instantly, so the GPU only works on what changed.
One GPU queue. Watcher jobs and manual requests never run at the same time on the same card.
Schema-checked output. Every result is validated against a fixed JSON schema, with one repair retry before returning a partial result with a warning.

What went wrong. gemma4:e4b is 6.6 GB on disk and my card has about 5 GB free, so part of it runs on CPU. I added a smaller-model retry and kept E2B one dropdown away.

My favourite bug: the UI said "Ollama isn't running" while Ollama was fine. The real cause was a CORS preflight rejection. Vite had moved to port 8081 and the backend's allowlist didn't include it, so the browser never read /health. The fix was easy, but the real lesson was that "backend unreachable" and "Ollama down" are different failures and the UI should say which one it is. It does now.

Why Does Open Innovation Matter?

Your code stays on your machine. A code summariser is a poor fit for a closed API. People paste private, unreleased, or employer-owned code into it. With local models the code never leaves the laptop. The UI shows a "100% local" badge, and a hosted fallback exists only as an opt-in setting that is off by default, with a warning before any code is sent.

Watch mode is only practical when inference is free. An assistant that re-summarises every time you save a file would run up an API bill quickly. Locally, the only cost is electricity.

Swapping models is a dropdown. I could try Gemma 4 against Qwen2.5-Coder on my own files and pick per task. A closed API doesn't let me do that.

It works offline. Once the models are pulled, Vector needs no internet except for GitHub repo mode.

Customising is possible. Because the weights are open, I can fine-tune a small Gemma on code-summary pairs next. I've fine-tuned small Gemma models before, and that path is closed with a hosted API.

Where closed still wins. Large frontier models write better summaries of huge, tangled files. For "tell me what this folder is about," a small local model with good chunking was good enough, and it was private.

The Lazy Payoff

For example: "A 40-file project that took me about 120 minutes to understand by reading now takes 30 minutes, and the cached re-run takes 10 seconds."

Prize Categories

Gemma: Gemma 4 E4B and E2B are the core models.
GitHub: repo ingestion. [Keep this only if repo mode really uses the GitHub API or clones through GitHub.]

Trail bird journal v1

AMIT KUMAR SINHA — Sat, 17 Oct 2026 19:05:52 +0000

What I Built
Trail Bird Journal is an offline bird-song journal that runs entirely on my phone. You tap Record (or upload a clip), an open bird-sound model names the species it hears, and the app writes a short field-journal entry and saves it with the audio. A second page keeps a growing life list of every bird you've identified.
It is for the person who walks past a hundred birds a day and has never known their names, and especially for the places where birdwatching actually happens: trails, woods and wetlands where there is no signal. A cloud app is useless there. This one works with airplane mode on, and your recordings never leave the phone.
The point is to get you outside and keep you standing still. The reward for listening is a name, an entry in your journal, and one more bird on the list.
A real entry from my outdoor test:
Date : 10/10/2026
Place : Near an open ground
Species recognised : rock dove

Demo

Code

amitsinha-cell / Trail-Bird-Journal

Trail Bird Journal

An offline bird-song journal for your phone. Record or upload a clip, and the app identifies the birds with BirdNET and writes a short field-journal entry. No internet, no cloud, no account. Built for the "Touch Grass" open-source AI challenge.

How it works

Browser page records audio (or you upload a file) and sends it to a local FastAPI server.
ffmpeg converts it to 48 kHz mono WAV.
BirdNET (ONNX backend) lists the species it hears with confidence scores.
The journal sentence is first built by plain Python from those detections, so it can only state what was detected. An optional small local LLM (Gemma 3 1B, via llama.cpp) may rewrite it, and a validator rejects any rewrite that adds facts, so the template text is used instead.
Each session is saved as a JSON file plus the audio clip. History and Birds Discovered pages…

View on GitHub

Everything is in the repo: a FastAPI server, a small pipeline, and four hand-written pages with no frameworks and no CDN. No model weights are in the repo; the README says where to download them.
How I Built It
I built and ran all of it on an Android phone (iQOO Z9, 8 GB RAM) using Termux, a proot Ubuntu, and opencode as my coding agent.
Browser page (phone)
-> FastAPI server (localhost, inside proot Ubuntu)
-> ffmpeg: any audio -> 48 kHz mono WAV
-> BirdNET (ONNX backend): species + confidence per 3-second window
-> journal.py: builds the entry text, optional LLM rewrite, validator
-> saves entries/.json and audio/.wav
-> optional: llama-server (native Termux) running Gemma 3 1B (Q4_K_M)
Bird identification: BirdNET (Cornell Lab of Ornithology and Chemnitz University of Technology), run through its ONNX backend. It scores each 3-second window of the clip against thousands of species.
Journal writer: Gemma 3 1B Instruct (4-bit GGUF) via llama.cpp, about 11 tokens per second on the phone.
No training. The project wires two open models together and builds the safety net around them.
The design rule that came out of the project: the language model never gets to know anything about birds. Plain Python builds a sentence from the detections, and the model may only rephrase it. That rule exists because of what went wrong, which is most of the story.
Challenges, and what I changed

TensorFlow doesn't exist for my Python. My proot Ubuntu ships Python 3.14. pip install birdnet-analyzer failed because it needs TensorFlow, which had no wheel for 3.14. The newer birdnet package also defaults to a TensorFlow backend, so that failed too. The fix was its ONNX backend (model version 3.0), which needs no TensorFlow at all. Open model formats let me route around a packaging dead end instead of giving up.
A crash caused by a missing if name == "main". BirdNET starts worker processes, and Python 3.14 re-imports the script in each one, so without the main guard everything died with an unhelpful "child process exited with exit code 1". The guard plus n_workers=1 (to keep RAM low) fixed it.
Two tools disagreed about the same clip. My first test clip scored Eurasian Skylark at 0.91, 0.95 and 0.90 across its three segments. A web bird-ID app said Daurian Redstart. BirdNET's top ten never included the redstart. I listened to it: a long, continuous, rising song, which matches a skylark, so I trusted the model whose scores I could see. The lesson is that every ID needs a confidence label, so the app now says "clearly identified", "likely" or "possibly, not certain" based on the score.
My 1B model lied to me. First test, I asked Gemma for "one fact about the bird". It told me skylarks nest "in the eaves of buildings". They nest on the ground in open fields. When I removed the fact request and tightened the prompt, it still invented things I never gave it: a "forest clearing" (the place was "unknown"), "bright yellow plumage", "a red bird", "a beautiful, melodic sound". On a noisy 80-second forest clip it simply repeated my prompt's format back at me. A 1B model copies the shape of whatever you show it and fills gaps with plausible fiction. What worked: Python decides everything factual (species, hedge words, segment counts). Python writes the entry text itself. This is the default. Gemma may rewrite it, but a validator rejects any rewrite that adds banned words (colors, habitats, behaviors), drops a species, or loses a "possibly" hedge. If the rewrite fails validation, or the LLM isn't running, the app uses the template entry and labels it "template" instead of "local LLM". So the bird ID is never the LLM's problem, and the LLM can't make the journal wrong.
The counting bug: "23 of 3 segments". On an 80-second clip with 27 windows, my summary said a nuthatch was "detected in 23 of 3 segments". The total was hard-coded from my 8-second test clip. I fixed it by counting unique start times, and later hit a cousin of the same bug: the template once printed "heard 3 of Alauda arvensis segments", where the scientific name had landed in the slot for the total. Small bugs, but a journal that states wrong numbers is worse than no journal.
8 GB of RAM is not much. llama-server, code-server and opencode together do not fit. Android killed sessions until I started working in phases: build with the editor and agent, then close them, then test with only BirdNET running, then add the LLM last. A 4-bit 1B model needs about 1 GB, BirdNET about the same, and the OS takes the rest.
The agent wrote a frontend it never ran. I used opencode to generate the backend and pages. The Python mostly worked. The browser side did not, because the agent had only checked syntax and never loaded a page. What went wrong: Pages linked style.css instead of /static/style.css. Served at /capture, the browser asked for /style.css and got a 404. The Play button was a plain link, so the browser downloaded a file named recording.wav.json containing {"detail":"Audio not found"}. The server looked for audio in one folder while the pipeline saved it in another. Buttons did nothing. The forms were hidden with inline styles and the script that should show them never ran, so Skip and Continue just reloaded the page with a stray ?step=1 in the URL. The server crashed at startup calling a helper that no longer existed. Uploads failed with a 422 because the page sent the file under a different field name than the server declared. I fixed these by hand with small patches, then replaced the capture page with a compact hand-written one, since patching on top of dead code wasn't working.
The microphone, and a format BirdNET can't read. Recording first failed with "Permission denied" because the browser stores mic permission per address and I was on 127.0.0.2 instead of localhost. Once the mic worked, the recording came back as WebM, which BirdNET cannot read. Rather than depend on ffmpeg inside proot, the page now decodes the recording in the browser, resamples it to 48 kHz mono, and uploads a real WAV, the same kind of file as my working uploads. I took it outside When and where: 10/10/2026, 9:43AM, near an open ground Setup: phone in airplane mode, llama-server and the app running in Termux Clips recorded: 4, each 8 sec What it got right: rock dove Airplane mode check: did everything work offline? yes Why Does Open Innovation Matter? It works where closed APIs can't. The places worth birdwatching have no signal. A hosted model would have meant a recording you can't process until you get home. Open weights and local inference mean the answer arrives while the bird is still singing. Private by construction. Field recordings carry your location, your voice, and sometimes strangers' conversations. Nothing leaves the phone, so there is nothing to leak. Swappable without permission. When TensorFlow had no build for my Python, I switched BirdNET to its ONNX backend and carried on. I can swap Gemma for another small model, or change the bird model, by changing one path. Inspectable, so I could constrain it. Because I could see BirdNET's raw scores and run the LLM on my own hardware, I could find exactly where the 1B model made things up and build a validator around it. With a black-box API I could only have hoped the prompt held. Free to run. No account, no key, no per-request cost, and no bill for walking around a pond for an hour. Where open beat closed here was not raw quality (a large hosted model would write nicer sentences). It was availability, privacy, and the freedom to fix things myself. Honest caveats: BirdNET's model weights are licensed for non-commercial use, so this project is a personal and educational one. The birdnet Python package itself is MIT-licensed. Gemma is open-weight under Google's terms of use, not an OSI open-source license. Prize Categories Goggle gemma

Trail Bird Journal

AMIT KUMAR SINHA — Sat, 10 Oct 2026 17:26:35 +0000

Demo

Code

amitsinha-cell / Trail-Bird-Journal

Trail Bird Journal

How it works

Browser page records audio (or you upload a file) and sends it to a local FastAPI server.
ffmpeg converts it to 48 kHz mono WAV.
BirdNET (ONNX backend) lists the species it hears with confidence scores.
The journal sentence is first built by plain Python from those detections, so it can only state what was detected. An optional small local LLM (Gemma 3 1B, via llama.cpp) may rewrite it, and a validator rejects any rewrite that adds facts, so the template text is used instead.
Each session is saved as a JSON file plus the audio clip. History and Birds Discovered pages…

View on GitHub

TensorFlow doesn't exist for my Python. My proot Ubuntu ships Python 3.14. pip install birdnet-analyzer failed because it needs TensorFlow, which had no wheel for 3.14. The newer birdnet package also defaults to a TensorFlow backend, so that failed too. The fix was its ONNX backend (model version 3.0), which needs no TensorFlow at all. Open model formats let me route around a packaging dead end instead of giving up.
A crash caused by a missing if name == "main". BirdNET starts worker processes, and Python 3.14 re-imports the script in each one, so without the main guard everything died with an unhelpful "child process exited with exit code 1". The guard plus n_workers=1 (to keep RAM low) fixed it.
Two tools disagreed about the same clip. My first test clip scored Eurasian Skylark at 0.91, 0.95 and 0.90 across its three segments. A web bird-ID app said Daurian Redstart. BirdNET's top ten never included the redstart. I listened to it: a long, continuous, rising song, which matches a skylark, so I trusted the model whose scores I could see. The lesson is that every ID needs a confidence label, so the app now says "clearly identified", "likely" or "possibly, not certain" based on the score.
My 1B model lied to me. First test, I asked Gemma for "one fact about the bird". It told me skylarks nest "in the eaves of buildings". They nest on the ground in open fields. When I removed the fact request and tightened the prompt, it still invented things I never gave it: a "forest clearing" (the place was "unknown"), "bright yellow plumage", "a red bird", "a beautiful, melodic sound". On a noisy 80-second forest clip it simply repeated my prompt's format back at me. A 1B model copies the shape of whatever you show it and fills gaps with plausible fiction. What worked: Python decides everything factual (species, hedge words, segment counts). Python writes the entry text itself. This is the default. Gemma may rewrite it, but a validator rejects any rewrite that adds banned words (colors, habitats, behaviors), drops a species, or loses a "possibly" hedge. If the rewrite fails validation, or the LLM isn't running, the app uses the template entry and labels it "template" instead of "local LLM". So the bird ID is never the LLM's problem, and the LLM can't make the journal wrong.
The counting bug: "23 of 3 segments". On an 80-second clip with 27 windows, my summary said a nuthatch was "detected in 23 of 3 segments". The total was hard-coded from my 8-second test clip. I fixed it by counting unique start times, and later hit a cousin of the same bug: the template once printed "heard 3 of Alauda arvensis segments", where the scientific name had landed in the slot for the total. Small bugs, but a journal that states wrong numbers is worse than no journal.
8 GB of RAM is not much. llama-server, code-server and opencode together do not fit. Android killed sessions until I started working in phases: build with the editor and agent, then close them, then test with only BirdNET running, then add the LLM last. A 4-bit 1B model needs about 1 GB, BirdNET about the same, and the OS takes the rest.
The agent wrote a frontend it never ran. I used opencode to generate the backend and pages. The Python mostly worked. The browser side did not, because the agent had only checked syntax and never loaded a page. What went wrong: Pages linked style.css instead of /static/style.css. Served at /capture, the browser asked for /style.css and got a 404. The Play button was a plain link, so the browser downloaded a file named recording.wav.json containing {"detail":"Audio not found"}. The server looked for audio in one folder while the pipeline saved it in another. Buttons did nothing. The forms were hidden with inline styles and the script that should show them never ran, so Skip and Continue just reloaded the page with a stray ?step=1 in the URL. The server crashed at startup calling a helper that no longer existed. Uploads failed with a 422 because the page sent the file under a different field name than the server declared. I fixed these by hand with small patches, then replaced the capture page with a compact hand-written one, since patching on top of dead code wasn't working.
The microphone, and a format BirdNET can't read. Recording first failed with "Permission denied" because the browser stores mic permission per address and I was on 127.0.0.2 instead of localhost. Once the mic worked, the recording came back as WebM, which BirdNET cannot read. Rather than depend on ffmpeg inside proot, the page now decodes the recording in the browser, resamples it to 48 kHz mono, and uploads a real WAV, the same kind of file as my working uploads. I took it outside When and where: 10/10/2026, 9:43AM, near an open ground Setup: phone in airplane mode, llama-server and the app running in Termux Clips recorded: 4, each 8 sec What it got right: rock dove Airplane mode check: did everything work offline? yes Why Does Open Innovation Matter? It works where closed APIs can't. The places worth birdwatching have no signal. A hosted model would have meant a recording you can't process until you get home. Open weights and local inference mean the answer arrives while the bird is still singing. Private by construction. Field recordings carry your location, your voice, and sometimes strangers' conversations. Nothing leaves the phone, so there is nothing to leak. Swappable without permission. When TensorFlow had no build for my Python, I switched BirdNET to its ONNX backend and carried on. I can swap Gemma for another small model, or change the bird model, by changing one path. Inspectable, so I could constrain it. Because I could see BirdNET's raw scores and run the LLM on my own hardware, I could find exactly where the 1B model made things up and build a validator around it. With a black-box API I could only have hoped the prompt held. Free to run. No account, no key, no per-request cost, and no bill for walking around a pond for an hour. Where open beat closed here was not raw quality (a large hosted model would write nicer sentences). It was availability, privacy, and the freedom to fix things myself. Honest caveats: BirdNET's model weights are licensed for non-commercial use, so this project is a personal and educational one. The birdnet Python package itself is MIT-licensed. Gemma is open-weight under Google's terms of use, not an OSI open-source license. Prize Categories Goggle gemma

Byte-Gemma: An Offline C++ Tutor That Asks Instead of Tells

AMIT KUMAR SINHA — Sun, 04 Oct 2026 18:59:02 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

A fully offline C++ tutor that runs on a phone, built for [friend's name], who is learning C++ from scratch.

Most AI tools hand over the answer, and my friend ended up copy-pasting code without understanding it. Byte-Gemma is a fine-tuned Gemma 3 1B that teaches Socratically. It stays under ~100 words, praises one thing you got right, and asks one guiding question. It runs locally on Android, so it works without internet or an API bill.

Slash commands control how much help you get:

Command	Behaviour
`/explain`	Concept via analogy, tiny example, one question
`/debug`	Only the first hint
`/hint`	A more specific hint, no full solution
`/solution`	Full fix, explanation, practice question
`/review`	One thing done right, the key issue, you fix it
`/quiz`	One question, waits for your answer

Demo

Code

How I Built It

Base: Gemma 3 1B (open weights), fine-tuned and quantized to Q4_K_M GGUF.
Data: [~300] examples generated with Gemma 4 as a teacher via the Gemini API. Validation scripts filtered out low-quality outputs, and I merged in cleaned examples from my friend's real coding mistakes.
Runtime: llama.cpp-based, with PocketPal/Termux on Android.
A pivot: My first version was a gamified "Byte" persona. Testing showed it wasn't teaching well, so I rebuilt it around Socratic tutoring.

Evaluation (and what failed)

My friend and I compared Byte-Gemma against stock Gemma 3 1B on struct vs class, pointers vs references, and multithreading. My first attempt gave only Byte-Gemma the tutoring system prompt, which made the result meaningless. So I re-ran it with the identical system prompt, runtime, and questions for both models.

Where Byte-Gemma won: following the tutoring rules.

6 of 6 replies stayed under 100 words (about 66 words on average for first replies). The stock model went over in 3 of 3 (131 to 214 words).
Byte-Gemma asked exactly one question per reply. Stock Gemma asked three in the struct/class test and ended others with "Does that make sense?".
Speed per token was about the same (about 6.4 vs 6.7 tok/s), but replies about 2.7x shorter mean much shorter waits on a phone.

Where it fell short: accuracy.

Every Byte-Gemma reply had at least one error, and at least 4 of its 6 code snippets were broken (assigning "Red" to an int, * = 12;, Car<Car>, and a "multithreading" example that never creates a thread).
It never stated the real struct/class difference (default access), and it wrongly said references can't access an object directly.
With one-word replies like "classes" or "structure", it said "You are right" and then invented that objects are created "using the <iostream> header". A tutor that agrees with a confused student and adds a wrong fact is the failure I most want to avoid.
Stock Gemma had errors too (calling a reference "not an alias", a class with an accidentally private constructor), but its multithreading explanation was sound and its pointer example was correct.

Subjective scores: Byte-Gemma 5.5/10, stock Gemma 4/10. Byte-Gemma's lead is smaller than my first run suggested, and it comes from teaching format, not knowledge. Caveats: one run per prompt, 6 Byte-Gemma replies vs 3 stock replies, no follow-up turns for stock Gemma, and code judged by reading rather than compiling.

Neither model is reliable enough to teach unsupervised. Next steps:

Compile every code block in the training data and reject anything that doesn't build.
Add multi-turn examples where the student answers with one word and the tutor checks it instead of agreeing.
Re-run the comparison with fixed temperature and seed, including follow-ups for both models.

Why Does Open Innovation Matter?

Offline: The tutor runs on a phone with no connection.
Customizable: I could change the model's behavior through fine-tuning, not just prompting.
Free: No per-token cost for a student project.
Transparent: My friend could audit the model, find its errors, and show me where it was wrong. Testing against the base model with the same prompt is also what showed me the fine-tune changed its behavior more than its knowledge.

Prize Categories

Google Gemma