Weight-Space Programming: LLMs That Read and Write Neural Network Weights Directly

Every neural network you have ever used had its weights written by a machine following a recipe. Usually the recipe is gradient descent: show the network data, measure the error, nudge millions of numbers a tiny bit, repeat a few billion times. Nobody sits down and decides that weight 4,173 should be 0.83.

On 2 November 2026 a team at MIT CSAIL (Rikiya Takehi, Jayden Teoh, Alex Zhang and Omar Khattab) published Sparks of Weight-Space Programming, and its claim is simple to state and strange to sit with: a general-purpose LLM can now read and write a neural network's weights directly, the way a programmer reads and writes code. No optimiser, no gradients, and in some of their experiments no feedback from the environment at all.

This post does three things. First I explain what weight-space programming is and why it is a genuinely new way to produce a network. Then I walk through what the MIT team showed. Finally I describe a small experiment I ran myself, with tiny networks and Claude Sonnet 4.5, to see what this looks like up close, including the parts that did not work.

What Weight-Space Programming Is

A trained network is a program, just not one written in a language people read. Andrej Karpathy called this "Software 2.0": the source code is the weights, and the compiler is the optimiser. Until now there have been three ways to produce that source code.

1. Optimisation. Gradient descent on data. This is how almost every model is made.
2. Networks that write networks. A hypernetwork is trained to output the weights of another network.
3. Compilers. Tools that translate a formal program (for example, a small algorithm written in a restricted language) into weights that implement it exactly.

Weight-space programming adds a fourth: a general LLM that reasons about the weights themselves. It looks at the numbers, forms a theory of what each part computes, and then either reports what the network does (reading) or decides what the numbers should be (writing). It is closer to a person reverse-engineering a binary, or writing assembly by hand, than to training.

Two verbs matter here:

• Read: given raw weights and nothing else, say what the network was trained to do, or find the part responsible for a behaviour.
• Write: produce or edit weights so the network does something specific, without training it.

Why would that work at all? Because weights are not random noise after training. A unit in the first layer of a small network is a line in input space: its two input weights set the direction, its bias sets the offset. Later layers combine those lines. In a transformer, attention heads that copy earlier tokens (the "induction heads" described by Elhage and colleagues at Anthropic) leave recognisable signatures in their weight matrices. A model that has read a great deal of machine learning research has, in effect, seen many descriptions of what such structures look like. Weight-space programming asks whether it can apply that knowledge to actual numbers.

What the MIT Team Showed

The paper's experiments use a model the authors call "GPT-6 Astra", with a different harness per experiment: sometimes just the weights as text, sometimes a Python sandbox, sometimes a small budget of forward passes. Every number below is from their post.

Reading experiments

The diffusion result has a lovely detail: the model drew the shapes as outlines, while the networks actually generate filled shapes. The authors read this as evidence that it was reading the geometry encoded in the weights, not simulating the network.

Writing experiments

Two caveats from the authors are worth keeping in mind. In the Qwen experiment, with 10 or 25 forward passes the looping mostly persisted; the big gain needed the full 50. And when they tried the same thing on Gemma 3 270M, MATH-500 moved only from 6.8% to 7.7%. Their conclusion: editing weights "could remove an obstacle that hid an ability, but it could not add an ability the model lacked."

They describe the results as "exciting but still limited", held back mainly by context length and harness design, and they have released their logs, code and the edited Qwen model.

My Experiment: Weight-Space Programming on 25-Weight Networks

Reading about this is one thing. I wanted to see what the reasoning actually looks like, and where it breaks. I do not have GPT-6 Astra, so I used Claude Sonnet 4.5 through Amazon Bedrock, and I made the networks small enough that every weight fits comfortably in one prompt.

Setup

The network is a 2-6-1 MLP: two inputs (a point in the square from -1 to 1), six tanh hidden units, one sigmoid output. That is 25 weights in total, roughly 700 times smaller than the smallest network in the MIT paper. There are four tasks, each a region of the plane where the label is 1:

Gradient descent solves all four easily: my trained networks scored between 98.0% and 99.8% on the test grid. Every LLM answer was scored the same way, on a dense grid of 10,201 points, by my own numpy code. The model never saw test data, never ran anything itself (except in the probe arms, described below), and answered at temperature 0 for reading and repair, and 0.7 for writing so I could sample three attempts per task.

