Training Your Forge: Customizing Coding Models to Your Internal Style Guide

A coding assistant that writes syntactically correct code and a coding assistant that writes code your team wants to merge are not the same product. The gap between them is style in the broadest sense: naming conventions, error-handling idioms, which abstractions the codebase prefers and which it has deliberately moved away from, how tests are structured, what a docstring is supposed to contain. A generic model trained on the open internet has opinions about all of these things, and those opinions are frequently not your organization's. Closing that gap is the practical work of making a coding assistant useful day to day, and it is also, for teams that cannot send proprietary source to a cloud provider, work that has to happen entirely inside the boundary. That is what customizing a Forge deployment to an internal style guide means: not a cosmetic preference layer, but an adaptation of the model's actual behavior to the codebase it is going to work inside.

Style guides are the easy 20 percent

An internal style guide document (indentation rules, naming schemes, approved libraries) is usually the smallest part of what "our style" actually means, and also the most legible. It is text a model can be given directly as instruction, and Forge's retrieval layer can surface the relevant section of a style guide alongside a request the same way it surfaces relevant source files, so a rule about naming test fixtures gets pulled into context precisely when the model is generating a test. That mechanism works well and is worth using, but it only covers what your organization has bothered to write down. Most of what makes code look like it belongs in a given repository was never written down at all. It exists only as thousands of examples of the pattern being followed. A model that has only read the style guide will get the documented 20 percent right and default back to generic conventions for everything else.

The remaining 80 percent is architectural taste: which error type gets raised in which situation, whether a given codebase prefers composition over inheritance in practice regardless of what any document says, how deeply nested a conditional is allowed to get before someone insists on a guard clause. These are patterns a model has to learn from seeing the codebase itself, at volume, not from being told about them once in a prompt.

Two mechanisms, not one

Forge draws on two distinct mechanisms to close that gap, and it matters to keep them conceptually separate because they solve different problems and fail differently when misapplied.

Retrieval-grounded context is the first and does the most work for the least cost. Every request Forge handles is enriched with material pulled from the repository's own index: nearby files, related symbols, and, if it has been ingested, the style guide itself. This is how a model that has never been retrained on your code can still produce a suggestion that matches the file it's editing: it is looking at neighboring code in the same request and pattern-matching against it directly. Retrieval is fast to set up, updates automatically as the repository changes, and requires no training run at all. Its limit is that it only shapes a single response at a time. It does not change what the model prefers by default when relevant context happens to be thin or absent.

Fine-tuning is the second mechanism, and it is where deeper, more durable adaptation happens. Rather than shaping one response through context, a fine-tuning pass adjusts the model's own weights against examples drawn from the organization's codebase and its history of accepted, reviewed changes, the corpus of code that has already passed your team's actual bar, not code in general. That process changes the model's baseline behavior, so the adapted preferences hold even on a request where retrieval didn't happen to surface a perfect matching example. This is qualitatively different from prompting: it is training, and on Forge it is training that happens on the appliance itself, or on a paired Czar system provisioned for that workload, so the source material never leaves the sealed environment it came from.

What actually goes into the adaptation

The material that makes a fine-tuning pass useful is exactly the material an organization is least willing to hand to an outside vendor, which is part of why this work has to happen on sealed infrastructure in the first place. The codebase itself is the primary input, not a sample or a sanitized subset, but the real repository history, including the pattern of what got proposed, what got sent back in review, and what eventually merged. That reviewed-and-merged signal is more valuable than raw source alone, because it encodes judgment, not just syntax: it shows the model which of two equally valid implementations your team actually prefers.

Review history and comments, where an organization chooses to include them, add a second layer: the explicit reasoning behind a preference, which can generalize further than the code change alone. A comment explaining why a particular retry pattern was rejected teaches the model something a diff by itself cannot. Documented standards, including the style guide and any architecture decision records, round out the input set, giving the model the explicit rules to weigh against the implicit ones it infers from examples.

None of this is exotic data. It is the organization's own engineering history, already sitting in its version control system and its review tooling. The work is connecting it to a training pipeline that respects the same boundary the rest of the appliance respects. Nothing in that corpus is more sensitive leaving the training process than it was sitting in the repository, because it never goes anywhere.

Judging whether it worked

The honest test of a style-adapted model is not a benchmark score; it is whether engineers stop editing the model's output to match house style before merging it. That is a qualitative, team-specific bar, and it moves over time as a codebase's own conventions evolve, which is the argument for treating this as a periodic pass rather than a one-time setup step. A team might reasonably choose to re-run adaptation on a cadence tied to major conventions shifts (a new error-handling pattern adopted org-wide, a significant refactor) rather than on a fixed calendar schedule, since the material that matters is "how much has house style actually moved," not time elapsed.

It is worth being explicit about what improves and what does not. Style adaptation changes idiom, how code is expressed, not correctness. A model fine-tuned on your reviewed history will produce code that looks like it came from your team; it does not become more capable at reasoning about a genuinely novel problem simply because it has seen more of your existing patterns. Teams evaluating results should separate "does this look like our code" from "is this the right code" as two different questions, because conflating them is the most common way a style adaptation effort gets over- or under-credited.

Where this sits in the deployment

Style adaptation is something a Forge deployment does with an organization's own history, not something Element 31 does on its behalf against a shared or external corpus. The training material stays inside the boundary the appliance was purchased to establish, whether the adaptation runs on Forge directly for lighter passes or on a connected Czar system when the workload calls for dedicated training capacity. The two products are complementary here, not overlapping: Forge is where the adapted model is used day to day, Czar is where the heavier training work that produces it can run when a team needs more than incremental retrieval-based tuning. Either way, nothing about making a coding assistant sound like your team requires anyone outside your team to read the code that taught it.