Any org large enough to have separated the people responsible for the security exposure of the organisation from the developers with familiarity of what's deployed is likely to have done exactly this.
The thing you have to remember is that CVEs can be a) scanned for without exerting mental effort, and b) counted.
With their current API approach they're essentially a commodity. They need to start moving parts of the harness behind the API, otherwise they'll remain a commodity.
Recursive self-improvement changes the parameters a bit, especially for the market-leaders, and it's the one thing that makes me wonder if they'll be able to extend their lead faster than the smaller labs can keep up, but it's an option available to everyone.
It's good but (at least on openrouter) it's got an annoyingly tight output token limit. So if it does get stuck in a reasoning pit, it won't work its way out of it in time.
For me it's more an expression of how much mileage you can get out of "glorified", how many tasks devolve down to "if you model language accurately enough, look what drops out" because it turns out that to model language you need to model how the world works. I don't use it to minimise the capabilities at all.
> ...a hypothetical type of artificial intelligence that matches or surpasses human capabilities across virtually all cognitive tasks.
You can argue that paperclip maximising is an inevitable consequence of that (and the huggingface breach is interesting from that point of view) but it's not fundamental to the definition.
The question then is what "surpasses human capabilities" means and we're there in some niches but not all, and not across many models.
I've just grabbed myself a Nape Pro trackball. It's really quite neat. ZMK firmware (which was actually the main thing I wanted) and a configurable positioning angle. I'm still getting used to it but so far it looks like a decent addition to my wireless toolkit.
I would prefer a bigger trackball as a daily driver, but it's an interesting device otherwise. It feels like they could reasonably do a mini version, too, just by chopping the non-main buttons in half. Definitely going to crack it open and see what the innards look like.
Control vectors for the win? It feels like the way to fix this is to pull out a control vector immediately after processing the handbook and use that to steer later inference. That should stop the drift over long distances, but it doesn't guard against the handbook itself being too big.
CSG on meshes isn't really where FreeCAD struggles or focuses. That's more BRep, which is a harder problem than CSG.
Blender used to struggle with boolean operations, though. Seems to have got much better some time in the last couple of years, but without knowing any of the backstory I don't know if they've bodged it into shape or would benefit from something proven.
When did you try it? I got a bit confused by your comment because there's no obvious reason why the accelerometers in an android phone would have a problem reporting forward/backward acceleration any less accurately than lateral. So I installed it and the 'Dots' mode definitely responds to acceleration normal to the screen, but that mode is marked as 'New' so might not have been present when you last looked.
The very first time I came across the term, it was used to refer to something so small that you'd comfortably rewrite it rather than fix it if it was wrong.
It's not just the modular organisation that you've got to get right though, although that's definitely a big thing. Deployment independence matters too: if I've got a perfectly modular monolith but I have to coordinate with everyone else who lives in that monolith to get my module into production, it's leaving half the gains on the table.
One team owning many services is fine, as long as they can deploy them independently of any other team. Less critical (but still useful) is being able to deploy their own services independently of each other.
This isn't mimicking what a human would do, because it is an exceedingly rare human who would write their own renderer for a task needing a CAD file generating. The human who is capable of doing both is rare, let alone the human who can do it in any sort of reasonable time. Saying "but it's in the training data" is a cop-out: it's in Google too, would I do it? No. I would not.
The whole point is that if you don't maintain high quality, any software will degrade to the point where the factory breaks. "Human-quality" here isn't quite the right measure because human software factories also bog down in exactly this way.
I got usable token rates (10-20tps from memory, so marginal) with the Qwen A10B a while back, well before all the new speculative speedups landed in llama.cpp. There's an unmerged branch which allegedly supports this, but I don't know how well yet. Looks worth investigating but I might give it a few days to see what bugs get shaken loose.
That is the context switch I'm referring to. It's worth the reviewer suffering a 15 minute (say) flow state loss to avoid the multiple hours the ticket would otherwise have been waiting to be picked up.
For us, review latency was obviously a problem so we eliminated it (for most tickets, anyway) by making the handover synchronous. Get on a call with the reviewer when it goes into the review column. The win from eliminating review latency massively outweighs the context switch cost for the reviewer. All the more so when the patch is small enough to actually read through on the call, so if there is anything immediate to address you can ping-pong it without anything waiting.
Yeah, it's only a chat template change. So if you don't fancy re-downloading the whole model and can just hack the new chat template into your process, it's a lightweight test to do.
Worth knowing that Unsloth have just put out another Gemma 4 release from Google's upstream updates which should improve reliability. Bugs in the chat template affecting tool calling and other issues, apparently. https://www.reddit.com/r/unsloth/s/MpC6Hzs4Wj