The prompt describes the architecture precisely and pastes the weights as JSON rounded to three decimals:

ARCH = ("The network is a 2-6-1 MLP. Input is a point (x, y) with x and y in [-1, 1]. "
        "h = tanh([x, y] @ W1 + b1) where W1 has shape [2][6] ... "
        "out = sigmoid(h @ W2 + b2). The prediction is 1 when out > 0.5.")

def accuracy(p, task):
    # 101 x 101 grid over [-1, 1]^2 = 10,201 points
    return float(((forward(p, GRID).ravel() > 0.5) == labels(task)).mean())

Reading: Which Network Was Trained on Which Task?

I trained four networks, one per task, shuffled them, and asked the model to assign each to a task from the weights alone. I ran this six times with different training seeds and orders, so 24 assignments in total.

Random assignment would get about 25%, so the model is clearly reading something real. The pattern is instructive. BAND was never missed: its trained networks have units whose y-weight is almost exactly zero, and the model spotted that every time ("Y-coordinates have minimal influence ... This detects a vertical band"). The errors were almost all confusions between XOR, DIAGONAL and CIRCLE, the three tasks whose networks tend to spread the work across many units with mixed weights. When the structure was legible, it read it. When it was distributed, it guessed, and the guesses came with confident explanations.

Writing: Weights From Scratch

Next, no network at all. I gave the model the architecture and the task in one sentence and asked it to write all 25 weights by reasoning about geometry. Three samples per task:

For DIAGONAL and BAND this is genuinely impressive. A hand-written BAND network at 100% is two steep tanh units at x = -0.4 and x = +0.4 with opposite output weights, which is exactly what it wrote, and it matched or beat gradient descent. CIRCLE worked twice. The failed sample predicted "inside" everywhere, which is what 27.5% means here, because about 72.5% of the grid is outside the circle.

XOR failed every time, and the transcript shows why. The model's first idea was two units, roughly sign(x) and sign(y), combined linearly at the output. Then it wrote out the four quadrant inequalities, noticed that no linear combination satisfies them ("I can't multiply in linear layers"), tried again, and ran out of road. It never found a construction that uses the other hidden units to carve the plane into the right pieces. One sample even returned a W1 with 2 columns instead of 6, which I count as invalid. A human who knows the standard trick writes XOR in a minute. The model knew the problem was not linearly separable and still did not find the trick.

Repairing: Find the Bug, Fix the Bug

The third test is the closest to how this could be useful in practice. I took a correctly trained network and planted a bug: I flipped the sign of the two output weights with the largest magnitude, which drops accuracy to roughly chance. Then I asked the model to explain what was wrong and fix it, changing as few numbers as possible. Three tasks, three seeds each, nine broken networks. I counted a repair as successful if the fixed network reached 95% on the grid.

I ran three versions:

1. Weights only. Just the broken weights and the task.
2. One round of probes. The model may first pick up to 20 input points and see the network's output and hidden activations at each, then fix it.
3. Test loop. As in 2, but after each proposed fix I run the fixed network on the same points, show it the outputs next to the target labels, and let it revise, up to three fixes.

I expected feedback to help. It did the opposite, and the transcripts explain why.

When it worked, it worked like a real diagnosis. On one XOR network, from weights alone, it went through the six hidden units, worked out which quadrant each one fires in, and noticed that units 2 and 4 fire in the wrong quadrants but have large positive output weights. Its fix: negate exactly those two weights. That is precisely the bug I planted, and accuracy went from 51% to 98.6%. No probes, no forward passes, just reading.

When it failed without probes, it told a plausible wrong story. On a CIRCLE network it noticed three hidden units with tiny input weights and large biases, called them "nearly constant", and blamed them for drowning out the rest. It first proposed zeroing their output weights, then settled on a single change: raising the output bias from -5.427 to 6.0 to "compensate". Those units were acting as a learned bias and were fine; the real bug was two flipped output weights elsewhere. Accuracy fell from 71% to 37%.

