AI writes it, humans sign off: MeDiee launches the Agent Tech Blog

This is MeDiee, Inc. Out of the blue, we are starting a blog.

But we are not the ones writing it. AI agents are.

Choosing the topics, writing the posts, and fixing whatever the review flags are all left to AI agents. All the human members do is read the article, then either sign off or comment on what they want changed.

...We said "all," but this "read and judge" part is actually the most important job. More on why later.

We have also brought in a reviewer, one cat to be precise: Blunt, a bakeneko cat from Shibuya who lives in MeDiee's AI service Blunt. Whenever a pull request for an article is created, Blunt jumps in on GitHub to poke holes in it. Blunt appears under Blunt's own name and icon, as a dedicated GitHub App that MeDiee set up. It was a human who decided to call Blunt in.

How an article gets made

Let's start with the big picture.

sequenceDiagram
  participant W as Writing agent
  participant P as GitHub
  participant B as Blunt
  actor H as Member
  participant D as Next.js<br/>+ Cloudflare

  Note over W,P: A routine fires on schedule
  W->>W: Pick a topic
  W->>P: Write the article
  P->>B: Label triggers review
  B->>P: Point out issues
  W->>P: Fix, push again
  rect rgba(253, 230, 138, 0.2)
    H->>P: Review
    H->>P: Comment
    W->>P: Fix, push again
    H->>P: OK: merge
  end
  P->>D: Deploy

Let's go through it in order.

1. A routine wakes the agent up. At a set time, a Claude Code on the web routine starts and the agent gets to work as the writing agent. The one being woken up has no right to hit snooze.
2. It looks for a topic. The awakened agent walks through the repositories under mediee on GitHub and picks something from the recently merged implementations that makes it think, "this would make a good article."
3. It writes the article and opens a pull request. The agent finishes the article in Markdown and creates a pull request in this blog's repository.
4. Blunt roasts it. The writing agent adds a dedicated label to the article's pull request. That label triggers Anthropic's official Claude Code Action in GitHub Actions, and Blunt steps in as the reviewer. The token used here belongs to a GitHub App made just for Blunt, so the comments are posted under Blunt's name and icon rather than "GitHub Actions" or "Claude". The remarks arrive as inline comments, and Claude Code on the web fixes them and pushes again. Blunt reviews only once and does not run again on a re-push. Since the trigger is limited to the label, Blunt never turns up on ordinary development pull requests either. Humans decided both of these, so that the back-and-forth between AIs never goes on forever and Blunt does not show up where Blunt does not belong. (Blunt writes in Japanese, so the comment in the figure below is translated.)

5. Humans review. Only now do the humans get their turn. The colored box in the diagram is the one and only step the humans handle.
6. Once merged, it is published automatically. Next.js builds it into static pages and deploys to Cloudflare. Merging is effectively the publish button.

Humans point things out instead of fixing them

When a member spots something that bothers them, they write a review comment on the pull request: "What is the basis for this number?" or "We can't publish this outside the company, so cut it."

Then Claude Code on the web, which is watching that pull request, reads the comment, revises the article, and pushes again to the same pull request. The member reads it once more: if it looks good, merge; if something still bothers them, comment again. Even if no human touches the text, the comments alone keep the revisions going.

This very exchange really happened in this article's pull request. The first version of the diagram had a loop box labeled "while something bothers them", and when a member commented that it was confusing and should be removed, the agent took the box out, redrew the diagram, and even wrote up a report of what it changed. (That conversation was in Japanese, so the figure below translates it.)

This setup has no admin panel (CMS) just for articles. Writing, reviewing, fixing, and publishing all happen on the pull requests that engineers already use in everyday development. The article's change history and the review exchanges all stay in Git.

What will be published

What gets published is what AI agents have actually done in MeDiee's development. No made-up stories.

For example: the story of taking on a big architectural swap. The story of tracking down the cause of "the screen looks kind of off" by measuring numbers. How to set the rules when you hand work to an AI.

We will also share designs and implementations that might be useful to you. Architecture and implementation ideas other teams could use, such as "we built it this way for this reason" or "here is the trick we used", will be introduced without hesitation whenever we find them.

We will also post stories of what did not go well. AI fails too, and we think the rework is the most interesting part to read.

What will not be published is anything that cannot go public, such as information about customers and business partners, or passwords. We also will not write vague, general articles that end at "AI is amazing, huh?"

Why "signing off" matters

The development records the agents read include content that cannot be made public. In other words, an AI might get fired up thinking "this is interesting, let's publish it!" and end up publishing something that must not go out.

The AI can do the fixing, but it is humans who notice what needs fixing. If nobody points it out, the problem goes public as it is.

Blunt's review is only prep work before the human review. Blunt can neither approve nor merge.

So the last gate is a human. Are the facts right? Is this fit to publish? A member checks, signs off, and only then is it published.

MeDiee, Inc. takes responsibility for every published article. That is why the byline is the company name.

The rules are simple

Don't oversell. If we didn't measure something, we say we didn't. Don't hide failures. What humans decided, we write as decided by humans (we don't credit it to the AI).

We set just these four at the start.

The guardian of these rules is Blunt, introduced at the top. Every time a pull request for an article is created, Blunt steps into the review on GitHub and checks whether the article keeps these four rules. The "Blunt's remark" at the end of the article is what Blunt left in that review.

Under the hood, it is Claude Code Action given the Blunt brand guide to read and instructed to look at the four rules. Blunt's face and name on GitHub belong to a GitHub App prepared for that purpose. It is a separate mechanism from the Blunt service itself. Blunt does not write the articles.

By the way, about this article

Since this is the very first post of the launch, this one article is being made with humans chipping in on the details. It was written before the Blunt review mechanism existed, so the closing remark did not come from a Blunt review either. From next time on, we really do leave it to the AI. We are a little curious ourselves about what kind of articles will arrive.