wild_egg

Interesting! I wrote a Smalltalk in CL last year that did the same kind of mapping: Smalltalk classes compile to CLOS classes and every message is a CLOS method. Worked great at the start and then performance dropped off as more classes compiled.

I never took the time to get that sorted out but it smells suspiciously similar to what you described here. Thanks for the write up!

I might have misinterpreted what the submitted link is offering then. I thought this was some "secure" sandboxing thing where agents can write ephemeral scripts as tool calls to take arbitrary actions. No human will be looking at that. It's not checked into a repo and is not maintained.

One-off throwaway scripts can be written in literally anything. It does not matter.

Ah I forgot to add an /s

I agree on all counts and that this project is silly on the face of it.

My comment was more that there is a massive cohort of devs who have never done sysadmin and know nothing of prior art in the space. Typescript "feels" safe and familiar and the right way to accomplish their goals, regardless of if it actually is.

Jails are alien magic and typescript is safe and familiar

Agents really do not care at all how "nice" a language is. You only need to be picky with language if a human is going to be working with the code. I get the impression that is not the use case here though

From the title I thought there was some massive Hashicorp/IBM boondoggle. But no. Just crypto being crypto.

I'm probably 10 years out of date. Are ethereum smart contracts still a thing? I'm sure you could deploy one of those for every agent session to handle the notifications

This project very most definitely has significant AI contributions.

Don't care though. AI can work wonders in skilled hands and I'm looking forward to using this project

Just want to say upfront: this mindset is completely baffling to me.

Someone gives you a hammer. You've never seen one before. They tell you it's a great new tool with so many ways to use it. So you hook a bag on both ends and use it to carry your groceries home.

You hear lots of people are using their own hammers to make furniture and fix things around the home.

Your response is "I accept what you say about the best way to use these hammers. But my worry is that there is nothing that requires people to use them in that way."

These things are not intelligent. They're just tools. If you don't use a guide with your band saw, you aren't going to get straight cuts. If you want straight cuts from your AI, you need the right structure around it to keep it on track.

Incidentally, those structures are also the sorts of things that greatly benefit human programmers.

I don't see any problems with either of those framings.

It really doesn't matter at all whether these things are "truly intelligent". They give me functioning code that meets my requirements. If standard fuzzers or search algorithms could do the same, I would use those too.

You need to be telling it to create reproduction test cases first and iterate until it's truly solved. There's no need for you to manually be testing that sort of thing.

The key to success with agents is tight, correct feedback loops so they can validate their own work. Go has great tooling for debugging race conditions. Tell it to leverage those properly and it shouldn't have any problems solving it unless you steer it off course.

Terminals already solved how to do this decades ago: pagers.

Write the full content to a file and have less display it. That's a single "render" you do once and write to a file.

Your TUI code spawns `less <file>` and waits. Zero rendering loop overhead, zero tearing, zero stutter. `less` is a 40-year-old tool that exists precisely to solve this problem efficiently.

If you need to stream new content in as the session progresses, write it to the file in the background and the user can use `less +F` (follow mode, like tail -f) to watch updates.

I had that for a few months and cancelled. They have minutely rate limits as well so you get 3-4 hyperspeed responses and then a 45 second pause waiting for the throttling to let your next request through.

And then, depending on what you're working on, the 24M daily allotment is gone in under an hour. I regularly burned it in about 25 minutes of agent use.

I imagine if I had infinite budget to pay regular API rates on a high usage tier, it would be really quite good though.

`br` is still massively larger than necessary for the feature set.

I didn't mention above but I made https://github.com/wedow/ticket as my beads replacement back at the end of December.

I have zero reach compared to Jeff there so I'm considering `ticket` to be a smash hit at this point ;)

Task management is fundamentally straightforward and yet workflow specific enough that I recommend everyone just spend a few hours building their own tools at this point.

Beads is a nightmare.

It took them about 15 minutes to update that page

The ISS creates radically less heat than a datacenter

I'm really struggling to think of a scenario where I would want to do something like that.

What use case do you have in mind?

FWIW, this will be part of the core library in the next version instead of a separate extension.

https://four.htmx.org/htmx-4/#built-in-streaming-response-su...

> Email is an optimal interface for long-running agents.

Long-running agents are themselves not optimal though. There are a ton of these coordination layers for long running agents now but they don't make any sense under other paradigms

I guess not to be confused with https://github.com/Dicklesworthstone/mcp_agent_mail?

Connecting to localhost still involves the network stack and a fair bit of overhead.

SQLite is embedded in your program's address space. You call its functions directly like any other function. Depending on your language, there is probably some FFI overhead but it's a lot less than than an external localhost connection

Aside from losing the loop (the whole point of the command), why the double `cat`?

It's explained under the July 2025 heading with link to the blog post where it was first shared.

The key bit is right under that though. Ralph is literally just this:

    while :; do cat PROMPT.md | npx --yes @sourcegraph/amp ; done

I was disappointed to see that this is still 10x the code needed for the feature set and that it still insists on duplicating state into a SQLite index for such minuscule amounts of data.

I've seen 25-30 similar efforts to make a Beads alternative and they all do this for some reason.

Beads was phenomenal back in October when it was released. Unfortunately it has somehow grown like a cancer. Now 275k lines of Go for task tracking? And no human fully knows what it is all doing. Steve Yegge is quite proud to say he's never looked at any of its code. It installs magic hooks and daemons all over your system and refuses to let go. Most user hostile software I've used in a long time.

Lot of folks rolling their own tools as replacements now. I shared mine [0] a couple weeks ago and quite a few folks have been happy with the change.

Regardless of what you do, I highly recommend to everyone that they get off the Beads bandwagon before it crashes them into a brick wall.

[0] https://github.com/wedow/ticket

I do wonder if C programmers ever asked that of Python devs back in the day.

After a certain experience level though, I think most of us get to the point of knowing what that difference in quality actually matters.

Some seniors love to bikeshed PRs all day because they can do it better but generally that activity has zero actual value. Sometimes it matters, often it doesn't.

Stop with the "I could do this better by hand" and ask "is it worth the extra 4 hours to do this by hand, or is this actually good enough to meet the goals?"

This is such a tired response at this point.

People are under zero obligation to release their work to the public. Simon actually publishes and writes about a remarkable amount of the side projects he builds with AI.

The rest of us just build tons of cool stuff for personal use or for $JOB. Releasing stuff to the public is, in general, a massive amount of extra work for very little benefit. There are loads of FOSS maintainers trapped spending as much time managing their communities as they do their actual projects and many of us just don't have time for that.

I've had Opus 4.5 hand rolling CUDA kernels and writing a custom event loop on io_uring lately and both were done really well. Need to set up the right feedback loops so it can test its work thoroughly but then it flies.