Japan’s Zenn platform, a hub for developer writing similar to Dev.to, has recently surfaced three unrelated posts that, read together, sketch a surprisingly coherent picture of how individual developers are actually using AI coding assistants like Claude Code in 2024-2025. None of the three authors set out to write a trend piece. One was job-hunting, one was running a controlled experiment on testing discipline, and one was trying to stop manually juggling three publishing platforms. But stacked side by side, their experiences say more about the current state of AI-assisted development than most industry analyses do.
The portfolio problem: when “I built tools for four years” isn’t enough
The first case is the most human. A developer named tnakamoto describes losing his job after years as an in-house systems engineer, then applying to over 150 companies across three months of job hunting without a single offer. His diagnosis wasn’t lack of skill but lack of demonstrable output — internal tooling built for one employer doesn’t translate into a public portfolio. His response was to build something visible: a résumé-generation app for engineers, inspired by an idea he found on the ideation platform ideee, framed specifically as “エンジニアの職務経歴書サポート” (resume support for engineers).
This is a small story, but it’s a familiar one for anyone who’s worked exclusively on closed-source internal tools. The interesting part isn’t the app itself — it’s what it implies about the current job market: verifiable, public shipping has become a harder requirement than it used to be, and AI-assisted development lowers the barrier to producing that evidence quickly. A four-year track record inside a company now counts for less than a working weekend project anyone can click through.
The TDD cost didn’t disappear — it just moved
The second article tackles something more technically substantive: whether AI-driven development actually solves the classic objection to test-driven development. TDD’s value proposition has never been controversial — nearly everyone agrees tests plus implementation produce better code. The problem has always been that paying both costs (writing tests, writing implementation) is hard to justify in an estimate, and solo developers routinely skip tests entirely because “it’s just me, I can keep it in my head.”
The author, hontsuke, tested an appealing hypothesis: if Claude Code is doing most of the implementation work now, maybe the TDD tax effectively disappears, since the AI can burn through test-writing overhead that used to cost a human developer real hours. The framing of the piece — cost didn’t vanish, it “turned into tokens” — is the sharpest insight here. It’s a useful corrective to a common assumption in AI-development discourse right now: that offloading work to an LLM converts a time cost into something close to free. In practice, it converts one currency (developer-hours) into another (token spend, review time, prompt iteration), and the exchange rate isn’t always favorable. TDD with an AI pair may still be worth doing, but the honest accounting is that you’re paying for it in a different unit, not skipping payment altogether.
This matters beyond the individual anecdote because it pushes back against a narrative that’s easy to fall into: that AI coding tools make previously “too expensive” best practices suddenly free. They don’t. They shift the bottleneck from typing speed to review bandwidth, token budgets, and the discipline to actually check what the model produced.
Automating the unglamorous half of technical writing
The third piece, from becchi78, is a systems-design story rather than a philosophical one. The author built “BlogForge,”: a personal project using Claude Code’s SKILL feature to take a single GitHub Issue and turn it into a Zenn article draft, a note.com manuscript, and an X (Twitter) announcement — chaining thirteen individual skills together under one orchestrator skill. Crucially, the two steps left to a human are note publishing and the pull-request review of the Zenn draft — the two points where judgment about accuracy, tone, or confidentiality actually matters.
This is a small but telling design decision. It’s not “AI writes everything, human proofreads at the end” — it’s a pipeline where automation handles sequencing, formatting, and cross-posting mechanics, while a human retains veto power exactly at the two junctures where mistakes would be costly (a published typo mistake is cheap; a leaked confidential detail or a factually wrong technical claim is not). That’s a more mature automation pattern than most “AI does my blog now” projects, which tend to automate either everything or nothing.
What ties these together
None of these three developers work at an AI company or write about AI as their beat. They’re solo engineers solving their own immediate problems — needing a portfolio, wanting cheaper tests, wanting fewer manual publishing steps — and AI coding tools happen to be the material they’re building with now, the way a previous generation might have reached for a framework or a CI pipeline. The common thread isn’t hype; it’s normalization. Claude Code and similar tools have quietly become default infrastructure for individual developers in Japan’s indie scene, used pragmatically rather than evangelistically, with costs, limits, and human checkpoints built in rather than assumed away.