Who I Write For: The Reader I Call "Kenji"
When I write this series, I hold one specific reader in mind. This chapter is about that person.
While writing, I sometimes hit a moment where I find myself wondering: "Who exactly am I writing this for?" How far should I break down technical terms? How much background knowledge can I assume the reader has? Those small judgment calls, made one after another, shape the texture of the whole piece. If my mental image of the reader keeps shifting, the writing style becomes inconsistent when I read it back.
To avoid that, I settled on a design where I fix a single, concrete person in my head.
The Reader I Have in Mind: "Kenji"
I call the main reader I have in mind for this project "Kenji" — a stand-in name for a type of person.
Kenji is somewhere in his early thirties to mid-forties, comfortable with technology, and working in a small team of roughly three to ten people. The image I have is someone like an in-house IT systems person (someone who manages and runs internal systems for a company), a freelance engineer, or a startup's first developer.
He has already started using AI in his work. He has tried ChatGPT or Claude for actual tasks. But as he starts running multiple AI tools at the same time, the question of "who controls what, and how" does not have a clean answer yet.
"When an AI makes a mistake, who is responsible?" "Where does the go / no-go decision get made? The criteria are vague, but we keep moving anyway."
I imagine those kinds of questions sitting somewhere in the back of his mind — no clear answer, just pushing forward for now.
On a day-to-day level, I picture him thinking something like this:
"I want to hand work off to AI, but I am afraid of it going off the rails." "I want to build a checking system, but I do not know how to design one." "I cannot find any Japanese-language examples of applying separation of powers (here meaning: splitting the executor, auditor, and approver roles across separate agents) to AI."
What he is hoping to get from this blog is not a clean theoretical explanation — it is a record of something that was actually run. Where the failures happened, how fixes were designed, an implementation log that includes both what worked and what did not. The kind of thing where he can read it and think: "I could probably try this myself."
Why I Fix the Target Reader
Fixing a target reader is about keeping myself consistent as a writer.
When writing, the choice of words changes depending on who is reading. Whether to include a conceptual diagram, where to put explanations of technical terms, how much shared background to assume — if I reconsider all of that each time, the decisions become endless.
Having "it just needs to reach Kenji" as a reference point makes those judgment calls faster. That is the purpose. Deciding on a reader profile is less about narrowing the audience and more about keeping my own thinking consistent from piece to piece.
There is also a structural benefit: when the target reader embodies what the audience wants to know, it becomes easier to see what each chapter should cover. If I trace what Kenji would want to know next, the order of the series takes shape naturally. That is roughly how each chapter ended up in its current position.
To Readers Who Are Not Kenji
One thing I want to say honestly.
Kenji is a design I made, and not everyone who reads this blog will fit that profile.
A younger person exploring engineering might read this as a first step toward something they want to try someday. Someone on the management side considering AI adoption might read it thinking: "If this is how they prevent failures by design, maybe there is something useful here for us." Or someone with a completely different background might engage with it in a way I have not anticipated at all.
I think all of that is fine.
In fact, if I discover that someone I had not imagined was reading this series — that itself is interesting. "It reached this kind of person too" is data, and data becomes material for the next design decision.
The Kenji profile is a reference point for me as a writer. It is not a "no one else is welcome" statement. I wrote this chapter because I wanted to be transparent about this as a design choice — something built in to keep the writing consistent, not a boundary drawn around who can read it.