
By the end of this material, you should be able to:
When you teach an LLM a new programming language through fine-tuning, what exactly does it learn?
There are three candidates:
| Component | What It Means |
|---|---|
| Syntax | The grammar rules of the language (brackets, keywords, structure) |
| Algorithm Selection | Choosing the right problem-solving approach (e.g., use dynamic programming vs. recursion) |
| Implementation Fidelity | Correctly translating a chosen algorithm into working, bug-free code |
If you fine-tune a model on Python, you cannot separate:
Analogy: Imagine testing whether a cooking class improved someone's skills, but they already cooked professionally before the class. You cannot isolate the class's contribution.
The researchers created PyLang — a completely novel programming language that:
Python output = Pretraining knowledge + Fine-tuning knowledge
PyLang output = Fine-tuning knowledge ONLY
↑
(model never saw PyLang before)
Therefore:
Fine-tuning contribution = PyLang output
Pretraining contribution = Python output − PyLang output
This is a controlled subtraction experiment — elegant in its simplicity.
In-distribution problems are similar to the training examples — same problem types, similar complexity.
2,250 PyLang examples are sufficient to completely match Python performance on in-distribution problems.
For familiar problem types, fine-tuning successfully teaches:
The gap closes entirely — meaning fine-tuning is highly efficient when problems resemble training data.
Analogy: If you learn to drive in an automatic car, switching to a manual car on the same familiar roads is manageable with modest practice.
Problems that are different from training examples — novel problem types, higher complexity, unseen combinations.
A persistent ~19 percentage point gap remains between Python and PyLang performance on out-of-distribution problems.
The researchers tried every reasonable technique:
| Intervention | What It Does |
|---|---|
| Infilling | Train model to fill in missing code sections |
| Multi-token prediction | Predict multiple future tokens simultaneously |
| LLM-JEPA | Joint embedding predictive architecture |
| Plan-then-code training | Explicitly plan algorithm before writing code |
| Easy-only data | Train only on simpler examples |
| Restricted Python prompting | Limit Python to PyLang-like constructs |
None of them worked.
The gap is not caused by:
The gap must be caused by something more fundamental — which leads to Finding #3.
An independent LLM evaluated whether models used the same algorithm when solving the same problem in Python vs. PyLang.
For 64–75% of problems, models produced fundamentally different algorithms in PyLang vs. Python. Cross-language algorithmic agreement was as low as 25–33%.
Same Problem → Python → Algorithm A (e.g., dynamic programming)
Same Problem → PyLang → Algorithm B (e.g., brute force recursion)
This happens the majority of the time.
The model's algorithm selection is entangled with language familiarity:
Analogy: A chef who knows a complex French recipe might simplify it when cooking in an unfamiliar kitchen with unknown tools — not because they forgot the recipe, but because they're uncertain about execution.
The researchers examined the model's internal representations — the mathematical vectors that encode how the model "thinks" about a problem.
Finding A: PyLang requires more restructuring
Finding B: Both models converge to the same problem understanding
Problem Understanding → SAME in both languages ✓
Algorithm Selection → DIFFERENT 64-75% of time ✗
Code Execution → DIFFERENT quality ✗
The bottleneck is not comprehension — it is execution.
Implementation fidelity = the ability to translate a correct, known algorithm into bug-free, working code in a specific language
Level 1: SYNTAX → Fine-tuning teaches this well ✓
Level 2: ALGORITHMS → Partially transferred, but language-dependent ⚠️
Level 3: IMPLEMENTATION → This is the bottleneck ✗
FIDELITY
Implementation fidelity requires:
With only 2,250 examples of a new language, the model learns the shape of the language but not the deep fluency needed for reliable execution.
┌─────────────────────────────────────────────────────────┐
│ CODE GENERATION │
├─────────────────┬───────────────────┬───────────────────┤
│ SYNTAX │ ALGORITHM │ IMPLEMENTATION │
│ │ SELECTION │ FIDELITY │
├─────────────────┼───────────────────┼───────────────────┤
│ Fine-tuning │ Partially │ Primary │
│ handles this │ language-tied │ bottleneck │
│ well │ │ │
├─────────────────┼───────────────────┼───────────────────┤
│ Closes gap │ Causes 64-75% │ Causes persistent │
│ in-distribution │ algorithm │ ~19pp OOD gap │
│ │ divergence │ │
└─────────────────┴───────────────────┴───────────────────┘
Fine-tuning is efficient for familiar problems — 2,250 examples can match extensive pretraining on in-distribution tasks
Algorithm selection is not language-independent — models choose different algorithms based on what they can implement, not just what is optimal
Understanding ≠ Execution — models can understand a problem identically across languages but execute solutions very differently
Implementation fidelity is the frontier — future research should focus on teaching models how to execute known algorithms reliably, not just which algorithm to choose
Post-training efficiently teaches syntax and enables in-distribution performance, but the persistent out-of-distribution gap reveals that the true bottleneck is implementation fidelity — the deep, language-specific fluency needed to translate correct algorithms into bug-free code — which 2,250 examples and seven training interventions all fail to provide.