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.

Have you noticed that AI-generated code often requires significant rewriting every time you integrate it? Since the launch of Coding Agents, there have been constant voices claiming that software engineers will be replaced. However, through my recent collaboration with colleagues, the overall situation still aligns with the reality that “professionals remain.”

Some might think that with Coding Agents, “there’s no need to learn software development,” but they fail to realize that much of advanced software development knowledge isn’t about “implementation” - it’s about “design” and “architecture.”

In 2025, we experienced a year of rapid advancement in LLMs (Large Language Models). Tools in the form of AI Agents have become increasingly common, and Coding Agents for software development have matured to the point of becoming standard equipment, rather than just one of many means to quickly modify files.

However, for software engineers, I believe the most worthwhile investment in 2026 isn’t learning to use tools like Coding Agents, but rather developing more fundamental capabilities.

Have you seen Claude Code’s Sub-Agent feature and immediately wanted to design a bunch of them? Backend Agent, Frontend Agent, and so on—it feels like getting more powerful tools. But do you really need them?

During WebConf 2025, chatting with friends about this topic revealed that many people are still unfamiliar with when to use Sub-Agents. Two talks at the conference provided good entry points: ihower’s AI Agents Development and 91APP’s Chief Architect Andrew’s From Service to Agent.

Recently, the Hono framework launched the Hono CLI tool, and I quickly created a Hono Plugin for Claude Code, adding Agent Skill support for querying documentation using Hono CLI.

At the same time, I realized that the ri (Ruby Information) command, which I rarely use, provides similar capabilities to the Hono CLI. Therefore, I created the Ruby Plugin ahead of schedule to provide the ri skill.

I was originally planning to release a tool that applied techniques from my COSCUP talk in August. However, I discovered that there are many considerations in development, and practical usage has its barriers.

I decided to start from a simpler, more immediately accessible angle. Recently, I finally completed the basic functionality of ccharness, which can improve Claude Code’s output quality from a different perspective.