Yeah I'm actually less hesitant to try out Google open source projects than I am new Google products. I have no idea if this is accurate or just my impression, but I feel like I've been burned by the "killed by Google" meme almost exclusively on their software products, whereas there are plenty of open source efforts from Google that I think of as stable.

In addition to the ones you listed, I'd add the V8 runtime, Jax, Protobuf. Even some of their projects that wound up declining in market share (Angular, Tensorflow--both losing share to projects that wound up at Meta, ironically) are still actively maintained and pushed.

But I'm sure there's also a huge graveyard of open source projects they abandoned that just never hit my radar. Still, at least with their open source stuff, you can fork in the worst case.

I think this is basically the motivation behind MCP servers, so you're in good company.

But I've spoken with many people at companies who've decided to add an in-UI agent to their apps, and I don't think this trend will persist. Absolutely AI/agents will increasingly become a major component of interfaces, but the current common incarnation of "Clippy for X" feels like a kludged bridge between an app that was not designed from first principles for agents (and often was poorly designed for humans) and the impulse to be "AI native".

From my experience, some of the most successful niches for this sort of UI so far have been in apps that were already well suited to it. I'm thinking specifically about analytics/dashboarding/"this is a portal for you to query things easily" software. They already started with a lot of the elements you want: visible provenance of the agents actions via the queries it writes, a malleable interface that you already expect to be customizable and ephemeral, and most importantly, "navigation" that is genuinely difficult for many users (in the sense that "navigating" can mean "querying specific data"). The agent provides a ton of value to users and its actions are intuitive and legible.

But the agents you see right now in a lot of apps that do things like navigate you to the right page by... sending you a link, which you could have clicked from the navbar? Or worse, which hijack your navigation and throw you on a page you're unfamiliar with, and where you have no sense of place or how to make your way to/from? I don't think they're particularly long for this world.

IMO it's a fundamental tension. AI does not fit well inside a product. It works best outside of it. But that means the product - not its functionality, but the business around it - becomes irrelevant. Which none of the product vendors want.

Also the motivation behind CLIs and SDKs, right? And the way agents write Python regularly, these days, I am hopeful what can be offloaded to deterministic systems will be.

Jev seems pretty cool! I just got access and have only gotten to do minimal experiments, but I love this general area of research and it fills a very real need.

I agree with you. I think the OPs pushback is emblematic of a larger reaction I've seen that is, at the very least, misinformed.

There are a lot of approaches that use a self-attention backbone for classifier-style outputs. You have structured generation libraries like SGLang and Outlines, but those basically give you guided generation on an autoregressive model. You also have a bunch of models that are non-autoregressive that try something similar. Older NLP stuff applies here, and there's newer stuff using diffusion transformers for this purpose.

But I don't think the Jev author has ever said that he's the sole human, alone in a vast sea of misguided researchers, who is interested in schema-guided classification? I think he said he found a novel way to train a model for this task that has much higher general intelligence at much lower cost than other approaches. Which is an exciting result with lots of applications if it bears out.

I think some people are just reflexively skeptical of anything that gets a lot of hype. Maybe that's fair. Things that are wildly successful and high impact also tend to get a lot of hype though, so it seems like a poor filter.

This is also a really common thing in ML specifically. We joke about getting Schmidthuber'd, which is when Jurgen Schmidthuber (sometimes correctly) announces that he or one of his colleagues actually proposed your thing 37 years ago in a Japanese linguists journal.

Statistical modeling, from simple classical stuff up to modern deep learning, just has this dynamic where the theory is rich and bottomless, but the actual components of implementation are pretty neat and compact. So for any given idea, there are probably 20,000 other people who have had the same intuition, just with subtly different application or implementation. Add in that depending on what your particular flavor of research is, you might name an almost identical implementation something completely different. And it leads to a huge amount of sour grapes whenever anyone's idea really garners attention.

If you listen to any podcast with a founder in the ML space who has been in it for long enough, they will invariably say at some point "We actually developed xyz over a year before OpenAI"

Schmidhuber rarely ever executed the idea correctly, which makes his claims particularly obnoxious.

I understand the distinction you're drawing, but in my experience, it gets a lot blurrier as a project evolves. Caveat that I use LLMs all day and have for quite some time, so I'm coming from a positive perspective.

The danger for me in LLM code is the same as in writing, it's just that I'm not typically writing at the same scale as when I'm building something. The final piece when I'm writing is usually a message or a 1,000 word article at most. So I'm naturally going to analyze it quite intensely, because I can afford to. And I don't really use LLMs for this at all. I use them for things around writing (research, interrogating ideas, situationally specific stuff, mapping, visuals, publishing, etc.) And the code equivalent to an essay or message would probably be something like a single script, or the sort of thing I'd write as example code when I'm teaching. In those settings, again, LLMs can be helpful, but I'm still going to be really opinionated at a highly detailed resolution.

