ekidd

For things where I really care about code quality, I still prefer to write about half the code, including almost the architectural bits, by hand. The models are allowed to pick holes. They're surprisingly good at that.

Interesting. My experience is that Opus 5.5 is smarter than a model like Qwen3.8 Flash Next. But given the choice, I'd actually rather work with a model like Qwen3.8 Flash Next.

Even on medium reasoning, modern Qwen and DeepSeek models are ridiculously diligent. If I ask them a question about which library is best for a given task, they'll download 4 different candidates, read the source, and write test programs. Meanwhile Opus will look at a couple of web pages and give me glib bullshit answer. Opus is often like a brilliant coworker who can't be bothered to do their job. The modern Qwen and DeepSeek models are like someone who is merely smart, but who has an alarmingly good work ethic.

And I'm not just writing simple React CRUD GUIs. I'm doing stuff like modernizing ancient software forks, working on high throughput distributed systems, or finding bugs in other people's parser generators. And even the 120-240B open weight models are normally entirely adequate for these tasks.

One of the benchmarks where open models tend to perform badly is Terminal-Bench 4.0. I looked at some of the sample tasks on that benchmark, and some of they are really hard and specialized. Look, all I actually need out of a model is things like "tell me where this distributed algorithm might break", "get this ancient C code to build on modern Debian with modern dependencies", or "write a plan to migrate this database from MySQL to PostgreSQL and to test that the app still works." The modern open models can do all that, no problem.

The reality of running recent Chinese open weight models is that they are all overtuned for successfully completing tasks. I can ask Qwen3.8 Flash Next to grep for regexes that use PHP-specific features that might be problematic to port to Rust. But instead of just grepping, Qwen3.8 FN will spend 30,000 tokens writing a Rust test harness, exhaustively check every regex, consult a bunch of docs, and write me a 2 page report. Q3.8 FN is deeply convinced that it's going to get extra credit for doing more than it is asked. (To be fair, it's a prototype release.)

But if your sandboxing isn't set up to handle some whacky weirdness, then you can't even trust Claude or ChatGPT. Which is important—the big vendors often do provide sandboxing or command filtering in their harnesses, but some popular local harnesses like Pi.dev are intended to rely on external sandboxing tools.

Yes, this exposes some root-level kernel features to ordinary users in a restricted way, and yes, those features sometimes have security bugs that aren't visible to users outside a namespace.

But nothing that model was described as doing seemed particularly sketchy? At least not from the information we were given? It was using a normal kernel operation that I used regularly, not trying find a kernel exploit?

So that part of the article left a bad taste in my mouth.

DeepSeek V4 Flash 0731 is dirt cheap at scale, less than 10% of the cost of Qwen3.8 27B. This is because it's an MoE and it uses much less VRAM for KV cache. And it's generally a better model. V4.1 is also cheap at scale, though I've heard mixed reports on the optimized K/V caching.

You should not be running Qwen3.8 27B on an API normally. Maybe Cerberas's hardware is bad at batching or supporting more efficient K/V caching schemes, or something like that?

There are reasons why Google pays this price! But I think it's one of the worst practices for much smaller organizations to adopt.

Haven't burnt out a single bulb yet.

I understand that this has caused some challenges for the Philips Hue division. They had extremely satisfied customers but not many repeat buys.

I wonder if Nvidia is also trying to cover themselves against a market crash the bankrupts the AI labs but leaves the tech standing? (Similar to the dotcom crash or the big railroad crash back in the day.) If Anthropic and OpenAI struggle, Nvidia can always sell local inference hardware. But local inference hardware often has a lower utilization, so you need more GPUs for the same number of tokens.

Sam Altman says a lot of things, most of which seem to benefit Sam Altman. And Google used to tell me that they wouldn't be evil. Facebook probably said some noble-sounding nonsense at some point, too.

> Why do you deserve to be paid higher wages when it can be done easily and better by something else?

I mean, this is exactly what happened to the Neanderthals: We could do every job better than they could, and now there are no more Neanderthals. So I wouldn't like a future where two companies make machines that outcompete humans at every job.

Which is why I say we can adapt to this, but only if it stops advancing soon.

But more importantly, sure, we were always paid for results. And yes, sometimes professions transform or die. The buggy whip manufacturers aren't doing that great these days. But people are also allowed to have feelings about losing their professions.

My real concern is that the stated goal of the AI companies is to do this to every human job. They want to replace programmers and artists and movie-makers and—as soon as they get robotics figured out—physical laborers. They measure the ability of their models to run entire retail businesses with Vending Bench, so management isn't safe, either. They sell their AIs to the military for use in weapons. No job is safe, anywhere: They want everything, if they can figure out how to take it.

If the current rate of AI advance stops really soon, then eventually we'll figure out some kind of liveable future. Probably one with fewer programmers. But the labs have zero intention of stopping. Anthropic is a cult, and they hope to build a machine god that will have power over humanity forever. So I'm not going to them for answers. OpenAI used to have non-profit oversight that encouraged them to serve society, and Sam Altman gutted it like a fish. So I don't think I trust them to design a machine that replaces all human jobs, either.

Personally, I don't mind current coding models, at least not the local-sized ones that exist now. They make nice sounding-boards and can be trusted with the grunt work. We could adapt to these, given time.

But so far, AI technology shows no sign of stopping. And the labs are focused heavily on coding and math, because the next step in their plan is to let their models do AI research so that they can advance their technology even faster into new fields.

We could, like, decide that we don't need to do this. There is no need to try to replace every single human job with a superhuman machine. Because if you thought the enshittification of the Internet was bad, wait until you see the enshittification of a machine that can do almost every human job. No thanks.

With llama-server, you can use basically any GGUF model as a Jev-like classifier. See Pi.dev's codemode and the accompanying llama backend to the "classify" function. The advantages of Jev-like inference are that:

- You generate 1 token per question in parallel, instead of sequentially generating a bunch of JSON punctuation. So you get much better latency and utilization.

- You can use a custom "sampler" that sees the raw logprobs for these tokens, including all the tokens that might have been generated. So you can generate some "probability" or "confidence" numbers based on how likely the model was to have generated a different answer.

So really, no difference? It's just a nice API with some computational efficiencies.

Unfortunately, Qwen3.6 35B A3B isn't really a useful coding model. You'd probably want Qwen3.8 27B at a minimum, which requires at least 32GB of VRAM (not system RAM) to run semi-comfortably.

So this isn't going to be a competitive model for hobbyists, and you'd have to be a bit desperate to use it for coding. But if you work in a regulated industry and don't mind paying for a bit of extra hardware, it isn't catastrophically bad, either. Probably would work fine for information extraction or as a "classifier" like Jev. (Almost any GGUF model can be turned into a classifier using llama-server. See pi.dev codemode for sample code.)

So they're not a real contender yet, but they look like they're probably at least minimally credible.