program-as-weights-github

Define a fuzzy function in plain English. Compile it once into a tiny artifact. Run it on real GitHub issues, offline, on a frozen 0.6B model, at $0 per call.

This is an independent, from-scratch reimplementation of the Program-as-Weights (PAW) mechanism (arXiv:2607.02512), applied to a real substrate: GitHub issues and pull requests.

The paper's authors published an inference-only SDK. The training/compiler code here is reconstructed from the paper. Not affiliated with the authors. See CITATION.cff.

---

The idea in one picture

 "Summarize what this PR changes." <- your English spec
|
compile ONCE (pseudo-compiler + trained mapper hypernetwork)
|
+---------------------------+
| program.pawgh (~a few MB) | <- discrete pseudo-program + LoRA adapter
+---------------------------+
|
run PER INPUT on a frozen Qwen3-0.6B, locally, offline, $0
|
f(issue) -> "Adds retry logic to the upload client."

A fuzzy function is a task you cannot write rules for, only recognize good output ("summarize this diff", "is this a duplicate?"). Today people call a big LLM API per input: slow, metered forever, needs internet, leaks data. PAW calls the big model once per function definition to build a small reusable tool, then a tiny frozen model executes it per input.

Only one small component is trained — a "mapper" hypernetwork that turns a spec into LoRA weights. The interpreter and compiler are frozen. Training fits on a free Colab/Kaggle T4.

Why this is not "just fine-tune a BERT classifier"

You can define a brand-new function from one sentence with no labeled dataset and no new training job, and it runs offline. The functions here are generative / reasoning / transformation (free-form output), not fixed-label classification — an encoder cannot do them. Five specs are held out from training entirely, to test compile-from-spec generalization.

What we claim (and what we do not)

• We claim: the mechanism works — paw > discrete_only > small_raw — and it is useful: it retains a meaningful fraction of big-API quality at $0/call, offline.
• We do not claim to beat frontier APIs. We do not.
• Eval avoids circularity: labels come from one model (teacher), judging from a different model, plus a hand-checked sample.

Repo layout

src/pawgh/
config.py model ids, LoRA/mapper shapes, paths
data.py pull real issues/PRs via `gh` -> data/records.jsonl
tasks.py ~25 generative/reasoning specs + teacher labels (Ollama) -> triples.jsonl
pseudo.py spec -> discrete pseudo-program (Ollama), cached
mapper.py THE trained part: hidden states -> alpha -> LoRA from shared bases
interpreter.py frozen Qwen3-0.6B + externally-fed LoRA injection
train.py train the mapper (frozen interp+compiler)
package.py write/read .pawgh artifacts + offline runner
eval.py systems x metrics, seen vs held-out
viz.py cost bar, build story, meaning map
notebooks/ 01_train_colab.ipynb, 02_eval.ipynb (thin T4 drivers)
app/demo.py Gradio: type a spec -> compile -> run on a real issue, offline

Quickstart

Local (CPU) prep — needs gh authenticated and a local Ollama with a teacher model:

pip install -e ".[dev]"
pawgh data # P0: pull GitHub issues/PRs -> data/records.jsonl
pawgh triples # P1: teacher labels (Ollama) -> data/triples.jsonl
pawgh pseudo # P2: pseudo-programs (Ollama) -> data/pseudo/
pytest -q # P3: shape + overfit-one sanity (downloads Qwen3-0.6B once)

Train on a free T4 (notebooks/01_train_colab.ipynb): zip data/, upload, run. Then:

pawgh eval checkpoints/mapper_seen.pt # P6: benchmark -> results.md / results.json
python app/demo.py --ckpt checkpoints/mapper_seen.pt # P7: live compile-and-run demo

Attribution

Program-as-Weights: Zhang, Hotsko, Kim, Nie, Shieber, Deng, arXiv:2607.02512 (2026). Independent reimplementation for educational/demonstration purposes.