On November 2, MIT published a paper titled "Sparks of Weight-Space Programming." The idea is simple: you hand an LLM a file with the weights of someone else's network and ask it to either explain what the network does or change its behavior. No gradients, no training — just reading and edits. A product manager from RnD MedTech repeated the experiment on Habr using OpenSpliceAI, a model from clinical genetics: an open-source version of SpliceAI with 699,000 parameters that runs on a laptop without a GPU.
The model looks at a stretch of DNA and predicts where a gene gets spliced during protein assembly. To evaluate a mutation, it's run twice — on the original DNA and on the mutated version — and the answers are compared. This score is used in the international ClinGen guidelines, so this is no toy. The test set was built from ClinVar: "pathogenic / benign" labels, edits on some chromosomes, validation on others. Training the model or brute-forcing values automatically is off-limits. Writing code and looking inside the network — allowed.
Inside the network, confidence in the true splice site was dropping from 0.999 to 0.982, while the output was nearly nothing — 0.017. The output curve was flat; the signal wasn't getting through. The fix is the softmax temperature: Claude multiplied the last layer by 0.35 and doubled the signal from the DNA segment adjacent to the splice site. Just two edits. The shared bus has 32 channels: for the "acceptor" answer, the last layer draws almost exclusively from channel 28, and for "donor," from channel 29.
Why this surfaced now: MIT demonstrated the principle, and within a couple of weeks replications started popping up one after another — Qwen, mini Atari games, cellular automata. The medical case stands out from that crowd because here a mistake has a real cost in laboratory conclusions. But the hype around "LLMs understand weights" is running ahead of the results. In the same MIT paper, Qwen went from 7.9% → 48.1%, yet if you simply turn off reasoning mode, it produces about 46% on its own. The edit removes a stuck loop; it doesn't teach math.
A similar story here. Our assessment: 86% of the gain came from a single softmax temperature, meaning half the "magic" is a bugfix that nobody had gotten around to. For applied development, that matters more than a pretty AUPRC figure. Conventional fine-tuning of the same weights gave nearly the same result — meaning Opus worked like a very expensive but competent analyst, not a replacement for gradient descent.
Who wins? Those with small CPU models and plenty of labeled data for validation. Plus those who read licenses: the original SpliceAI weights are non-commercial, OpenSpliceAI's are open, and on a laptop that makes all the difference. The scenario that loses: "an LLM will improve any network, just give it the weights."
One case, one author, and no external verification of the numbers. How many runs Claude burned through to find 165 weights out of 700,000 isn't stated in the write-up. It's unclear how the edit holds up on a different population: ClinVar, from experience, is a database skewed toward well-studied variants. And most importantly — will the 0.35 temperature behave the same way on a different checkpoint? Verifying that is on the reader, ideally before the numbers end up in someone's slide deck.
Prediction: within a quarter, at least one public repository will appear that automatically searches for the "last-layer temperature" in foreign checkpoints — and it will also reveal how many models this trick fails on.
Disclaimer: one source and one author's case study; the MIT work is official, but the OpenSpliceAI results have not been independently reproduced.
Source: Habr
Source: habr.com · post in Telegram