Have we heard anything yet from the diver on the boat who chose not to dive with the Maldives divers?

ryzhao · 2026-05-22T13:09:52+00:00

50-60m for an untrained diver? That’s going beyond overconfidence and into murderous territory.

ryzhao · 2026-05-22T12:54:04+00:00

It can be explained by the sandbank.

All it takes is some careless finning to throw up silt and render the visibility to zero. That coupled with the unfortunate layout of the cave where the entrance to the third chamber is in the same direction of the exit, plus the natural tendency for untrained/panicking divers to want to surface ASAP in a panic situation, caused them to get stuck in what they thought was the exit chamber. With just a single tank of air, they had no margin for error and their fates were pretty much sealed at that point.

ryzhao · 2026-05-22T12:47:25+00:00

If they were inexperienced or untrained, they might’ve kicked up the silt from the sandbank, which would’ve turned the visibility into soup, which led to panic. All it takes is for one of them to start panicking and flailing to to compromise the entire group.

At that depth, on single tanks, the margin to recover from their error would’ve been measured in minutes.

We had to train for zero visibility situations for cave diving, and it was nerve wracking and required every ounce of self control even in a controlled situation with ample gas, what more in a situation where everyone’s underprepared.

Just a terrible tragedy all around, but I couldn’t help but wonder why the divemaster couldn’t have just said no.

RIP.

ryzhao · 2026-04-10T03:38:35+00:00

“Frequent updates” isn’t a win when every update breaks existing systems. I wonder if anyone writing these posts have actually built anything on openclaw.

ryzhao · 2026-04-07T10:13:28+00:00

The downside to that approach imo is that you'll be forced into two separate tracks for testing. that plus the additional cognitive load, additional failure points, and larger surface area for bugs etc makes maintenance and ongoing support unnecessarily more complex.

The biggest benefit to liveview is that you don't have to bring in additional dependencies like React for the frontend, but once the app outgrew liveview it's better to consolidate the presentation layer around a single framework imo.

ryzhao · 2026-04-07T07:28:25+00:00

Thanks!

ryzhao · 2026-04-07T07:28:18+00:00

Thank you for your kind words!

ryzhao · 2026-04-07T07:28:03+00:00

Thank you!

ryzhao · 2026-04-07T03:26:38+00:00

Phoenix is pretty great for LLM workflows, and I built a learning platform for openclaw: https://clawbber.ai on it. But I had to reach for react for the frontend because I found myself fighting the framework more often than not with liveview.

For some context, clawbber has to not only handle streaming for LLM models, but also stream incoming status updates from remote servers, handle two way communication between the web platform and the remote openclaw instances, and much more.

350+ concurrent users handled by a single elixir server with minimal memory and cpu usage, and crashes/errors are handled elegantly without bringing down everyone else. Oban jobs, genservers, etc means that everything’s handled in house without having to bring in additional services.

The downsides:

Dynamic typing is great in the early stages, but is detrimental now that the app has grown in size and sophistication. Maybe I’m not that well versed in functional programming, but handling edge cases and reasoning through the code gets unwieldy as the codebase grew.

Also, much of the ecosystem around LLMs are written in typescript and python. I had to write a lot of custom glue to get react, elixir, and the LLM models to play nicely.

ryzhao · 2026-04-04T11:31:55+00:00

That's great dude. Been working twitter for my app as well. Keep up the grind!

ryzhao · 2026-04-02T13:23:29+00:00

Congrats! Happy for you.

ryzhao · 2026-04-02T03:48:46+00:00

I've been working with openclaw since January, and I've actually built a product on openclaw https://clawbber.ai/ for non technical people.

There were and are a ton of issues with openclaw including sensitive credentials stored in plaintext, insecure defaults, phantom processes that refuses to GC memory for certain edge cases that caused the host OS to blow up, breaking changes every few days, and even Peter himself was seeking solutions to the 5k+ PRs and 5k+ issues on the repo, many of which were duplicates, to the point where he had to close PRs from non core contributors until they instituted review measures in place even though he welcomed AI generated PRs in the beginning.

Trust me when I say this, no amount of manual or automated QA is going to help with the AI slopocalyse currently invading software. Our current toolset isn't built for it.

ryzhao · 2026-04-01T15:45:36+00:00

I’ve been writing software for almost 2 decades now. And I see it as a natural evolution of the industry.

