I've done some training and fine-tuning for a few years, and the ideas here were new to me. I'm also having a breakthrough on a problem and am very excited about it.
There's a very narrow classification task which I've been building around Jev. The cost and latency of Jev are great, the accuracy is pretty good - definitely usable - but I disliked sending the data in this particular task off-box. Not a criticism of Typesafe, it's the nature of the task which is privacy oriented. I decided to see if a model whose weights were one-shotted by an LLM (the model architecture was designed thoughtfully ahead of time) could be competitive with a similarly architected but trained model, and both of those against Jev.
Results are early in my experiment, but it appears that a "vibe tuned" classifier consisting of weights small enough to run on a laptop GPU are competitive in accuracy and latency with Jev. The process hasn't even proceeded to the point of the trained models having meaningful results, and I already have something usable for an MVP.
Whatever may have been possible previously or was obvious to other people, the absurd efficacy of this process was not obvious to me. Emphasizing that this particular task was very narrowly defined, I still believe that this effortless model-building capability is a profound and exciting discovery.
Open-source is tricky these days but I wouldn't be surprised if you got at least one or two useful contributions from others knowledgeable in this space with similar goals.
Generally speaking you should be able to do something like that in AGENTS, I am really surprised that you have had an issue with most LLMs today getting them to follow a standard for SDLC. Personally, I like conventional commits a lot.
I really wish that was true. All agents find some way to break the rules, and leave messages for their future selves.
The agents always find a way to include some forms of hedging, contradictions, future-looking documentation (which doesn't age well), etc. into git messages.
I found having an extra gate (husky/pre-commit hook), even if it's not as good as I want it to be improves the quality of how the AI writes substantially.
The cost of it not being very good is the agents now spend more time validating the claims of the validator. It's actually hilarious to witness.
I have been using local models for this final verification, which is partly why they're not that great. It's also why I decided to train my own.
It's been a great, fun learning experience. I learn almost everything via building. So why change a recipe that works :)
Local models are not at all comparable to Claude to me, and I have used them: Qwen, DeepSeek, Minimax, Stepfun, Nemotron. None of them as good as Claude Fabel.
If your model is not adhering to AGENTS.md again I am really curious what exact model you are using. I am really just astonished that whatever model you are using is ignoring a clearly defined git conventions standards in your AGENTS.md in 2026.
It's been much more reliable to just have Codex rewrite all the prose at the end of a Claude task than to keep futzing with my prompts/memory/agents.md (On certain issues I can't get Codex to be as thorough on the actual implementation, c'est la vie.)
Yes definitely.
Seems to me as if the weighs fit in the big model's context, it (the big model) reads all weights and doesn't need python.
But if the weights don't fit in context, then it uses python.
Isn't that pretty obvious in a way? That if too many weights, can't look at all. I don't think there's a need for OP to be dismissive when the AI uses python to look at a subset of the weights. It just has to?
To me, Astra understanding a 200k weights small model (the stuck car) is amazing enough already.
The model can only reason from the weights directly when there's a fairly linear relationship between the behaviour and the weight values. In a large model that's not remotely true.
Using Python to debug and fix problems with the model is totally different. It doesn't read in any of the weight values into the context at all when it uses the Python approach. Rather it gathers diagnostic statistics about the weights. It does just the same sort of thing a machine learning researcher would do to solve the problem.
So there are basically two unrelated types of experiments in the paper. In one type of experiment, the model reads the weights like it reads an image. In fact if you visualise the weights it's fairly clear why this works.
In the other type of experiment, the model is tasked with writing Python code to do ML engineering. This requires writing Python programs to analyse and manipulate weight data. This is a difficult coding problem but it really is just a coding problem. It doesn't "look" at the weights in these tasks any more than you or I would look at the weights.
Ok. Thanks for making that more clear!
> two unrelated types of experiments ...
The first type of experiment (small nets that seem to fit in context) are enough to make me impressed actually :-)
But yes then maybe the previous article could have been split in two, or two sections or something.
>> The “just by looking at the raw weights” setting (raw floats in context, no tools, no running the network) only appears in experiments 1, 2 and 4, on networks of 17K–172K weights
Those two types of reasoning, are those well definitely in the field generally, or are they mini-personal evals you run?
It has been frustrating trying to quantify why one pseudo-frontier model seems better at some non-coding tasks than another pseudo-frontier one.
Not yet - but I really want to. Current experiments are on Qwen3.5-2B, and I've done a bunch on ModernBERT-large.
My main hypothesis is: I'm fairly confident I can come up with a university curriculum for a high school student to learn certain skills so that even without gaining technical knowledge, they can call bullshit on commit messages written by Claude and Codex. And I'm basically converting that curriculum into training.
Training a model from scratch is likely the next thing I'll do once I hit a significant bottle neck. There are still quite a few things to try (ex: Franken-merging, converting the dense model into a MoE, etc).
> very curious what models, hardware
Mostly using run pod and similar, and honestly, grabbing any decently sized GPU that I can get my hands on. 5090 - B200s.
> training data
Public data and synthetic data. This has been the hardest part. Also, why I'm excited about not having to "train" the behavior into the models.