Depends on the person, I never really had fun telling someone else what I wanted built or drawn. I've always enjoyed the process more than just the results, and having the results without the intellectual activity is boring.
For software, the increase usage of AI code makes my team move much faster, but our software isn't robust anymore and I fear that our longterm mission is being compromised by the endless slop. Favoring quick implementations that AI can make versus good implementations, and lazily relying on AI makes my teammates not develop a deep understanding of the work, which ultimately limits the solutions they can develop. YMMV.
Also, I don't understand what's funny about your image? Is it that it's bad?
It's that I asked for an SVG of a circle and it created a beautiful gradient filled animated technical diagram. I wanted something closer to <svg><circle cx="50" cy="50" r="40"/></svg>
Qwen 3.8 27B on xhigh is a delightfully weird over-achiever.
Here's another fun one: "Generate an SVG of a pelican eating caviar and drinking expensive wine in a tony SF restaurant" - it thought about that for almost an hour! SVG and thinking trace here: https://tools.simonwillison.net/markdown-svg-renderer#url=ht...
Aside from fun with over-engineered SVGs, I'm finding the challenge of getting AI-generated code to be robust, maintainable and better quality than if I'd typed it out myself to be deeply intellectually stimulating.
> I'm finding the challenge of getting AI-generated code to be robust, maintainable and better quality than if I'd typed it out myself to be deeply intellectually stimulating.
Yea that's why I started my comment with "it depends on the person", in response to you asking what's not fun about having AIs do what you tell them. For many, coercing a tool to do something you can likely do yourself better isn't ideal, and at least for me, is just inefficient use of time (in the long run) and a headache. It also zaps the fun out of any task since now you move from searching for a good solution using your priors, to now validating that the LLM has a solution that works, even if it's not optimal. The searching for a good solution is for some, the fun part, which is eliminated by agentic coding, since that search inherently relies on you writing code and seeing what works IMO. The coding is an essential part of the thinking here. An analogy would be doing a math problem by hand versus reading the solution in a textbook. I can give concrete examples if you'd like.
For your SVG examples, I have used AI for a similar use case, the construction of 3D scenes for robotics via a text prompt and an asset catalog. I wish I could get the same richness as your SVG examples, the LLMs fail too hard on all 3D tasks given, even after spending a high amount of engineering effort on a suitable harness + tools. Also like your SVG example, it often doesn't give a realistic, or even nice output, and coercing it to do so, likely takes longer than just creating the image/3D scene yourself.
"Combining them into one heroic speedup would make a better headline and a worse benchmark."
"The machine immediately taught me that capacity estimates are just admission tickets."
"Useful in production, poison in a kernel comparison."
Please don't publish writing like this, it's exhausting to read. You can edit that stuff out.
The best part of this is the "Five xhigh artifacts from the finished model" section at the bottom, I suggest either moving that up or at least prominently promoting it at the top of the article.
It has gotten so much worse over the last month. The default writing style of the Claude 5 model series in Claude Code is some sort of jiberish jargon.
Apparently we've blown way past the Turing test and approaching AGI and yet LLM-generated text still sticks out like a sore thumb. Maybe LLMs aren't that good at writing after all.
I think it's fair to say they're better at a paragraph or so than most humans. And have been for quite some time, which is probably why their use in writing has exploded.
Long form though? Still pretty bad. Probably getting worse in practice, as people have them write larger and larger chunks of text without paying any more attention to the result.
Scaling ChatGPT and scaling GitHub are very different problems.
For LLMs, prompt handling is effectively stateless. They do try to route follow-up prompts to the same cluster to benefit from prompt caching, but those can be effectively sharded. They also need to write results to storage but that's on a per-customer basis, so also easy to shard.
GitHub is a shared space, where commits and issues and PRs need to become instantly available to all readers across all geographies. They have a very different shape of scaling challenge to the LLM vendors.
> GitHub is a shared space, where commits and issues and PRs need to become instantly available to all readers across all geographies. They have a very different shape of scaling challenge to the LLM vendors.
Github data is accessible by all (if open source), but they should be partition-able by individual repository (and their related forks.). Thus while there is more shared state across users, it isn't fully shared state.
And they have been working on this semi-shared state design for over 10 years now.
I don't think "don't overthink" is a useful guide, it's too ambiguous which leads to the model overthinking how to interpret the advice to not overthink.
I think guidelines have to be specific, such as "provide only the specific properties specified, and if other properties are required but are not specified, then ask for clarification or pick the simplest default possible". Even that's ambiguous on "simplest default possible".
I would be more specific in specific domains. The circle example from the article is clear that it defaults to elaborate stylistic choices rather than simple colours and shapes, so the prompt would have to specify "use only simple colours and the simplest possible shape that fulfills the request".
I've been passing "reasoning": { "effort": "none" } to LM Studio's Responses API and the resulting response doesn't include any reasoning chunks, so that seems to work.
It's absolutely not for these models. There are plenty of consumer GPUs out there with 8 or 12GB VRAM - they are comparatively very fast at inference but just aren't big enough to run lots of the models you want. Also context management is a massive pain.
for inference the compute is the last thing we need more of.
memory bandwidth is the numebr one blocker, after that the inefficiencies that where introduced with MoE models (and all new large models are made that way)
You now have me testing it with reasoning turned off, which I have never bothered much with on any other local models because it's rarely worth it.
The result appears to be almost as good as Qwen 3.6 35B A3B on medium thinking mode.
It second-guesses a little, it gives broader/more speculative answers, of course, and it missed the nuance of one of my prompts, but this gives me a lot more confidence that the Low reasoning effort is going to be as good as they say, and perhaps in some cases non-thinking looks like it would be enough.
Hm — brain jumped tracks a bit there at nearly 4am.
I'm talking about budget — I mean limiting it to 2048 tokens.
… for one or other of the models I tested at the same time, in llama-server, there is a dropdown that offered options (unlimited, max, medium which was 2048)
(I've tested so many of these things now that they are beginning to blur.)
I thought that was llama-server with Qwen 35B, just checked and it's not. Nor is it Gemma 4 26B. Perhaps it was Ternary Bonsai which I tested again and deleted earlier.
Anyway I took to clipping Qwen 3.6 35B at 2048 tokens reasoning in LM Studio and elsewhere, and it did OK at that (because it often loops like mad on an ambiguous prompt if not curtailed).
FWIW I just rechecked outputs and I am a bit over-optimistic when I say 3.8 27B 's non-thinking output is that good. I spotted a couple of subtle errors in my tests that Low thinking didn't fail on. It is good, but it is not quite Qwen 3.6 35B thinking level.
It varies widely based on a bunch of factors. With this specific model at 8-bit quantization and MTP, it starts out at about 25 t/s for basic chat, but for agentic tasks with long context it slows way down to something like 12-15. I don't see a big difference in token rates based on any config changes I have tried, or going to the smaller 6-bit quantization, so far, though I haven't spent a ton of time on experimenting.
If you already have one or more of them, then, yeah, you can use them for this model or any other at around this size or smaller, but I wouldn't recommend you buy them (or anything else, right now, everything is just too overpriced). You can run better models for less money at higher speeds. I bought mine before they got more expensive, but I wish I'd just bit the bullet and bought newer/faster cards before they got more overpriced. Or, the actual smart money, even back then was to just use cloud models and forget about self-hosting.
Both applications work correctly and fulfill the requirements. The Qwen one (which used the default xhigh reasoning setting) is massively over-engineered. The Glimmer one used whatever their default in LM Studio is and I would argue is a tiny bit under-engineered.
Weirdly the Glimmer one doesn't work with images on other domains like https://static.inaturalist.org/photos/714731804/large.jpg - it fails with a CORS error, but you don't need CORS to load images and detect their width and height, and the Qwen one handles that URL just fine.
That's because Glimmer added this unnecessary line:
Yesterday I tried both as well. I do a quick "explain this repo" + "any security issues" convo to do a "vibe check" on the models and make sure everything works w/ serving and harness. Both qwen and glimmer explained it pretty well, and both accepted the security question without any issues, flagged a few things left there on purpose (hardcoded tokens, single auth, no logs, etc).
I like the style of glimmer more. Much terser language, no adjectives, no fluffy claude-like language. ("Images are written to...", "Tasks are stored in SQLite...", "Docker image is built from ...")
In contrast, qwen is a bit more flowery. ("Unbounded image processing / resource exhaustion — preprocess() opens whatever was downloaded with no size/dimension/format validation before the VAE encodes it..." , "SQLite as a queue — fine at this scale, but...", "Debug info leakage — exceptions are re-raised as...".
But both flagged pretty much the same stuff, just ordered / styled differently. Mighty impressive understanding for a thing that I can run locally. Qwen served in fp8 w/ full kv cache, glimmer in w4a16 (the fp8 weights wouldn't serve for whatever reason), both at full supported context in 48GB of VRAM.
The other day I asked one of them (running directly on my laptop) to "draw an svg of a circle" and it "thought" for 20 minutes and produced this: https://tools.simonwillison.net/markdown-svg-renderer#url=ht...
I'm still chuckling to myself about that two days later.
reply