-
-
failed google drive mount
-
Google Colab GPU
-
successful google drive mount
Inspiration
The seed was my own cloud product, getdebug.dev, AI code-security review. But every tool in that class (CodeRabbit, Snyk, cloud SAST) quietly assumes three things: fast internet, a company credit card, and permission to send your source code to a server abroad. For most developers on the continent, those are three walls.
A three-person fintech team in Accra moving school fees over mobile money often ships code that handles children's financial data with no security review at all; not because they don't care, but because the tools that would help are unreachable: priced in dollars against revenue in cedis, gated behind connectivity they don't always have, and blocked by data-residency rules for banking data. I wanted to find out: could a genuinely useful code reviewer run entirely offline on the $150–$500 laptop they already own?
What it does
getdebug-edge is an offline, security-first code reviewer. You point it at a project folder and a 3-billion-parameter model running entirely on your CPU no internet, no account, no data ever leaving the machine, reads your code and flags bugs, vulnerabilities, and correctness issues with suggested fixes.
- Hybrid detection: the LLM handles reasoning-heavy bugs; fast deterministic detectors catch the pattern-matchable classes (hardcoded secrets, weak crypto, secrets-in-logs) it would otherwise miss.
- Meets you where you work: findings drop into VS Code's Problems panel, clickable to the line; a one-shot mode answers ad-hoc questions.
- Honest by design: it's a first-pass triage that points a developer at the code worth a closer look, not an authoritative gate.
It works in a village, during a power cut, and inside compliance rules; because it needs nothing but the laptop on the desk.
How we built it
I measured every decision, not assumed:
- Model: I benchmarked six open models head-to-head (Qwen2.5-Coder-3B/1.5B, Qwen3-4B, Gemma-3-4B, Llama-3.2-3B, DeepSeek-Coder, GLM-Edge) on a real laptop. Qwen2.5-Coder-3B won on accuracy-per-resource.
- Runtime: llama.cpp with the model quantized to a ~2.1 GB 4-bit GGUF, loaded once into a persistent server, context capped at 3072 tokens, KV cache quantized with flash attention.
- The threading discovery: using physical cores instead of logical threads made it ~25% faster AND ~27°C cooler, generation is memory-bandwidth-bound, so hyperthreads add heat, not speed.
- A hybrid pass: cheap regex detectors for the classes a 3B model reliably misses, because you shouldn't ask a language model to do what a regex does better.
- A measurement harness: a seeded-bug eval (22 planted bugs + clean controls) that scored every change objectively, plus a persona baked into the model, prompt/KV and result caching, and deterministic decoding.
- Verification: I ran the whole thing in a container pinned to the contest spec, Ubuntu 22.04, 4 CPUs, 8 GB RAM with swap disabled, reviewing a real Flask app.
Challenges we ran into
- Fine-tuning made the model worse, twice. Two LoRA runs on a free Colab T4 both regressed accuracy: the first taught it to stop after a single finding (terseness), the second overfit to my templated training data and started answering "no issues" on obviously buggy code.
- The obvious performance setting was a trap. Using all CPU threads was slower than using fewer, and ran hot enough to trip the contest's thermal-throttling penalty, the exact opposite of intuition.
- My accuracy benchmark was too small to trust. An early 10-sample eval showed a flattering 80% recall; the number moved sharply once the sample was large enough to mean anything, and I had to confront a lower, truer figure.
- The 3B model over-flags clean code. It reported "SQL injection" on queries that were correctly parameterized and safe, the kind of false positive a larger model wouldn't make.
- …and it's blind to whole classes of real bugs. Hardcoded secrets, weak cryptography, access control (IDOR), and secrets written to logs slipped past it — the reasoning-heavy or pattern-specific issues a small model doesn't reliably catch.
- The model kept finding ways to misbehave. Given a terse prompt it took the "no issues" escape hatch and skipped a genuine SQL injection; at nonzero temperature it produced different output formats run-to-run, some of which broke my findings parser; and greedy decoding occasionally sent it into repetition loops.
- A fixed network port silently corrupted a run. The agent assumed port 8080 was free, an unrelated app was already listening there, answered "healthy," and the agent happily "reviewed" code against a server that wasn't even running the model.
- A read-only test mount produced phantom findings. When the target directory was read-only, the bundled linter failed with a filesystem error, and that error text got fed to the model as if it were a lint hint, which it dutifully reported as a bug.
- African-language support collapsed beyond Swahili. Probing Hausa, Yoruba, Amharic, and Twi, the small models degenerated or answered in the wrong language entirely, closing off a language-bonus path I'd hoped to claim honestly.
- Getting the model onto constrained hardware was its own fight. Free Colab sessions recycled mid-work and 2 GB downloads stalled near completion; baking the reviewer persona into the model's chat template broke the server at startup over a single stray apostrophe in the template.
What's next for getdebug-edge
- Close the reasoning-heavy gap (access control / IDOR, business-logic validation) with lightweight taint analysis for authorization flows.
- Real reference-hardware validation on a refurbished Intel i5 for true throughput numbers.
- Wider language reach for finding explanations via offline translation models (and GhanaNLP/Khaya as an opt-in online mode), honestly, not by overclaiming.
- Broader detector coverage and tree-sitter AST-aware chunking.
- Keep it free and open-source, so the developers who need it most never hit a paywall.
Log in or sign up for Devpost to join the conversation.