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.

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.

[1]: https://www.anthropic.com/research/formal-verification

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. :)

There are free, web-based wizards to create PKPass-format Apple Wallet passes. This one was posted on HN a few months ago.

https://walletwallet.alen.ro/

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.

Well, yea. Everyone agrees with these points. Who wants to ruin things for the sake of it?

The reason why things get worse is because of systemic problems: misaligned incentives, information asymmetry, diffuse responsibility, etc. It's actually hard to improve these aspects of large systems. Hence, why the world is an imperfect place.

They have a "before" picture but not an "after"!

Suddenly turning off services when the billing cap is reached is a big reliability risk for customers. All workloads using that billing account would be impacted immediately.

If they weren't turned off at the billing cap, but were given some leeway instead, either that becomes the new hard limit, or GCP will have to give away the difference.

And there's no "middle ground" you could implement that makes sense either - like a "frozen" state. Preventing new writes to a GCS bucket breaks the writer app. Freezing VMs serving web traffic takes the site down.

Even if the service was shut down once the billing limit is hit, how long would GCP wait for the user to add funds or raise the limit? GCP would need to either keep the services in a hidden/frozen state or not turn them off / freeze them at all (in which case GCP would be giving away resources for free).

Maybe GCP can give users a heads-up when they're about to hit the limit? GCP already does - billing alerts do exist. It's just possible to blow past them if your usage is a massive spike.

Moreover, getting the hundreds of GCP services to implement a "frozen" state is difficult. It's hard enough getting everyone to listen to the "billing account disabled" signal, and (soft-)delete the resources (based on the resource, after some time interval). Given these billing overruns happen for smaller customers, it's not really worth solving the problem - which I don't think has a great solution to begin with.

How much do existing services trust new email service providers? It would seem to be an uphill battle for Cloudflare to start a new service. It's easy to automate from the start, meaning it's easier to send spam. I suppose reputation is not simply based on the domain the email comes from?

Brilliant piece of content marketing:

1) Pulls you in with a catchy title, that at first glance seems like a dunk on Cal.com (whatever that is).

2) Takes the "we understand your pain" approach to empathize w/ Cal.com, so you feel like you're on the good vibes side.

3) Provides a genuine response to the actual problem Cal.com is dealing with. Something you can't dismiss out of hand.

4) But in the end of the day, the response aligns perfectly with the product they're promoting (a click away to the homepage!)

This mix of genuine ideas and marketing is quite potent. Not saying this is all bad or anything, just found it a bit funny. The mixed-up-ness is the point!

A blog post like this is half the story. I’d like to see the results. Did your brother get more business? What were the failure modes? Did customers care if it was a bot or not?

They have direct feedback that many people return them bc they’re too heavy, and yet… It’s just Apple being stubborn. I guess it’s not a big enough problem for them, and they don’t care about losing the market. One must laugh.

Is AI-driven clean room implementation a wild west at the moment? I suppose there haven't yet been any cases to test this out in real life?

I'm glad you remember it as well! I didn't think to see if there was a recording or something of this talk, until now. It looks like the text of the talk was published here: https://www.cs.utexas.edu/~EWD/DijkstraMemorialLectures/Tony...

And the talk wasn't a random talk, but a memorial talk for Dijkstra: "The 2010 Edsger W. Dijkstra Memorial Lecture". I forgot this aspect as well!

That's right - it was bubble sort first. Absolutely - frail, yet sharp. I'm happy to hear several of us didn't forget this encounter with him.

Good to hear from you after a while, Gaurav (I think?!).

He came to give a lecture at UT Austin, where I did my undergrad. I had a chance to ask him a question: "what's the story behind inventing QuickSort?". He said something simple, like "first I thought of MergeSort, and then I thought of QuickSort" - as if it were just natural thought. He came across as a kind and humble person. Glad to have met one of the greats of the field!

The problem can be complex, which sometimes means the solution needs to be complex. Often, you can solve a complex problem in simple ways. There’s many ways to do that:

a) finding a new theoretical frame that simplifies the space or solutions, helps people think through it in a principled way

b) finding ways to use existing abstractions, that others may not have been able to find

c) using non-technical levers, like working at the org/business/UX level to cut scope, simplify requirements,

The way you can make complexity work for your career, is to make it clear why the problem is complex, and then what you did to simplify the problem. If you just present a simple solution, no one will get it. It’s like “showing your work”.

In some orgs, this is hopeless, as they really do reward complexity of implementation.

One of the odd things people do with tech is taking someone else's random projections at face value?

What does it mean to say "we were promised flying cars", or "every city would have micro-factories, that 3D printing would decentralize production"?

The people creating these narratives may a) truly believe it and tried to make it a reality, but failed b) never believed it at all, but failed anyway, c) or be somewhere else on this quadrant of belief vs actuality.

Why not just treat it as, "a prediction that went wrong". I suppose it's because a narrative of promise feels like a promise, and people don't like being lied to.

It's a strange narrative maneuver we keep doing with tech, which is more future-facing than most fields.

It's extremely painful that there's are free, OSS dictation tools that can run on-device, that are so much better than Apple's dictation, and yet it's quite difficult to use them on the iPhone. I'm referring to Whispr. Microphone access is a pain for custom keyboards -- for good reason, but still.