AI

I tried Sarashina Translate API for my technical blog posts

Thu, 15 Oct 2026 20:35:05 +0900

I added an English version to my blog. After implementing the language switch on the site, I still had to turn 51 technical articles from 2026 into individual English posts. I could write short introductions by hand, but I needed another way to translate long articles full of code and links. So I tried Sarashina and its Translate API.

The API helped me translate the prose. I could not paste its output straight into Hugo, though. Checking the Markdown links, shortcodes, and code examples against the Japanese originals took more work than I expected.

As AI-driven development progressed, the 30‑minute CI wait became increasingly burdensome, so I revisited the validation of Omoikane.

Tue, 29 Sep 2026 10:20:00 +0900

When developing with AI coding agents such as Claude Code and Codex, you can work on implementation and research in parallel. Tasks that used to take one at a time can now be tackled multiple on the same day. However, the CI that runs after a pull request is submitted does not speed up to match your pace.

My custom browser, Omoikane (source), has a large Rust codebase, and the internal Boa component resides in a separate Cargo workspace. Testing spans Linux and macOS, various architectures, WPT, and more. Because Rust compiles based on dependencies, features, and targets, this setup especially highlights long build wait times. Even if the agent can generate the next change, the verification of previous changes keeps piling up without finishing.

How about writing end‑to‑end tests first in order to bring the AI agent development closer to “completion”?

Mon, 28 Sep 2026 12:50:00 +0900

When you have an AI agent write code, you may find that even though the problems are solved, it doesn’t feel like you are getting closer to what you want to build.

Implementation progresses. During review, issues are uncovered. Fixing one issue reveals another. Design concerns are raised, abstractions are reconsidered, tests are added, and the implementation is adjusted to make those tests pass. Each step has a justification, and the problems being pointed out are reasonably plausible.

How to Choose Between LLM, Embedding Models, Jev, and Classical NLP

Sat, 26 Sep 2026 20:30:00 +0900

I often see people treating search, classification, comparison, and judgment as tasks that can simply be handed off to an LLM. If you ask it in natural language, you get a response, and you can keep asking follow‑up questions directly. That convenience is indeed useful, and I’m prone to entrusting everything to it. As a result, it’s easy to develop an impression that an LLM can solve any problem.

On the other hand, even when using a judgment model like Jev, you can still give it tasks that aren’t suited for it. Asking it to hunt for information before the necessary data has been gathered, or to have it formulating an overall strategy before any candidates have been identified, is asking a limited‑purpose decision‑making tool to perform investigative work as well. If you only need to locate known terms, you can simply perform a string search without invoking a model at all.

Stance on AI Coding and Code Reviews

Fri, 25 Sep 2026 09:23:11 +0900

When it comes to AI coding, I think we should freely use any technology that works. Both the speed of implementation and the number of ideas we can try have changed dramatically compared to when humans wrote all the code themselves. Tasks that were once measured in hours can now be completed in a short amount of time.

On the other hand, just because more code is being generated doesn’t mean humans can review it at the same pace. Trying to keep the cycle going with “if AI writes a lot, humans must read a lot” is unsustainable.

I created ctx-sync, a CLI tool that shares development context across multiple sandboxes.

Wed, 23 Sep 2026 22:37:00 +0900

When you develop by running multiple sandboxes simultaneously, it’s convenient that each environment is isolated, but it can become unclear what the other sandboxes are doing.

For example, suppose you conduct research and decide on a design approach in one sandbox, then begin implementation in another. The new sandbox has no prior conversation, so you don’t know why that approach was chosen or what issues remain unresolved. As a result, you may end up repeating the same research or re‑examining decisions that have already been made. It can also happen that one worker unintentionally edits a file another worker is working on, causing their work to clash.

Visual Store now supports libvpx 1.12 on Debian 12 ARM64.

Wed, 23 Sep 2026 07:55:00 +0900

I updated the Visual Store .

In the previous article “Added the ability to retain judgment results in Visual Store” (linked to 2026-09-21-2.md), I wrote about the new Judgment Layer that saves the decisions and verification results before an image is opened. This time, rather than introducing a new feature, I’m addressing the issue where the default build with VP9 enabled fails to compile on Debian 12 ARM64, and I’ve revised the procedure for reporting bugs in the Visual Store Skill. (related article)

Enabled the Visual Store to retain judgment results.

Mon, 21 Sep 2026 19:55:00 +0900

I updated the Visual Store .

This time, I added a Judgment Layer that records, for each image, the decision made before actually opening the screenshot and the verification results after it is opened.

In the previous article “I created a Visual Store to prevent coding agents from hoarding images” (see 2026‑09‑16.md), I described a mechanism for saving images and retrieving only the ones needed. (related article)

Background

The Visual Store was created to store debugging screenshots locally instead of embedding them directly into conversations, so that only the necessary screenshot can be retrieved later.

Added evaluation JSONL and production‑ready features to Jev MCP.

Mon, 21 Sep 2026 15:55:00 +0900

I updated the jev-mcp .

In the previous post, I wrote that we had created an MCP server that invokes Jev, TypeSafe AI’s decision model, from Codex. Simply connecting the four decision tools doesn’t tell us whether they can be reliably used in actual coding work.

This time, we added a small JSONL file for evaluating the decision results, an evaluation CLI, telemetry for monitoring invocation status, and handling for failures. We have also expanded the Codex‑specific Skill with additional decision recipes tailored to different use cases.

I created an MCP server that extracts Codex’s decisions for Jev.

Sun, 20 Sep 2026 18:29:44 +0900

I created an MCP server called jev-mcp .

It is intended to be invoked during Codex work to call the TypeSafe AI decision model Jev. Implemented in Rust, it communicates with Codex via standard input/output.

Jev, TypeSafe AI’s decision model

Instead of handing the entire coding task over to another agent, I want to extract the small decisions that arise during the investigation.

For example, questions like “Is this file related to the current bug?” or “Which subsystem should be examined next?” While Codex continues the investigation, editing, and testing, we use Jev for the intermediate classification and evaluation.

AI