But a codebase is more comparable to a novel than an essay. Or more directly, the writing in a codebase is usually the documentation, which grows commensurately with the codebase. And the real LLM risk here is the drift that can happen over the course of many epics or "chapters" as the LLM writes "code that works but is imprecise and probably shouldn't work this way" or introduces weird new terminology that neither of us can precisely define. Worse, this usually becomes obvious down the line, and I have to parse through the verbose constructed world the agent has created to trace the issue back. That's a big cognitive tax, because I'm holding these weird parallel worlds of "How did the LLM's alien brain get here within the bounds of the contracts" and "What do I really want this to look like".

So I think it's fundamentally the same phenomenon, and we're all developing our skills around working with it in real time.

I think about this a lot. I started my teenage-to-young-adult life in the literary world as a poet who loved programming, and made a living as a ghostwriter. At some point, I fell in love with mathematics and wound up in ML in research/engineering for the last 8 years or so. So, I've thought a lot about writing and ML and their intersection.

I think one of the underappreciated things about writing "substantive" work is that the work you see at the end isn't the first attempt. And I don't mean the first draft of the piece. I mean that almost always, writers iterate on the same topic many times, either with complete published pieces or abandoned drafts or even just conversations and sessions of unproductive daydreaming. It's a cliche that your best work typically also comes out fastest, but it's not because of divine inspiration, it's because you've whittled the big idea you actually care about down so much in your mind that you instinctively know exactly how to write it.

My experience has been that for people who don't work this way or don't write a lot, LLMs can give them this incredible feeling of leaping straight from inkling to "substantive" writing. And because they haven't built up those muscles or "taste", they don't immediately recognize that it's imprecise and hard to follow.

That's not to say they're not brilliant in their own right, just that they haven't spent a lot of time on this particular thing. Sort of like a very gifted programmer who doesn't have a ton of experience yet (speaking as someone who is gifted at nothing and frequently has to do things they're inexperienced at).

So I don't think the problem is that LLMs just write bad. It's that LLMs are so wonderfully powerful that they allow you to confidently leap forward to create something that is a little beyond your experience.

And that's why I have different reactions to heavily AI generated writing. When it feels like marketing at scale, it grosses me out. But when I feel like it's just someone who is excited to write an idea and maybe doesn't have a lot of experience doing it, I'm not judgemental. My hope is that it makes them more excited about writing, and that trying to make their next piece better will lead them inevitably to start thinking about where the last piece fell short. And if there's some slop along the way, eh, I'm not compelled to read it.

Which hyperscalers are doing that? I've heard of one startup trying this, XFRA, currently in early pilot phases. But I'd be pretty surprised to hear that AWS or Google are paying people to host GPU clusters in their home.

Yeah, in essence. This is actually a pretty cool part of working in Lean. It's a somewhat normal convention to write something in a human readable way and then write a second optimized implementation with some kindness of correctness theorem connecting them. There was a whole open "competition" for writing a faster Lean kernel/proof checker that didn't sacrifice on soundness called Lean Kernel Arena. Fun reference point: https://kim-em.github.io/blog/2026-7-24-why-lean-is-faster-t...

Great read, thanks for sharing

I'd wager that the vast majority of the ML research community, especially anyone interested in "AGI", is familiar with Hofstader's work. And I don't think anyone working on contemporary language models would argue that they are somehow an assumption-less "pure" model--the particular inductive bias of the Transformer has been studied by a huge number of researchers and continues to be, and the same is true for things like training data bias.

I think the Hofstader's view of modern LLMs is actually a deeply human and touching one. Looking at his work over the years, his curiosity has always veered towards human thought. He could have written GEB with a focus on completely different examples of self-reference, but he chose three striking humans from history. When he's describing modern systems as "empty intelligence", I think there's a little bit of heartbreak in his perspective, because he sees them as fundamentally different from humans in a way that leaves the part he loves--the "I" in the loop--out of the equation. He gave an interview a few years ago where he explains his feeling as being "diminished" not in a "What will I do if I'm not the best at math?" kind of way, but more specifically as he puts it, that humans are "imperfect, flawed structures".

There is no reason to believe that the transformers couldn't be doing something close to what copycat does (especially with thinking tokens), as an emergent phenomenon of the sheer size of the corpus. The architecture is certainly capable of encoding the actions in copycat anyways.

Love seeing projects like this. The performance benchmarks are nice to see. Have you done any benchmarks against approaches like OpenAI's Symphony for things like token usage or task completion?