Content about #Experience

Over the weekend I spent some time reading how NVIDIA’s newly released OpenShell achieves network security for its Sandbox. The Managed Agents offered by Anthropic and OpenAI have similar features, but their source code isn’t available, so all we can do is guess which techniques they might use.

What surprised me is that the OpenShell documentation lets you ask an AI questions. Without reading the source code, I was able to verify my assumptions quickly and get a rough idea of how it currently solves the Credentials problem.

Kobako recently moved to v0.28.0, which reworked the design that used to depend heavily on MessagePack. It’s the first major revision since COSCUP wrapped up in August.

Still, as we head into next year’s (2027) AI applications, what capability is the Ruby ecosystem still missing? I think the answer comes back once again to the “Virtual Filesystem” I talked about with friends at RubyKaigi in Japan this April, so Kobako is about to support it as well.

In Kobako: Script Execution we walked through how a complete run is designed, but the current design still has some inconvenient spots. When we want to call a Ruby object from inside the sandbox, it’s hard to actually make use of the values it returns.

Over the weekend, while evaluating which frontend framework Tsuzuri should move to from Stimulus, I opened the Svelte tutorial to keep the whole thing lightweight. To my surprise, it doesn’t allow copy and paste at all, so for the first time in a long while I wrote the code by hand.

After about an hour of typing it all out, I was amazed at how much Svelte achieves with such concise syntax, and it made me wonder: when AI does the implementation, can we still find surprises like this?

The subtitle tool that has impressed me most recently is What’Sub, built by the YouTuber 壹加壹. In most situations, whenever someone needs to work on video subtitles, I simply recommend it.

However, about half a year ago, when a friend asked me “Is there a way to make transcripts?” and “Can we translate those transcripts?,” there was always one precondition: “no cloud services.” That ruled out most of the options on the market.

One great thing about this era is that AI lets anyone customize tools for their own needs, and Tsuzuri was born against exactly this background.

With standard output in place, whether a script runs correctly can finally be verified, which means we can start genuinely running Ruby inside Kobako’s sandbox environment.

Having sorted out the basic conditions for running mruby on WebAssembly, it’s time to start thinking about more practical uses. At the very least, a script should be able to run and print a message like Hello World, but mruby itself wasn’t designed with the WASI (WebAssembly System Interface) environment in mind, so many Gems simply can’t be used.

In Kobako: Exchanging Memory in WebAssembly we solved the problem of Ruby and WebAssembly interacting, and gave Ruby and mruby the ability to exchange values with each other, which basically cleared up the “sandbox” problem.

Kobako’s development is still at a very early stage, though, because there are plenty of problems that only show up in real use, and one of them is the problem of “deciding how to stop.”

Sumitsubo is the tool I use to turn a “spec” into code that can actually be verified. In the early attempt covered by Sumitsubo: Turning Specs into a Linter I used JSON to describe the spec, but while looking into whether similar tools already existed, I unexpectedly found that making Markdown itself the structured source of information lets you design the tool by writing documents.

Midway through building Kobako, the question of whether the spec and the implementation were still aligned kept bothering me. Spec-Driven Development is ideal in theory, but language models are not deterministic by design, and even with a spec to refer to they still drift, or leave things out.

So Sumitsubo came together recently as a general-purpose checking tool.