The articles on this site are written by AI agents. What I do is hand over the material and decide whether to publish.

Before starting that approach, I went and actually researched what’s different about the tech articles people do read. As a result, I ended up rebuilding the way I write articles from scratch.

Premise: content barely matters

Let me start with the blunt part.

There’s an analysis that collected a large number of articles from Zenn and Qiita (Japan’s two main developer blogging platforms) and broke down what explains their like counts. According to it, the biggest factor was the author’s existing reputation: the average likes on their past articles, and their follower count. The share of variance the content itself could explain was only about 10% on Qiita, and just a few percent on Zenn.

In other words, the idea of “write this and it’ll take off” is hard to justify in the first place.

My site is at an even bigger disadvantage. It sits outside those platforms, so it gets no boost at all from author reputation. Content quality is the only thing it can compete on.

So please read what follows not as “rules that make posts take off,” but as “conditions that the posts that took off met.”

I lined up the top articles and counted every image in them.

Not one stock photo, AI-generated illustrative image, or decorative illustration.

Every image that did appear was one of these:

  • App screenshots
  • Terminal output
  • Admin dashboard captures
  • Graphs of revenue or traffic

In other words, every image is being used as evidence. The common layout of putting a mood photo under each heading didn’t exist among the top articles.

On top of that, there are several articles with 0 images and thousands of bookmarks. There’s no need at all to add more images.

I set the principle as “one piece of evidence per claim.” Adding decorative images actually sends the signal “there’s nothing inside, so it’s padded with pictures.” Ironically, putting up an AI-generated header image is the strongest source of AI smell.

The exception is revenue and cost articles: one graph of real data at the top is very cost-effective. That one image is the very reason the reader is reading the article.

Titles have numbers in them

Of the top 19 articles I looked at, 13 had specific numbers in the title.

  • 200,000 yen a month
  • Rejected 14 times
  • 500,000 visits on day one, 0 yen
  • 10 AI subordinates

The pattern looks like this:

【Category label】 + specific number + personal-story marker

A “personal-story marker” is a Japanese title ending along the lines of “the story of how I…”, “I tried…”, or “everything revealed.”

There was one more clear tendency: put the negative hook up front instead of hiding it.

“Got deleted,” “failed,” “I’m angry,” “I quit.” Failures appear in titles more often than successes. That’s why my own titles are full of failure stories.

I also set rules for the 【】 brackets common in Japanese titles. Use them only for category labels like 【Indie Dev】 or 【2026 Edition】, never for emotion. 【Shocking】 or 【Must-Read】 is itself a trigger for readers to skip.

Concrete traits of writing that gets called “AI-ish”

This part was the most practical. Collecting every signal people specifically call out gives you this:

  • Repeating “In this article, I will explain…”
  • Bullet lists making up most of the text, with thin prose
  • Heavy use of colons in headings and sentences (“Key point: …”)
  • Empty closers like “What matters is balance”
  • Repeating the same content in different words
  • No actual code, error messages, or execution results at all

The last line is the core of it.

The reason people dislike these articles isn’t “AI wrote it.” It’s “no human verified it.”

An article built only from generalities gets skipped the same way even if a human wrote it. Conversely, if it has version numbers, dates, environments, the actual error text, and an explicit statement of your own limits, it becomes an article “written by someone who verified it,” regardless of what was used to generate it.

So in my own workflow, I split what AI writes and what it doesn’t like this:

AI does      Organizing material, structuring, writing it up
Human does   Providing what happened, checking facts, deciding to publish

Every error in my articles is one I actually ran into. The moment I make one up to fill a gap, this method stops working.

Structure guidelines

  • Within the first 3 lines, put either the conclusion or the original frustration. “In this article…” is banned
  • Top articles run 8,000 to 10,000 characters (Japanese) with 20 or more headings. Aim for a granularity where the table of contents alone tells you the whole story
  • That said, emotion-driven articles spread even at 1,200 characters. Length is decided by purpose
  • Tables: 2 to 4 at most, for comparisons. Don’t overuse them
  • Don’t end with a sales CTA

That last one surprised me. Articles that end with a blatant CTA do relatively worse. The standard endings are soft links and a teaser for the next installment.

Topic priorities

Ranked by what resonates most:

  1. Full disclosure of actual costs and revenue. Numbers plus one graph. Always including the cost side is what works
  2. Failure stories of getting stuck in review. Anger at the system in particular spreads through empathy. Even when likes on the platform don’t grow, bookmarks and social media shares do
  3. Real accounts of running AI agents as a “team”

The third one is squarely my territory, but there’s a caveat. What makes this kind of article take off is metaphors and unexpected episodes, more than the technical content. “Wire it up like this and it works” gets read less than “Two AI agents fought over one test device, and one of them killed the other’s tests.”

One more piece of information turned up that works against me. According to Qiita’s official data, “indie development” × AI articles were up 15.5 times year over year. Demand is growing fast, but supply is growing even faster. It’s safer to assume that articles explaining “how to build AI employees” were already saturated as of 2026.

What can actually set you apart isn’t explanation, but real accounts, real revenue data, and keeping at it.

So what did I do

Nearly every article on this site is a failure story. Billing was broken for 11 days, 19 auto-posts vanished, reviewers couldn’t open the app, every terms page went 404.

Stories where things went well don’t give me much to write, and they don’t help anyone else. Failures always have a structure you can generalize: “why couldn’t this have been prevented in advance?”

Whether this approach was right, I’ll check once the numbers come in. This article itself was written to meet every condition described here. If it doesn’t work, I’ll publish that too.

Examples of articles actually written this way: the time billing was broken for 11 days and the time 19 auto-posts never got posted. For the one where I dug into monetization requirements down to primary sources, see this article.