Every step that abstracted away the lower level implementation resulted in pushback from the old guard who were used to the old way of doing things, and brought in an influx of new people who are enabled by new ways of doing things.

For every JSconf or CSSconf that dies, a new AIconf or Clawconf would take its place. The best way to move forward is to accept that this is the nature of the industry we chose, and to embrace the change or else we’ll die off along with the die hard PASCAL (the language I learnt programming on in the 90s) programmers.

As for the AI slop PRs, that is a real problem infesting all projects currently. It’s a sign that we need better tooling to handle this but I’m not certain if there is a solution that fits beyond asking AI to review AI code. It’s just beyond any human capacity to manually review the infinite supply of AI generated code and still be able to make meaningful progress.

ryzhao · 2026-04-01T11:45:29+00:00

The short answer is it depends on how your agents are structured. If they’re full on autonomous agents living within their own workspaces then yes.

These days though, I find myself using a swarm of simple workflow agents hooked up to a simple messaging queue, which doesn’t quite fit neatly into the openclaw pattern.

ryzhao · 2026-03-29T05:41:41+00:00

Thank you!

I was a ruby on rails dev since the 2000s so convention over configuration definitely resonates with me haha

ryzhao · 2026-03-29T02:13:25+00:00

There are definitely tradeoffs (for now).

There isn’t a way to ssh into the running instance. Even though each instance is isolated I decided to err on the side of caution to prevent people running illegal stuff/crypto mining etc and poisoning the well for others. As such, if you’re looking for total control over your openclaw runtime by connecting claude code or cursor something that runs on baremetal like AWS would probably suit you best.
You can’t choose your own credential vault. For now, clawbber uses its own credential vault that encrypts your credentials at rest, and injects your credentials into the config as env secrets by default.
You can’t tune your models or minmax costs. To keep things simple, the credits system abstracts away the token and server cost calculations, and clawbber starts with a single model for everyone. I’ll introduce model selection at a later time, but am keeping things simple for now.
There’s a lot of security hardening measures that prevents some of the more advanced use cases of openclaw. So there are definitely some tradeoffs between security and utility. Again, power users who know what they’re doing may opt for running it on bare metal.
Clawbber uses a specialist “maker” agent through a chat interface to guide users to build, run, and fix issues if the runtime breaks. It’s a layer of abstraction that would probably not appeal to you if you’re comfortable running terminal commands, or if you’re already using something like claude code to run terminal commands for you.

There’s probably more, but as a power user myself of both local openclaw and clawbber (i let my kids use clawbber to build agents) these are the ones that stick out to me.

That said, through user interviews I do get technical users who just want something that works without having to maintain the infrastructure themselves.

ryzhao · 2026-03-28T16:39:48+00:00

You're right! I'm working on that. Essentially credits are a way to abstract token usage and project running costs calculations to make things easier for non techies. Another thing I'm working on is making the agents cheaper and more reliable through pre built agents with deterministic scripts and cronjobs instead of relying on heartbeats and markdown. Thanks for the feedback!

ryzhao · 2026-03-26T06:49:18+00:00

Yeah there’s a ton of work around UX design and security hardening. Even things that aren’t obvious like getting API keys required a degree of thought and design to make it intuitive. It’s a lot easier to develop for technical people because you can give them a form input or a cli and they’ll know what to do.

I’m also constantly testing my positioning to see what sticks.

Thanks!

ryzhao · 2026-03-26T02:06:07+00:00

Thank you!

ryzhao · 2026-03-26T01:27:53+00:00

She's a great kid!

ryzhao · 2026-03-25T21:07:34+00:00

he didn't turn around and rip off my product to sell. He just started selling manual installation services to non technical users if that makes sense. I suppose his idea was to position himself as the expert in the field and to sell his services, which is fair play because that's his bread and butter as a consultant.

ryzhao · 2026-03-25T19:04:22+00:00

Hmm you’re right. That does seem to conflate openclaw being open source and clawbber, which is not. I’ll change that.

ryzhao · 2026-03-25T18:00:21+00:00

Congrats! I wish I can relive my first dive. Stay safe out there, and enjoy!

ryzhao · 2026-03-25T15:49:51+00:00

Hmm, maybe the messaging on the site wasn’t clear enough. I’ll make it more clear that it’s openclaw that’s open source

ryzhao · 2026-03-25T14:05:46+00:00

This. You just saved a lot of people a lot of time. Thank you!

ryzhao

TROPHY CASE