wild_egg

Early 2000s tech could absolutely handle LLM agents as a client. They output like 1-2kbps and even dial up modems would have plenty of capacity for other traffic.

The UI itself requires laughably simple tech. The idea that a markdown renderer that can produce HTML at 50MB/s would use much CPU to process incoming hundreds of bytes per second is insane. CPU should be idle even if doing that constantly. Nevermind that between turns it has nothing to do whatsoever and should use zero CPU at all.

There are two different arguments here.

> These apps are doing real work taking text that is streaming in and doing syntax highlighting, calculating diffs, and rendering markdown.

The first argument is that these are expensive operations. They are not. And the second argument is the assumption that these are desirable things for an agent system to be doing. That's a personal preference but, personally, I don't want them and would appreciate a way to disable all of that to reduce CPU use.

No, the fundamental problem of these apps is that they are, for no reason, pretending they need a high powered game engine rendering loop. They don't. It's a text printout of history with some hotkeys for mode switches and such. "rendering in a single thread" should never be an issue because it should never be "rendering". It needs to stream text to stdout. That's been a solved problem for 50 years and now it takes 2GB of memory to be done poorly with broken scrollback.

> SQLite definitely seems like a poor choice for dealing with many concurrent requests

Can you qualify "many"? SQLite easily handles 100k+ writes per second and it's not hard to have app layer code serialize and batch writes to take advantage of that speed. Concurrent writes require a ton of overhead and your system and code can be quite a lot faster and simpler if you just skip the idea of them altogether.

There are a ton of optimization opportunities that hinge on the intent of a piece of code which static compilers can never detect at scale. LLMs can actually navigate that and write surprisingly optimal assembly.

I've had all my side projects being written in x64 for the last 6 months and it is shockingly effective.

You pull out Einstein when you need a breakthrough.

There is an amount of brute forcing that becomes possible at those speeds that I think could even take us beyond 80%. If we could have Qwen3.6-27B running at 15k t/s, run 100 attempts concurrently, select top-K solutions and synthesize a final result from them.

There was a paper a while back that showed top-K selection like that with tiny models was able to reliably solve some 1M-step Tower of Hanoi when no frontier model could. Very big level up in capability just from horizontally scaling compute.

Why a "parquet-like" format and not just parquet?

Will include in next month's thread! Finally getting it where I want after a year of hacking so it seems time to think about how I want to open it up.

Nothing public yet but hopefully will have for next month's thread!

Building a new Smalltalk VM from scratch that better utilizes modern hardware (full multicore support) and a web-based system browser so I can develop with it remotely.

What an odd bit to latch onto. What ratio would you find more appropriate?

> you expect of AI the ability to use the vast knowledge on languages and platforms that already exist out there.

They do. Even completely novel esolangs have enough in common with other things that the current models don't even blink.

I really recommend trying it some time.

That really, really depends on the language.

You're not wrong. I did a similar agent in lisp back with Sonnet 3.5 and had a wow moment, but the wow was mostly for seeing an agent working effectively at all at that point in time.

The part that killed it for me was losing everything if the lisp crashed (sonnet 3.5 was prone to doing that) and solving persistence had too many edge cases and confused the model.

Later realized that writing the agent as 20 lines of bash was equivalently powerful to the lisp agent, but made persistence trivial from the easy file system interop.

Why does having. GC mean not thinking about memory? I think about memory constantly in GC languages because I still want it to perform well.

The biggest difference is the failure modes. If I'm not thinking about memory, my RSS is higher or a bit of extra CPU time goes to GC. Both of those are radically better than UAF or buffer overruns. Good trade IMO.

Do you mean Tree Calculus? https://treecalcul.us

> unless you literally have written a new type system and compiler

This is entirely possible with plain lisp macros. See https://coalton-lang.github.io

Having that natively available as plain Common Lisp code is a very different thing from your "just read a text block and compile it as rust code!" concept. Or at least, the tool chain gymnastics required to make a C program emit its own source in another language... Why?

Can anyone explain this "quietly quantized" model idea to me from a business perspective?

Coca-Cola doesn't "quietly water down" its product to save a few bucks. They know people will take a sip, say "oh that's not what i wanted", and go buy a Pepsi.

If they serve me a quantized Fable, I'm just going to think Fable sucks and go get my tokens elsewhere. What's the point?

There's a bit of a mental model flip to make maybe.

> they're code that's generated at compile time

They're code that generates code at compile time. Macros can actively walk the AST of the parameters they process and rewrite them completely into new shapes. That transformed AST is what then actually gets compiled.

check out tsnet if you are building on tailscale anyways. your app can then be a tailnet node that can read tailnet WhoIs data and have access controlled via tailnet ACL

Really depends what you're working on. GLM 5.2 is doing excellent webdev work for me but really faffed up when working on a custom garbage collector that Opus has no problems with.

> LLMs do not produce a usable result

At this point, this is categorically false. Your mental model is very out of date.

The results may not be ideal but I can't say I've had a single output so far this year that wasn't usable.

Emphasis on the modern CSS. @layer, @scope, etc. go a long way in fixing the footguns.

`npm install` is the OG vibecoding

Do you mean blubs?

I'm actually very happy about this. Babysitting the agent just in case it needs me to do something is a terrible use of my time. I've always had to be very explicit about the various ways that it can get an automated feedback loop going to check its work, and now Fable doesn't even need that hand holding. Really great improvement all around.

Modern CSS is actually really quite pleasant.

Generally you don't even need to do the sub-routing in the handler. You can just render the entire page and have `hx-select` attributes pluck out the part that you want.