Japanese developer blogs on Zenn have quietly become one of the best places to watch AI coding assistants get put through their paces in unglamorous, real-world ways. Three recent posts, taken together, sketch a useful picture of where large language models stand today when it comes to planning, coding, and turning raw data into judgment calls.
Can an LLM actually think in Japanese and build something non-trivial?
The first post describes an unusual experiment: a self-described game-development novice wanted to test whether the model Solar Pro4 could genuinely operate in Japanese and handle the kind of multi-step logic a real game requires. The chosen test case was a shiritori-style word-chain game based on the on’yomi (Sino-Japanese) readings of kanji — a game that also links to Korean hanja readings, since kanji and Korean Hanja share historical pronunciation roots. That’s a nontrivial linguistic domain: the game logic has to correctly match phonetic endings across two writing systems’ Sino-Xenic vocabulary, which is the kind of task that trips up models with shaky non-English reasoning.
What makes the workflow interesting isn’t just the output but the division of labor: Claude was used for planning and design, while Solar Pro4 handled implementation, with the entire brief and instructions written in Japanese from the start. The post effectively works as a case study in cross-model orchestration — using one model’s strengths for architecture and another’s for execution — and as a language-capability benchmark for Solar Pro4 outside of English. For teams evaluating whether newer, less English-centric models can be trusted with real logic-heavy work in Japanese, this is a concrete (if narrow) data point rather than a marketing claim.
A week with Claude Opus 5: is the upgrade worth it?
The second post tackles a question a lot of Claude users have been asking since the Claude 5 family rolled out: when does it make sense to pay the premium for Opus over Sonnet? The author ran Opus 5 as their primary daily driver for a full week starting the day it launched (July 24, 2026), coming from Sonnet 5 and, before that, Opus 4.8.
The headline anecdote is telling: a refactor spanning five files that had previously taken three back-and-forth iterations with Sonnet 5 was completed in a single session once the author switched to Opus 5. That’s the kind of qualitative jump — fewer round trips, less context re-explaining — that matters more to daily productivity than raw benchmark scores. It suggests Opus 5’s edge over Sonnet 5 isn’t just about producing marginally better code, but about maintaining coherent reasoning across a wider working set without losing the thread.
What’s notably absent from a one-week test, and worth keeping in mind, is any read on cost-efficiency at scale or how the model behaves on tasks outside code refactoring. Still, for developers weighing whether to default to the more expensive tier or reserve it for hard problems, direct before/after comparisons like this are more useful than abstract capability claims.
Getting an LLM to write the “insight,” not just the numbers
The third post shifts from coding to something adjacent but distinct: analytics writing. The problem it identifies is familiar to anyone who’s produced a monthly KPI report — pulling GA4 data into BigQuery and charting it is mechanical, but explaining why session counts moved or why conversion rate shifted is the part that actually informs decisions, and it’s the part that gets rushed or skipped when time is tight.
The approach here is to use Claude Code not just as a coding tool but as a prompt-engineering target for report generation — designing prompts specific enough that the model produces genuine analytical commentary (考察) rather than a restatement of the numbers. This is a meaningfully harder ask than typical LLM report summarization: turning a table of month-over-month deltas into causal or diagnostic language requires the model to hypothesize about underlying drivers, which is exactly the step most automated reporting tools skip.
The common thread
What connects these three posts is a pattern showing up across the Japanese dev community: people aren’t asking “can AI write code” anymore — that’s assumed. They’re testing narrower, more specific claims: can it reason correctly in a non-English, linguistically complex domain; does a model upgrade translate into fewer iteration cycles on real refactors; and can prompt design push an LLM from data description into actual analytical judgment. Each of these examples is small-scale and anecdotal on its own, but together they map out the current frontier — not whether LLMs can code or write, but how precisely their outputs can be steered toward genuinely useful, judgment-requiring work.