This is exciting. I decided to add a whole YouTube search/download system to my FrankenWhisper project to make it quick and easy for agents to put together a set of really polished transcripts for a list of YT videos or an actual YT playlist. I figured I could just do a clean-room, memory-safe port to Rust of yt-dlp, but I underestimated how complex it is to deal with YouTube's anti-bot measures. The hardest part is that you need to run some very complex, very obfuscated JS to reliably make it all work. Which normally would throw a big monkey wrench into my goal of making a clean, self-contained, memory-safe Rust project, because then you have to bring in browsers and all this other nonsense, you have to grapple with FFI stuff that makes unsafe unavoidable, etc. A real buzz kill. But it just so happens that I've been working for months on FrankenEngine, my from-scratch JS engine designed specifically for handling adversarial extension workloads in AI agent harnesses. If we could use that for this purpose, it would totally solve the problem. Now, this is particularly exciting for me because I still haven't actually tried to USE FrankenEngine for anything yet, despite investing many, many billions of tokens to create millions of lines of Rust and 100k tests. To give a sense of the effort so far, FrankenEngine now has 5,273 commits despite being started just 4 months ago: github.com/Dicklesworthstone… Anyway, if I can get this all to work, not only will it be a very useful tool in general, but it will be a truly demanding existence proof that FrankenEngine really does work and can handle real-world, complex applications in practice. Which, if true, would really be quite incredible if you think about it. The teams that have been assembled by Google to create its V8 JS engine, or by Apple to make its JavaScriptCore engine, are extensive and include some of the smartest, most highly paid engineers at either company. And they've been at it for 10 years already. And btw, FrankenEngine doesn't exist in isolation; it has a sister project, FrankenNode, which is my agent-centric replacement for Node/Bun (and this time, the Rust engineering is actually done properly, without all the unsafe and UB!). See github.com/Dicklesworthstone… for details on that one. Anyway, the next week or so will be very interesting and exciting for me. Since this will be the first real-world use case for FrankenEngine, it will likely reveal some problems that were missed despite its insane collection of over 100,000 tests, but I should be able to quickly triage and fix all of them. If you want to follow along, here's the repo for FrankenWhisper: github.com/Dicklesworthstone…

Today we are saying goodbye to Windsurf …and we are transforming it to Devin Desktop Windsurf has been an absolutely amazing experience for me and the team. Though it has been rocky at times, we have seen every phase of AI coding and we want to keep embracing where things are going. That means we need to once again reorient ourselves towards a more focused goal and remove the Windsurf branding. Believe it or not, the Windsurf brand has been around less than a year and a half, and before that, the previous name Codeium was only around a similar timeframe as well. I’ve actually had to change my email every year all the way to the eventual acquisition to Cognition. In AI, most products only have a 1 year lifespan before you need to drastically change it to the next. Devin now encompasses all our form factors, whether it’s the cloud agent, the agent command center (with IDE), CLI, review, or our other products. This way we can really focus our efforts around one name. We are doubling down on our neutrality and making Devin Desktop compatible with other agents via ACP. We may be the only “Switzerland” of AI left and we embrace this role. As for me, I’ll be transitioning from CEO of Windsurf to Cognition’s President of New Enterprise, helping open new regions and verticals, accelerating velocity, and filling in gaps as usual. The story of Windsurf doesn’t end here, it continues on as part of Devin’s journey.

Things you get out of the box by adding a registry.json to a GitHub repo: - Discovery: Use list, search, and view to explore registries. - No backend: No server, package publish or install script. Your source code is the source code. - Source ownership: Code lands in your project as editable source. - Bundling: Group files, routes, scripts, configs, docs, dependencies, and metadata into one installable item. - Cross-registry composition: Compose items from multiple registries with registryDependencies. Extend and Override. - Local code adaptation: The CLI reads the target project and adapts imports, aliases, paths, deps...etc - Framework-aware code: install code cross framework even when source registry framework differ. - Release pinning: Install from branches, tags, or commit SHAs. - Update-ready workflow: Use --dry-run, --diff, and --view to inspect upstream changes. - Manifest for agents: registry.json tells agents what exists, what files belong to each item, where they go, what they depend on, and how to install, compose, and update them. Ship the implementation.