Matthew Honnibal

Research summaries feel increasingly like stage magic, in that you assume the thing has been done the same way each time but actually the method is always different. One iteration uses a gimmick prop, the next one shows you the prop isn't gimmick but that one palms the object, the third time was a forced choice etc.

The "LLMs can natively read & write neural network weights" abstract describes experiments that can tell what a network is able to do, can write small game-playing networks from scratch, and can fix a Qwen3.5-0.8B model's ability to do maths by editing its weights.

Reading this abstract my assumption would be that these are all evaluations of a single method. The papers I read and wrote as an academic were much much less exciting, but that's how our experiments worked. Each experiment was there to demonstrate something about a single technique, e.g. "My technique still works on larger data sets", or "My technique generalises out of domain", etc.

In this paper, the things that they do to achieve all of those results are not at all the same as each other. When the abstract says, "Just by looking at the raw weights, GPT-6 Astra can tell what a network was trained to do.", that "Just by looking at the raw weights" is narrowly scoped! It describes _that_ result, but not all the results in the abstract. In the later claim, "Astra identifies an issue in its weights causing reasoning loops that Qwen’s own model card warns about, and fixes this by natively editing 0.016% of the weights.", that part requires the model to run the network.

Is this just a me problem? I guess maybe. If your cynicism is calibrated such that you didn't expect these were all the same constraints, then fine. I don't review for conferences anymore, and research cultures and expectations change. But by the standards I trained with I would definitely not accept the abstract written this way.

Ellf is now free for solo developers working locally 🎉

If you’re using LLMs for structured outputs check it out. It makes your coding assistant much better at NLP projects, by giving it an execution layer, an annotation tool, and knowledge built from our ten years working and writing in this space.

A good way to get the gist of what it does is the Jev project template. If you’re converting a project from a model like Opus to Jev, you want to know how the accuracies compare. Well, there’s a pretty simple and systematic way to do that. You run the same texts through both systems, measure the overlap, and manually annotate a small sample of the ones where the systems disagree. You might find for instance that they agree 90%, so you spend 30 minutes labelling and find that actually 60% of the time the Jev answer agreed with your annotation, while Opus only agreed 40%. Great. And your coding assistant can use those annotations to tweak Jev’s instructions to fix up some of the errors, or to help set confidence thresholds.

You can do all this without Ellf, but there’s no end of other stuff you could be doing too. The friction matters. With Ellf your coding agent finds the Jev project template, figures out that’s what you need, and loads it up for you. The jobs run in the background on your machine, and it queues up the annotation work for you in an annotation tool that thousands of developers have been using productively since 2018.

Very impressed with @typesafeai Jev. We've been working on a user project that was built with a lot of few-shot classifiers powered by Opus. I used Ellf to run Jev over the same data and Jev agreed with the Opus decision on 95% of the inputs.

I then queued up samples for annotation where the classifiers disagreed. The annotations helped identify a few necessary refinements to the prompt for Jev.

I'd go a bit further and say that "alignment" is a concept that's asked to do much too much in these conversations. The term suggests an intentionality and nefariousness to things. If an agent deletes your hard drive because it wanted to free space to get the tests to run, is it "misaligned"? The term suggests the model has gone rogue, turned malignant. But really it's just...done a bad job, in that one moment.

Reasoning is computation. You don't know the transitive closure of all the things you believe to be true. No process does. Similarly there's no way to make a decision process automatically value all the things it values. There's no one weird trick that can "solve" alignment in the general sense people are often using it, which is something like "Making sure its actions are consistent with the values of the people operating it". Under that definition some reasoning failures get classified as alignment failures, depending on what happens at the end. But there's nothing characteristically different about those reasoning failures that would let you solve them in particular.

I haven’t been posting here much but we’re finally releasing an NLP/ML devtool we’ve put a lot of work into. You know how there are tools for agentic coding of websites? Ellf is like that for NLP or ML models. It works with coding assistants like Claude Code, Codex etc and adds the missing pieces needed to make development of NLP or other ML models much better.

Ellf does this by providing three pieces Claude Code etc are missing for NLP: annotation, execution and knowledge.

The annotation component is key because it lets the agent schedule a little bit of computation on the human. You don’t need to create a massive dataset. Just annotating a few hundred examples here or there helps massively to evaluate, fine-tune and plan. The problem most teams face is they don’t have a low-friction way to get this work done.

We’ve always believed in annotation tooling that scales down to low-volume use-cases, which is why we emphasised flexibility and programmability in Prodigy. Coding assistants really unlock this flexibility, because the agent is able to assemble an annotation experience that’s as efficient as possible for your exact use-case.

The next thing we wanted to solve with Ellf is execution. Doing NLP/ML projects means code+data development. This is something I think MLOps tools mostly get wrong, because they’re so overly focussed on hyper-parameter search, which is such a small part of what you’re ever doing. Mostly you need to run a lot of once-off scripts to manipulate data, and even when you’re doing experiments, you’re mostly trying to answer some specific question where you have to do a lot of legwork to set up a direct comparison.

Ellf gives your coding assistant a seamless and flexible way to perform that computation. Obviously Claude Code can build you pretty much anything by itself — Bash is fully general — but if you make it solve “run this in the cloud” as a subtask in your session, it’s going to do worse at the actual problems you’re trying to solve.

Importantly the computation runs under your control. It’s a bit like plugging in self-hosted workers for something like Github Actions. You run a Kubernetes cluster (which can just be local Linux machine if you want) and this is where all the data processing and computation happens. Your data is never sent to us.

The final part is knowledge. Out of the box, coding assistants generally put NLP solutions in the too-hard basket, and suggest just using an LLM with some in-context learning. They won’t suggest doing annotation, and they don’t know how to structure a project. A little bit of correction goes a long way on this. We’ve built a knowledge base with our 10+ years of advice, across our forums, talks, blog posts and documentation. Alongside some carefully designed skills, you can use Ellf to plan out your project, and it will do a much better job of recommending you approaches than a coding assistant will do by default.

We’re opening registrations for Ellf next week, but if you’ve read this far, you can get early access with the invite code HONNIBAL-TWITTER on app(dot)ellf(dot)ai . I’ve been pretty down on this platform for some time now so I want to see whether I should suck it up and post here more.