Shacharp

I kicked them back for failing my tests. I’m the SDET.

The AI slop code is so good that I’m kicking back more Jira tickets than ever for failing my tests.

I for one welcome my fellow software engineers into my realm: Welcome to becoming an SDET. AI is an extension of test automation. Just don't let it get to decide what is valid and what isn't. That's your job now.

I’ve already given up. HN has its own AI or something that flags me. I guess I’m not saying the right things?

So long as the wrapper is an instance of itself there’s no reason it wouldn’t work.

Would be even better if an epistemic framework were available for the model to follow. We don’t expect our language centers to do executive function. An arbitrarily long chain of thought isn’t gonna make the model suddenly have grounding.

> the reasons behind architectural choices

Should go into a historical document, not a durable record of decisions for an AI to follow unless those reasons are themselves decisions for it to act on.

Read through the paper a few more times. There are limits to the published methods:

1. Requires fine-tuning every 10M tokens ingested.

2. Requires complicated multi model pipelines. One for distilling the context, one for making a training dataset, and one for applying it.

3. All of this requires a lot of compute. Note the lack of wall times in the paper. While they do note that their process is considerably faster than SFT they never really quantify it.

4. They only published results on Llama and Qwen, and on fairly small versions to boot.

Despite all of that, the paper is a starting point for a process of making a model that can modify its own weights. I very much suspect that Google has solved many of the problems given the breadth of the related work and additional experiments sections in the appendix.

It will be really fun to see open weight models come out in the future with the functionality described in the paper.

I love that they tested it on Qwen 3. I’m curious if they’ve experimented with putting the new parameters onto system RAM or even an SSD. Big bummer they didn’t publish that part.

The "do not guess" sentence works but the last 20% will only close when a system stops being told to avoid guessing and actually knows what it does not know.

A command can get you most of the way. It takes something else for the rest.

This is a really really smart SVP. The answer to “how do we prevent this in the future” is to identify decisions that reduce that problem from happening again. This doesn’t have to be perfect. You can say “we are going to do X next time” and also say “but we don’t know how far X will work”. When the failure happens again, you can retire process X and move on to Y. The aim is to make a series of decisions that eventually get to the heart of the issue.

Everything else is a conversation that takes up space on a post-mortem or runbook.