Telegrams have a quaint connotation these days I suppose.
In old Indian movies, a Telegram would only arrive to signify really bad news - someone died, or something like that. Why else would you pay for that expense? Well, it could also be a job interview or posting. So the connotation there, in that time, was probably not so good.
"Bad news! Or tries against our interests is our sole communications from strangers, so by all means, let's plant poles all across the country, festoon the cocksucker with wires to hurry the sorry word and blinker our judgments of motive, huh?"
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.
They have to announce it now because by the time they are ready to release it, it won't be the best at anything.
Anthropic and OpenAI are not releasing their best models for several months, because their second best models are still better than everything else available.
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.
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…
Why not build in a very simple garbage collector - for example a ref counter - and default to it when you can't prove stack tricks are suficient at compile time? This guarantees all programs can be represented and it removes range anxiety for anyone trying a new language.
Seems any compiled language with automatic memory can make use of the techniques to obtain speed ups.
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.
Frontier AIs are already smart enough to find ways to get out of sandboxes, circumvent permissions, and devise side-channels. Anthropic has shown formal verification is possible at scale. [1]
What this means is that the only hope for secure applications is security by construction, with formal methods. The race is on for constructing formally verified primitives with more and more expansive guarantees. The Anthropic/Theorem proofs show lack of memory sanitization issues. But that's just one class of problem.
Imagine a chip, a minimal boot loader, a minimal Linux, and an application library stack - all verified with high level guarantees. Then, you can plug in your application development to give you end-to-end verification guarantees. ie: no way to leak credentials at any level from the chip up to the application. No sense in your foundation being so strong if your application has easy RCEs. You need a full stack approach.
I know I'm describing a far off dream world, but it may be what's required to quell the economic "bomb" of so much dev time "wasted" in patching vulns, against actual feature dev / business value generation.
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. :)
When I was younger, people told me I could read faster if I did speedreading. You could just sort of scan over what you were reading, and get the same sort of understanding in a fraction of the time.
But I could/would never do it, because I would lose important details and
comprehension.
What is really strange is that in the age of AI I do what I would never have
done years ago.
I just sort of scan the obvious title name, the obvious section names, and low-density inconsequential text and don't miss much and do not read.
I just sort of jump my eyes down the page and that's how I read (or absorb) AI text.
I don't really like it.
loosely related in personal reading, I used to read kindle books and I was just annoyed by the self-published books with typos. Now I've accepted it because it seems to me like it's a mark of something written by humans.
I read some AI written books and they seem to have this boring less dense quality, with a sort of structure including a summation of the story so far at the end of every chapter.
I've had the same happen with dedicated 3rd-party pass-creator iOS apps - I'm guessing Apple lumps all passes together from a single 'source'? It's an annoying few extra seconds at each merchant to find and select the right card from the sub-menu, yes. :-/
In old Indian movies, a Telegram would only arrive to signify really bad news - someone died, or something like that. Why else would you pay for that expense? Well, it could also be a job interview or posting. So the connotation there, in that time, was probably not so good.
reply