I've had a very similar experience optimising a hidden markov model prediction tool I work on. I wanted to experiment with an alternative architecture and data structures. Opus 4.7 did the refactor, and eventually the only hot spot became the maths kernel. Over the course of an hour or two it iteratively rewrote that code using all the usual optimisations to improve branching, cache usage, vectorisation, etc. It reviewed the disassembly and the hardware counters with perf to verify that the changes were working as intended. It could have taken me several days to cover that much ground doing low level optimisations - and I would have spent most of it grappling with gcc, perf, searching for information about particular SIMD instructions, etc.
How do you know that? What information do you have that would explain your position? We are talking about a specific circumstance and you have brought unsupported generalities to the discussion.
> For context: GLM 5.1 ran the same task and reached 7.3x. Kimi K2.6 reached 5x. DeepSeek V4 Pro reached 3.3x. The models that stopped early did so because they issued no tool calls for five consecutive rounds, they concluded they couldn’t make further progress and stopped. Qwen3.7-Max didn’t stop.
By this reasoning I could release a model that lacks all the basic optimisations. Have it optimise itself for hours to reach 20x the throughput and then claim that the model is superior to the others?
I am not saying that is what happened here, but the reporting is abysmal.
It is not the model's job to stop or continue, it's the agent. Qwen has nothing to do with it.
Right now now I switched to the latest cloudcode agent (in Rust), and it would perform much better according to his qualifications. Much better async IO implementation and orchestration, no more deadlocks as in the typical typescript tooling. It just doesnt stop out the blue, as claude, kimi or opencode.
Obligatory: Either written by AI or by a human who has spent so much time with AI that they adopted its writing style. Anyways.
> Over 35 hours it performed 432 kernel evaluations. Each cycle meant writing code, compiling it, running it, reading the profiling output, deciding what to change, and trying again. The model diagnosed compilation failures it hadn’t seen before, identified performance bottlenecks through runtime feedback rather than prior knowledge, and redesigned the kernel architecture multiple times when incremental improvements stopped working.
Anyone remember genetic algorithms? This might be an improvement, but it still feels a little like deja vu.
Yeah, I remember. I still have Usenet postings about the genetic algorims conference back in the '90s and some magazine clippings about researcher from the University of Sussex where I first learned about genetic algorithms back in high school.
Technically birdshot from a shotgun is also randomly distributed (passing through a cone). This actually improves the chance of hitting the clay pigeon, because the birdshot spreads out and each individual ball has a chance to hit.
Genetic algo is similar. it's an optimizer that - in order to avoid local optimae - will 'shotgun' an area around its current best guess.
This article was generated from the original Qwen3.7-Max release blogpost and contains nothing new https://qwen.ai/blog?id=qwen3.7
LLM written.
See the authors twitter, he speaks english at a rather basic level and certainly did not write this https://x.com/mohitgeryani/with_replies
https://xcancel.com/mohitgeryani/with_replies
Also I'm pretty sure the original source was linked here on HN before.
I've had a very similar experience optimising a hidden markov model prediction tool I work on. I wanted to experiment with an alternative architecture and data structures. Opus 4.7 did the refactor, and eventually the only hot spot became the maths kernel. Over the course of an hour or two it iteratively rewrote that code using all the usual optimisations to improve branching, cache usage, vectorisation, etc. It reviewed the disassembly and the hardware counters with perf to verify that the changes were working as intended. It could have taken me several days to cover that much ground doing low level optimisations - and I would have spent most of it grappling with gcc, perf, searching for information about particular SIMD instructions, etc.
I don't doubt that it did it but I wouldn't want to maintain whatever it ended up spewing after 35 hrs.
In my experience, AI fixes problems by mostly adding more code.
It's a short term gain for a long term hurt.
In my experience, AI fixes problems by mostly adding more code.
In my experience, humans unfortunately tend to do the same.
Some do, but we should not be level-setting at mediocrity.
The LLM's had to learn that from somewhere :p
How do you know that? What information do you have that would explain your position? We are talking about a specific circumstance and you have brought unsupported generalities to the discussion.
Don´t give up on native agents, best logic will prevail. The open weights will show the real deal.
so basically just brute force the kernel.
there are more elegant ways to leverage an LLM, see AlphaEvolve: https://arxiv.org/abs/2506.13131
it's difficult to frame most coding tasks in such a way where you can trivially verify correctness.
[flagged]
At this point the models should just start improving themselves.
Rumor is that anthropic writes all their code with Claude. So it kind of is.
what a nonsense, generated, article.
> For context: GLM 5.1 ran the same task and reached 7.3x. Kimi K2.6 reached 5x. DeepSeek V4 Pro reached 3.3x. The models that stopped early did so because they issued no tool calls for five consecutive rounds, they concluded they couldn’t make further progress and stopped. Qwen3.7-Max didn’t stop.
By this reasoning I could release a model that lacks all the basic optimisations. Have it optimise itself for hours to reach 20x the throughput and then claim that the model is superior to the others?
I am not saying that is what happened here, but the reporting is abysmal.
It is not the model's job to stop or continue, it's the agent. Qwen has nothing to do with it.
Right now now I switched to the latest cloudcode agent (in Rust), and it would perform much better according to his qualifications. Much better async IO implementation and orchestration, no more deadlocks as in the typical typescript tooling. It just doesnt stop out the blue, as claude, kimi or opencode.
It optimized the Extend Attention operator in triton. All models were optimizing the same operator
They didn't optimize their own kernels and optimize their own runtime, which I think is what you are implying.
Obligatory: Either written by AI or by a human who has spent so much time with AI that they adopted its writing style. Anyways.
> Over 35 hours it performed 432 kernel evaluations. Each cycle meant writing code, compiling it, running it, reading the profiling output, deciding what to change, and trying again. The model diagnosed compilation failures it hadn’t seen before, identified performance bottlenecks through runtime feedback rather than prior knowledge, and redesigned the kernel architecture multiple times when incremental improvements stopped working.
Anyone remember genetic algorithms? This might be an improvement, but it still feels a little like deja vu.
Yeah, I remember. I still have Usenet postings about the genetic algorims conference back in the '90s and some magazine clippings about researcher from the University of Sussex where I first learned about genetic algorithms back in high school.
Genetic algorithm is random. This is intelligent evolution. Big difference.
I got nerd-sniped wrt the genetic algorithm.
Technically birdshot from a shotgun is also randomly distributed (passing through a cone). This actually improves the chance of hitting the clay pigeon, because the birdshot spreads out and each individual ball has a chance to hit.
Genetic algo is similar. it's an optimizer that - in order to avoid local optimae - will 'shotgun' an area around its current best guess.
Both are non-deterministic, both have some metric to optimise, one is specific and efficient, the other is too broad and very expensive
Temperature is the rephrasing of randomness. No difference, just much better matchers.
Key word is non-differentiable optimization. That's what generic algorithms were traditionally good at.
So a LLM wrote 432 kernel variations and it found what was the faster...