pradn

A middle ground would be an LLM taking structured inputs ("mouse clicked at X,Y") and making "draw" calls at whatever level: pixels, SVG, HTML/CSS. While the LLM's output tokens could be mapped to just these calls, it could also just do a bunch of tool calls that write to these formats as well -- it's a matter of efficiency.

We have Jev to prove LLMs that output constrained decisions are useful. Why not make LLMs just output UI natively?

At a fast enough inference speed, you could just connect the network to it.

So an LLM would then just take the network, user input, and output a UI, with tool calls to deal with memory and other resources. In theory, you don't need an OS any more.

It doesn't seem possible to actually release frontier models quickly any more. Given their cyber capabilities, playing nice with the powers that be is probably required these days.

Who is doing the promising and why did you listen to them? Did they write it in blood? These statements are strange. It's a way to place vague blame, and remove the onus of critical thought from oneself.

If your employer lets you chill, their competitors will not, and win. That's how it goes.

Prompting and reading detailed AI output all day long, trying to tease apart the goods and bads - it's extremely exhausting. You don't get the mental breaks of pressing the compile or test button, or doing small refactors like pulling a logic into its own function. Coding is gone as a pleasure at work.

IIRC, this is feasible. But I think there's a nice simplicity in constraints. You know what you'd use Goose for, if it limits what you can express.

Goose is pretty cool. The idea is that you don’t need to make representable all programs: a language for a restricted purpose is ok. As long as you can statically specify the number of growable memory regions, you can use Goose. However, since there’s no garbage collection, you’ll probably need to be careful about memory use while a program is running. Ie: the stacks can get too big if you keep growing them, even as old data is not used any more.

Still, for a large number of programs - like data-oriented applications - it’s probably a good fit. It might work ok with entity-component game systems as long as you reuse old memory…

Games can now be recompiled to other platforms, like consoles and the browser, via WASM. So Zelda BotW can be played on a jailbroken PS5, and in the browser.

What actually limits someone from doing this?

1) You need the hardware to play the games, still. You still need a good enough PC or a console like a PS5 to play all these emulated/cross-compiled games. Though, the cost is moderate these days: a used PS5 goes for $400-500?

2) You need to want to jailbreak your console, giving up "mainstream" features (multiplayer, warranty). This requires some interest and know-how, too. Though the jailbreak steps are easy these days.

3) If you lack a console, your PC needs to be strong enough to play WASM or emulated/cross-compiled games. I suppose for consoles like the Switch, that aren't super powerful, most PCs made the past few years could play a AAA Zelda game in the browser. But playing on PC is often not as fun as on a console, with the couch and controller and all.

I have a hard time people en masse want to give up multiplayer, by jailbreaking their consoles.

But single-player games are probably going to have a harder time.

The video game world is already super top heavy, with mass-market multi-player games (like Valorant), not to mention casino-like gacha games. So the trends may further favor this current track.

There was a time when coming up with a new JS clock, at least a novel one, would be fun to look into. When confronted with 500 of these, the inclination to care about this problem at all vanishes.

The problems I see with AI-generated, or heavily-AI assisted technical design docs in my team:

1) It's easy to generate very long docs that explore every conditional, etc. It is probably better overall, because more edge cases are being caught. But, the docs tend to be very long, and often at a lower abstraction level than appropriate for a design doc. At the limit, why not just put all the code in the design doc, too? It's rarely necessary. Though, when the thing we're focusing on is an API, it is appropriate to put the API service proto diff in the design doc...

2) They're harder to read, often for easily discernable reasons. They love doing the "bullet colon sentence" pattern, which often just means you're reading a concept twice. Sometimes, it helps. But I can't help but distrust that pattern more just because its so obviously AI generated. A more pernicious problem is the AI using phrases that are technically correct, but not part of our verbal culture. An example is using "observability workloads" instead of "probers" or "CL submission strata" instead of "CL submission order". Perhaps a Skill and an obedient AI can make these particular problems go away. Perhaps there needs to be a "preferred vocabulary" dictionary distilled from all the teams' docs...

If I generate code or text with AI, I have been adding a bit of hand-written text that tells people what exactly I verified. Like "I've read all the words in this comment", or "I cross checked this data with other similar metrics at X". The trust you get from human validation is the scarce thing now, not the output itself.

I was embarrassed to blurt out factoids based on quick AI-based analysis that turned out to be incomplete at later, deeper inspection. So I've stopped doing that. :)

It was clearly a "tongue-in-cheek" framing. Got me interested at least!

It's clear that frontier agent swarms are going to be an important cyberweapon for well-resourced groups. Not just governments: organized crime, rebels. It will be feasible to train a deliberately misaligned agent, and to point them at adversaries. We'll have to deal with persistent, ongoing attacks, like we do with DDoS and ransomware attacks today. The limits on this will be intent, hardware cost, and talent.

You need an agent swarm to defend cyber-assets. No way we can respond at human speed.

Another consequence is that every public API with a bug bounty will be pen-tested up til the cost (in expectation) of running the AIs. We already see public AI-discovered vulns being reported to companies.

I'm not sure what this means for AI startups if their innovations can be copied by OSS so quickly (what, like 2 weeks?). There's "consumer surplus" for everyone, to borrow an economic concept. But we do ideally want some of the surplus to flow to the innovator, too. I know there were precursors, but that's fine - it's hard to have a totally novel idea in such a popular field. I don't know what the end game is for TypeSafe - they'd need to demonstrate perpetually better results, or compete in another axis: UX, support, custom solutions, etc. So much of the time, someone proving a concept, or it simply getting enough publicity, is enough for a "Cambrian explosion" of follow-ups and copies. Famously, that was true for "Attention is All You Need", and the general idea of "next-token prediction" being so powerful.

We've stumbled into general differentiable models..

The post is clearly in Claude English. Sorry not going to read a post in such an obnoxious style.