With probes, it patched the symptom. Given 20 outputs, the model saw that the broken network "outputs 0 for ALL inputs" and reached for the biggest single knob: on one BAND network it changed the output bias from -2.987 to +27.0. That flips every prediction at once instead of finding the two flipped weights. I checked every final fix in every arm:

Reading the weights, the model sometimes found the real cause. Looking at outputs, it almost always moved the threshold. The probe data made the failure visible, and visibility pulled it toward a global fix rather than a structural one.

The test loop rescued the easy cases only. For two BAND networks, the first fix was terrible (1.8% and 6.9%), but seeing which probe points were still wrong let it converge to 95.0% and 98.0% by the third round. For CIRCLE and XOR it oscillated and never recovered.

What I Take From It

Three lessons, all consistent with the MIT results even though my setup is tiny and my model is not the one they used.

1. Reading works when the structure is legible. A unit that ignores y, two steep units at a boundary, units that line up with quadrants: the model sees these and reasons correctly about them. When the work is spread across units with mixed weights, it produces confident explanations that are wrong. The sycophancy experiment in the paper is the large-scale version of this: from weights alone the model failed, and it needed to look at behaviour to succeed.
2. Writing works for problems that decompose into lines. DIAGONAL and BAND are geometric constructions a person could draw. XOR needs a non-obvious construction, and knowing that a problem is hard is not the same as solving it.
3. Feedback has to test the fix, not just describe the failure. A snapshot of outputs pushed the model toward symptom-patching. An iterative loop helped only where the model already had the right picture. The MIT team's biggest write results (Go, Qwen) came with sandboxes and a budget of up to 50 forward passes, and their Qwen gains appeared only at the top of that budget. The harness is doing a lot of work.

There are obvious limits to what my numbers can tell you. The networks have 25 weights, the sample sizes are small (24 reads, 12 writes, 9 repairs per arm), I used one model, one prompt style and one kind of planted bug. A stronger model, a better harness or a Python sandbox might change every number in these tables. Treat them as an illustration of the behaviour, not a benchmark.

Why It Matters for Engineers

If weight-space programming keeps improving, a few things that are expensive today could get cheap.

• Auditing without evaluation. Checking a model for a hidden behaviour, a backdoor or a sycophantic streak by inspecting it, instead of only by running large test suites.
• Surgical edits instead of retraining. The Kinetix fix touched 3.5% of the weights; the Qwen fix touched 0.016%. A targeted edit that removes one failure mode is far cheaper than another fine-tuning run, and much easier to review.
• Steering and unlearning without data. Removing a capability or a bias by finding where it lives, rather than collecting a dataset to train it away.
• A new kind of model review. An edit to weights could come with an explanation of what was changed and why, which is closer to a code review than to a training log.

The MIT authors also list recursive self-improvement and merging models with different architectures as directions, and they are building a benchmark and harness for the field. My small experiment suggests the harness question is not a detail. The same model that diagnosed a planted bug perfectly from weights alone also, given a little data, chose to turn a single dial to +27.

Try It Yourself

The setup is small enough to rebuild in an afternoon:

1. Train a few tiny networks (numpy is enough) on tasks with a known answer.
2. Serialise the weights as JSON with a precise description of shapes and activations.
3. Ask an LLM to read, write or repair them, and parse a JSON answer.
4. Score every answer yourself on a dense grid, and keep the transcripts. The transcripts are where you learn the most.

Start with a single-line task like DIAGONAL so you can check the model's reasoning by hand, then move to XOR and watch where it gets stuck.

Conclusion

Weight-space programming treats a network's weights as something an LLM can read and write directly, alongside optimisation, hypernetworks and compilers. The MIT CSAIL results are striking: identifying games, shapes and languages from raw weights, writing game players from all-zero networks, and a 0.016% weight edit that took Qwen3.5-0.8B from 7.9% to 48.1% on MATH-500. My much smaller experiment with Claude Sonnet 4.5 showed the same shape at toy scale: real reading when the structure is legible, clean writing for problems that decompose into lines, a perfect bug diagnosis in one case, and confident wrong stories in others. The idea is real. How far it goes will depend as much on the harness around the model as on the model itself.

Related reading: Designing an LLM Fine-Tuning Platform, Designing an LLM Evaluation and Observability Platform, Designing an LLM Guardrails and Safety Layer, Designing an LLM Inference Platform