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.

I’ve been working on Kobako for a few months now, and I’ll also be presenting the project at COSCUP. The process has been interesting enough that I think it deserves a series of posts about how I set out to build a sandbox for the AI era.

By the time of writing, there have been around 20 releases. From here on I’ll walk through Kobako’s evolution as close to chronological order as I can, along with the decisions made along the way.

Kobako is a sandbox I recently built on WebAssembly and mruby for the Ruby ecosystem, in support of Harness Engineering, to fill the gap where AI-written code has no safe environment to run in.

I already introduced Kobako’s design in a previous post, so this time I want to talk about performance. In its early versions, the Cold Start (the initial startup) took roughly 500 ms. That’s a lot slower than the 200 ms response time you’d usually aim for as a best practice. Even though AI generally tolerates slower responses, this isn’t about waiting on an LLM, so it still deserves to be judged by traditional API standards.

Developing Kobako has surfaced quite a few interesting cases. Continuing from the previous post, Building Kobako with AI: Will It Eventually Crash?, I ran into yet another new problem afterward—and this time it was the Segmentation Fault error I had always dreaded seeing during development. That signals a high chance something went wrong in the non-Ruby territory between Rust and WebAssembly.

Last week I published Kobako: Letting Agents Safely Operate Rails, introducing the goals of the Kobako gem. Since then I’ve kept pushing development forward with Claude Code—but I quickly ran into a situation that demanded major changes. Is this simply the fate of developing with AI?

This is a question worth discussing: when using AI to assist development, is the problem that AI isn’t capable enough, or that the design we humans handed it was too poor?

At RubyKaigi 2026 this year, while chatting with friends about Harness Engineering and the Sandbox aspect of it, I realized that Ruby still lacks a solid solution in this space. On the second night, I happened to be assigned to the dRuby (Ruby’s built-in distributed object system) group at the Code Party — and that’s how the idea for Kobako was born.

The Ralph Loop technique — a trick for making AI Coding Agents automatically repeat execution — was popular last year, but I didn’t trust whether it was safe enough or sufficiently stable.

A few months ago, Claude Code’s update introduced the /loop skill, which essentially uses Claude Code’s built-in Cron tool to repeat specific prompts at fixed intervals, achieving a similar effect. At least it’s safer and more controllable.

However, things are rarely that simple.

I previously wrote Should You Have Your Own Agent Skills? to explain why I believe everyone should maintain their own skills. But another phenomenon I’ve noticed is: are those “impressive skill collections” really as magical as they seem?

From my own experience, things work just as well without all that content — stuffing in too much might actually waste tokens and even hurt performance.

Recently, due to work requirements, I needed to evaluate AI Agents and also ended up comparing them with Agentic AI. If you’re also evaluating or adopting AI agent-related technologies, these two concepts may look similar but are quite different.

I often see discussions like “this tool is amazing,” but after actually using another person’s Agent Skill, it usually doesn’t feel quite right, and the results don’t match expectations. On top of that, letting arbitrary people provide your Agent Skills is quite dangerous from a security perspective, since we authorize Agents to do many things—far more dangerous than regular software tools.

Beyond security, there are many other reasons why having your own set of Agent Skills is a better approach.