Every AI editor learns from your code. The only question is who keeps the model.
The standard arrangement is one-directional: your prompts, your diffs, and your accept/reject decisions flow up to a vendor, improve a model you’ll never own, and come back to you as a subscription price. Your judgment — the thousands of small “yes, that edit” and “no, not like that” calls you make in a week — is the most valuable training signal in the loop, and you’re giving it away to rent its output back.
Forge is Yee’s answer to that arrangement, and the data story fits in one sentence, quoted straight from the product:
“Every code edit you approve in Easy mode is captured on this machine as training data — full weight, de-duplicated, and removable per repo. The Forge is where that data trains a real coder model, locally: no cloud, no rented GPU.”
How the loop works
You code in Yee the way you already do: the agent proposes edits, you approve or reject them. That’s it — that’s the data collection. Each approved edit is a supervised example of exactly the kind researchers pay annotation farms for, except better: it’s your codebase, your conventions, your bar for “good enough to ship,” captured at the moment you enforced it.
Forge — a companion training dashboard that runs as a local sidecar and opens full-screen inside the editor — takes that corpus and runs supervised fine-tuning (SFT) on an open-source coder model, on your Apple-silicon hardware, using MLX. The result is a model that has read every edit you ever approved and none you rejected. It lives in a folder you own.
Three properties of the corpus are worth calling out, because each is a deliberate choice:
- Full weight. Approved edits are stored complete — the before, the after, the context — not as telemetry-grade fragments.
- De-duplicated. Approving the same shape of fix fifty times doesn’t overweight it into the model’s personality.
- Removable per repo. Client work you can’t train on gets excluded the same way it stays private everywhere else in Yee: by never leaving the boundary you drew.
And when the training stack isn’t installed — say, on a tester’s build without the local server or MLX — Forge doesn’t fake it. It shows an honest offline panel that says the tools aren’t present and still explains what the door is for. No mock dashboards, for the same reason we deleted our own marketing numbers.
Why local training is the point, not a feature
You could imagine a cloud version of this: upload your approved edits, we fine-tune on rented GPUs, you download the weights. It would be faster. It would also delete the reason to do it at all.
Yee’s entire architecture is that your code, your conversations, and your keys stay on your machine — it’s bring-your-own-key with no proxy in the middle. A training pipeline that ships your accumulated engineering judgment to someone else’s datacenter would be the largest possible exception to that rule, attached to the most sensitive dataset the editor ever produces. Your approved-edits corpus is a distillation of how you build software. It’s exactly the thing a consultancy, a fintech, or a founder with a head start cannot leak.
So the constraint is the product: if it can’t train on your hardware, it doesn’t train.
Where this goes
The honest version of the roadmap (the only version we allow ourselves): today the capture pipeline farms Easy-mode approvals, and Forge trains a real local coder from them. The ceiling — a model that’s effectively you, on your best day, at machine speed — gets closer every session you code, because every session is more curriculum.
Vendors are racing to learn from everyone’s code at once. We think there’s a more interesting race: a model that learns from exactly one engineer, perfectly. In that race, you’re not the data source. You’re the finish line — and the owner of everything the training produced.