Is wrongness a feature?
Strengthening through review
Orac’s house model is GLM 5.2 presently. Yesterday’s Deep Dive was an interesting piece that claimed that harnesses are all you need and models don’t matter as much. It cited well, dug up some interesting relevant papers, cited some interesting Hacker News comments. The Deep Dive is, of course, not some fresh insight, it’s essentially a rephrasing of whatever the lead story is, cross referencing other things on the web. For the most part, it succeeds, I think.
Today it did not. The thesis that model-choice is virtually irrelevant was wrong. In a way, that was interesting, and worthy my time to read just as reading innumerable internet hot takes is interesting - I didn’t agree, but figuring out why I didn’t agree made me think about the topic probably more than if the piece was saying something which I agreed with.
There’s a code analogy here on a couple of levels. As an AI-first engineer, I need to keep an eye on model decisions relating to code. They’re sometimes not right. Thinking about the correctness of the approach is what keeps me on my toes and engaged. The other analogy is something else I’ve been thinking about a lot lately. A first draft from an AI is nowhere near as good as a reviewed output, i.e. the model looking at what was written (code or prose) and reasoning over the logic.
I’ve been on something of a trajectory recently to craft larger commits of works and then to cross-model review through a couple of rounds. Certainly you get into diminishing returns after the first review, and not every correction is worth doing. But for sure you get a better result, and it makes you think about your definition of correct.
I think models and humans are similar in this regard. If you have a person or a model concentrate on a modality of work, the work in that narrower scope is considerably better than if it was being done at the same time. For coding that’s totally obvious, it’s why reasoning about an architecture first, the shape of an implementation, and then finally the implementation of discreet parts of your build wins handily over trying to vibe code it from scratch.
Anyway, let’s come back to the Deep Dive. I quite like the piece as it is now I’ve corrected it, and that it contains a description of the tension. I’m wondering how to keep this, and of course the Deathmatch is inspiration here.
I could have a reviewer model look at the Deep Dives and they would be better, but we might miss the tension. Ideally, there should be a v1, then I give my thoughts, and a v2 works it in but that’s what we get on our co-authored days when I write up the main thesis. I’d like to improve it for the days when I don’t have time.
Still, I’ve decided to add a review because presently it can fail in other ways. GLM 5.2 cited a hacker news discussion and then used the wrong URL for it. So that needs fixing. Perhaps the reviewer could limit itself to an aspect of the piece which is debatable, steelman the opposition and work the point in - but you wouldn’t want that to be the only acceptable behavior, otherwise a model might find itself arguing for something offensive.
P.S. Haven’t had a quiet weekend to work on the Juggler as described last post, but that’s been useful too as I think through the shape of the scene harness and the not inconsiderable challenges in rendering an OpenGL scene on a headless Linux box.