There's plenty of evidence of China's ability to translate research into practical engineering. Just go look at who's leading in stuff like robotics, solar, and EV tech right now. In fact, China is beating the US across the board in critical technologies. https://itif.org/publications/2025/09/23/how-china-is-outper...
Personally, I don't really care what OpenAI does here. What's going to be far more exciting is when DeepSeek, Qwen, or GLM start integrating classifiers into their open models.
I'm not sure it makes as much sense to use the same bigger models for the things Jev does. Part of what makes Jev appealing is the cost/speed. I can definitely see them putting out S1 spins of their smaller models.
That's not what I meant. I'm thinking more of AI systems that combine multiple modules the same way the brain has different regions. LLMs are just part of the bigger picture here. They're good at tackling a certain types of problems, but other approaches are better for different kinds of problems. Having a system that combines a generative model and a classifier for example would make it a lot more efficient and accurate because it has a bigger toolbox instead of using one algorithm for every problem whether it fits or not.
There are plenty of other use cases aside from agentic coding. However, even here a classifier has a lot of obvious benefits. There are plenty of scenarios where a model has to make a choice, and programming/system tool use happen to be deterministic sets of choices that can be evaluated.
> programming/system tool use happen to be deterministic sets of choices
I'm not following. There are way more tools in the world, and likely available on every machine, than can fit in any model context. One can create a small list, but that will be very org dependent. Programming is very open ended, I struggle to see the 'deterministic set of choices' here.
I'm looking at Jev/Kev like models for some control over tool calling and similar, but I also think that fine-tuning out behaviors (like qwen 3.8 wanting to use rkt all the time) may be better in the long run. Instead of having to check/change every tool call, we can refine the main LLM to have high enough likelihood of using the tools we actually have, that we won't need to check every call.
Jev is definitely useful, but also being held like a hammer in search of a nail right now, approaching OpenClaw like fanfare and hype levels. No one talks much about OpenClaw these days, I would not be surprised if Jev has a similar trajectory.
I'm not talking about checking/changing every tool call, I don't even know what you mean by that to be honest. The question is about selecting the tool to use in a particular scenario.
The whole point of Jev/Kev is efficiency. If you can make decisions faster, cheaper, and more reliably that's the benefit. Even within the model architecture itself, you could use a classifier as a router within MoE to pick the expert that's likely to give the best outcome.
Exactly, the future is open models. Which is also the reason why those overvalued companies such as OpenAI will lead to a market crash as soon as investors realize that.
Classifiers can be very useful for guiding the agentic loop which is basically a state machine. You have the agent propose a task, write some tests, write code, run tests, tests fail, write more code, go to acceptance, etc. So, a classifier can judge state transitions and decide what the agent should do next for example.
both things can be true. China's gearing up, but they also try to make progress by aggressively distilling Anthropic and OpenAI models, and this is currently where most of their progress comes from.
People really need to stop parroting this line uncritically. The process takes time because even when you're distilling answers, you still need to actually do reinforcement training on the model. And given that Fable and GPT 5.6 just came out there simply hasn't been much time to do that. However, models like Kimi also do better than Fable or GPT on a lot of tasks, which means it's not just distillation but also difference in architecture. You can watch this talk from Kimi founder to see how Kimi was actually trained and why it performs well. https://www.youtube.com/watch?v=5CkCW1P-g88
It's also absolutely hilarious that people think only Chinese companies use distillation, as if Anthropic or OpenAI are above that or something. Not to mention that they basically ignored copyrights on all the data the siphoned and are now crying that people aren't respecting their terms of use.
Chinese labs have come up with a bunch of genuine innovations: GRPO, auxiliary loss free MoE load balancing, MLA, muon optimizer, and a bunch of other ones. The Deepseek papers are really well written, this isn’t just sneaking a peek at a peer. Anybody who thinks China is simply distilling glorious American models is not engaging with reality.
For sure, everybody distills when they can, it would be stupid not to. I'm just pointing out that Chinese companies clearly do their own research and innovation just like American companies do. It's not that they just wait for American models to drop and then distill them.
I would argue that learning a high level language like Clojure is most productive now that LLMs exist. I'm going to make a bold prediction that imperative programming is effectively dead now. LLMs are very good at writing the implementation details, dealing with syntax quirks, and the boilerplate.
What you still have to understand are high level concepts like which algorithm is appropriate to use for a particular problem, or which data structure is a good fit for the data. How to organize your logic at scale and how data flows through the system. These are the kinds of things you need to be able to do to evaluate whether a solution an LLM came up with is sound or not.
So, you still need to learn and practice writing code to develop the intuition for these things, but you don't really need to worry about the nitty gritty of it. And a language like Clojure is a perfect fit here.
I looked into that very briefly about a decade or so ago: it would be very difficult to get it done and maintained in practice. XMPP leans towards the "dumb server/smart client" side of the trade-off, while Telegram is the exact opposite: while an XMPP client establishes and maintains a session and its state, retrieves a list of discussions, for each, requests and processes new messages, and infers reas markers and counts (a bit like a traditional mail client like thunderbird), Telegram maintains the session and the client state on the server and the client is a thin layer to just display it.
Precisely, which isn't much, and on top of that, you would have those modified as well to map to XMPP concepts and specifics. That said, I do believe that XMPP deserves a beautiful Qt client. There is Kaidan (QtQuick), but it's very opinionated (practically incompatible with groupchats and preferring a mobile UI paradigm)
reply