For me in my day job, having extremely fast low quality decision makers over noisy inputs is very valuable. I work in security and having something that can help triage alerts, classify items and group things together is extremely valuable. It doesn't need to be perfect. Just being able to take a set of inputs from deterministic tooling and to be make general priority classifications goes a long way on helping humans look at the most important items first.

This seems like a technology heading in the right direction but not quiet there yet. Excited for what they are cooking up but probably won't start building around it yet.

Did I miss something? I thought one of the demo videos was it doing pretty decent at the first level of Doom?

I see this on here a lot on this site, but Rust hasn't been that in over a decade. Rust's devotion to post 1.0 stability is massive and has involved some interesting design choices. I started writing run in 2015(?) and only hit one breaking change in the language. It was a niche bug in a macro that was fixed later in a later release.

Just watching hackernews you see lots of news about it, but these are additive and not breaking things. I was still writing lots of mio-style async code after async await was out. You don't have to adapt new style or libraries. I used to have a joke that you could tell a codebase's age based on the error handling libraries used, but even with that it was additive. Often multiple would exist in different parts of the same code base. "Oh wow, I've gone deep on this refactor.... I'm starting to see error_chain"

I think some of these are excited, eager users always ready to hype up the new thing. The same crowd that previously would constantly push for a rewrite from angular->react->svelt->god knows what. Instead now it is on a 6 week cycle and about models/harnesses.

I think most of it is bot driven spam by the various labs. It's hard not to notice 3 month old accounts with very strong opinions about various frontier labs and little else.

Ultimately, I think some of it is legitimate shifts in who's in lead and what is the best. You gotta dig through a lot of crap to get to that, and I don't really know how to to.

Ultimately I'm saying is that I always applied a fair amount of skepticism about what I see in comment sections but these day it is extreme amounts.

https://risky.biz/RBFEATURES27/

I don't think you can put this on Zed. An unprivileged userspace application, even if coded poorly, shouldn't crash the machine.

1. https://simonwillison.net/2025/Nov/13/training-for-pelicans-...

The speed in which a copier can catch up to a leader is faster than every before, but everything is faster these days. I think the threat is if can these labs catch up and pass American labs while keeping costs low, but I don't see that happening.

> These crates sit on the path that renders untrusted model output (diagram source → SVG). Vendoring gives a full audit surface, pins exact source, and avoids crates.io yanks. Local patches and upgrade checklists live in each crate’s Cargo.toml header comments — treat those as the source of truth when re-vendoring.

Which honestly feels like a misunderstanding of how cargo and yanks work. Each upstream package is locked to an exact version in your lockfile along with a cryptographic hash. The upstream can't change the source without you noticing. Unless you update your lockfile you will always pin to the exact version and source. When a package is yanked, it is still available for download if it is already in a lockfile. It just prevents new packages from resolving it. Crates.io will sometimes completely delete a package, but I've only seen that happen in cases of malware. It's fairly rare and seems out of line with the supply chain concerns here.

There are good arguments for relying on upstream package managers and there are good arguments for vendoring all packages. I've never seen a project mix before.

There are still research firms who are actively and aggressively scanning new packages once they are pushed. For example socket.dev pulls new packages across ecosystems and performs automated analysis and runs it in a sandbox. We don't have to have them go boom in someone's production repos to find out there is a problem.