Content about #LLM

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.

The past few posts covered how MessagePack was chosen, but interacting through WebAssembly works a little differently from interacting with a native extension.

The reason is that what we’re building is a sandbox to isolate untrusted code, which means the operations are essentially close to one-directional. Code running inside the sandbox cannot touch any of the host’s memory, so the method calls we originally had in mind need some special handling.

Last weekend at COSCUP I gave a talk, “Let AI Take Over Your Application: Building a Seamless, Microsecond-Scale Ruby Sandbox,” covering some of the considerations behind Kobako’s design. During the Q&A afterwards, someone asked: in an era where AI makes the language matter less, why pick Ruby?

The short answer is simply “I like writing Ruby.” But there are much deeper considerations in how Kobako is designed.

Choosing mruby as the sandbox language came out of ruby.wasm’s limitations, but sharing the same language standard (ISO/IEC 30170:2012) with CRuby doesn’t mean the goal comes easily. Compared to CRuby, mruby comes with plenty of restrictions.

Those are the trade-offs mruby has to make to run in environments like embedded systems, and the lightweight nature that comes with them happens to be an advantage for an Embedded Sandbox. It turns the idea of embedding a Ruby sandbox into any language into a viable option.