CodeFellow

Learn, debug, and build - no internet required

Comment

Gate 2 model clarification — September 24, 2026

The current CodeFellow model repository points to the Gate 2 artifact, CodeFellow-qlora250-s100-Q4_K_M.gguf. It was adapted from the original Qwen2.5-Coder-3B-Instruct weights using rank-16 QLoRA with 4,000 training and 400 validation examples spanning English, Kiswahili, and natural code-switching. Training completed 250 optimizer steps on an RTX A6000. The adapter was merged at strength 1.0, then converted and quantized to GGUF Q4_K_M for offline llama.cpp inference. This Gate 2 build did not use the importance matrix described for the earlier Gate 1 model.

The public repository contains the adapter weights, training and validation records, training history, source and license manifest, conversion scripts, checksums, and recorded same-prompt comparisons with the unmodified base model. The current model is downloaded through the repository's download_model.sh script. Performance and accuracy figures above refer to the Gate 1 model and should not be read as measurements of this Gate 2 GGUF.

Repository: https://github.com/brianzhou139/CodeFellow

Gate 2 model release: https://github.com/brianzhou139/CodeFellow/releases/tag/gate2-v2

The following project story describes the earlier Gate 1 build and its measurements.

Inspiration

Across Africa, poverty and limited economic opportunities prevent many talented young people from fully participating in the digital economy. Coding can open doors to employment, entrepreneurship, remote work, and the creation of solutions for local problems. Yet learning to program increasingly depends on cloud-based AI tools that require reliable internet access and continuous data spending.

Many students already have access to ordinary, second-hand, or entry-level laptops, but connectivity remains expensive, unreliable, or completely unavailable. The hardware is present; the missing piece is affordable access to capable programming support.

We created CodeFellow to bridge that gap. It is an offline coding tutor and assistant designed to run directly on the ADTC Standard Laptop—an x86-64 computer with integrated graphics and only 8 GB of RAM. By bringing useful programming guidance onto hardware learners already own, CodeFellow aims to ensure that a student’s ability to learn, build, and pursue opportunities in technology is not determined by whether they can afford a constant internet connection.

What CodeFellow does

CodeFellow is an offline coding tutor that generates code, helps debug programs, and explains programming concepts in:

  • English;
  • Kiswahili; and
  • natural English–Kiswahili code-switching.

CodeFellow provides a meaningful cross-disciplinary integration between coding assistance and programming education. It must not only produce executable code, but also preserve the learner's requested function contract and explain the solution briefly in the requested language.

How we built it

We started from the original full-precision Qwen2.5-Coder-3B-Instruct model.

We created 10,000 verified training examples:

  • 65% English coding replay;
  • 20% Kiswahili programming tutoring;
  • 15% English–Kiswahili code-switching.

Parallel examples contain the same programming task in English, Kiswahili, and code-switched form. The executable code is locked across all variants; only the explanation language changes. This prevents translation from corrupting function names, identifiers, APIs, and program behavior.

Generated Python and JavaScript solutions were compiled or executed against tests and hidden edge cases. Mutation testing rejected weak tests that could not distinguish correct solutions from plausible but incorrect ones.

We trained conservatively using assistant-response-only LoRA, evaluated intermediate checkpoints, and compared several merge strengths. The selected checkpoint was merged at 0.45 strength to add the desired tutoring behavior while protecting the parent model's English coding ability.

Only the selected full-precision merge was converted to GGUF. The final Q4_K_M quantization uses an importance matrix containing English code, debugging, Kiswahili explanations, code-switching, tests, JSON, code fences, and strict response contracts.

Challenges we faced

Our hardest challenge was adding Kiswahili without damaging code.

Early language examples sometimes translated public identifiers or changed technically important English terms. Small differences such as renaming add() to kuongeza() make otherwise correct code fail immediately. Locking executable code across parallel language variants solved much of this problem.

Another challenge was balancing specialization against retention. Stronger adapter merges improved some Kiswahili responses but reduced English coding accuracy. We therefore tested multiple checkpoints, merge strengths, chat templates, and quantization controls instead of assuming that the final training checkpoint was automatically the best model.

We also learned that a coding model cannot be evaluated using prose quality alone. Every candidate response must be checked for executable correctness, exact signatures, edge cases, output formatting, throughput, and memory consumption.

What we learned

African-language programming support should not be treated as ordinary translation. Students naturally mix Kiswahili explanations with established English programming vocabulary.

We also learned that bigger models do not automatically make better on-device products. A model must balance accuracy with response speed, memory headroom, reproducibility, and thermal stability on the target laptop.

Most importantly, multilingual model development needs hard retention gates. Improvements in one language should never be accepted without measuring their effect on executable code in the original language.

Performance

The final model was profiled locally through the official ADTC profiler with four CPU cores and no GPU acceleration.

Metric Result
ARC-Easy normalized accuracy 0.82
Generation throughput 4.72 tokens/second
Five-run median throughput 4.67 tokens/second
Peak resident memory 3,369.93 MiB
Performance score, (S_{\mathrm{perf}}) 31.47
Efficiency score, (S_{\mathrm{eff}}) 52.99
Thermal throttling None detected

The final artifact uses approximately 3.29 GiB of peak memory, leaving substantial headroom under the profiler's 7 GiB inference limit.

Our independent coding evaluation also showed improved English executable accuracy and strict response-contract compliance over the untouched base model. Some localized executable tasks still trail the base model, and we publish that limitation rather than hiding it.

Accomplishments

  • Built one offline English–Kiswahili coding model instead of relying on an external translator.
  • Produced 10,000 verified training examples from 662 unique source tasks.
  • Achieved a 90.8% generated mutation-kill rate.
  • Preserved a small 3B CPU-ready footprint.
  • Published the training, evaluation, quantization, and profiling pipeline.
  • Compared the model against the untouched Qwen2.5-Coder base, Qwen3-4B, and Qwen3.5-4B.
  • Created reproducible English, Kiswahili, code-switching, executable-code, and strict-format evaluations.

What's next

Our next training cycle will focus on localized executable regressions using explanation-only language loss and more aggressive identifier-preservation tests. We also plan to expand the verified Kiswahili curriculum, add more JavaScript and debugging tasks, and develop a simple offline classroom interface for students and instructors.

The long-term goal is straightforward: make high-quality programming education available in any african language wherever there is a laptop—even when there is no cloud.

The source code, profiler evidence, and reproducible evaluation pipeline are available on GitHub.

Built With

Share this project:

Updates

Submission history