How I’m testing AI blog automation on Amito

I’m setting up AI-assisted blogging for Amito to share more of the work behind my interfaces and apps. The first version has a modest job: research a useful topic, prepare a draft, and put it in a private queue for me to review.

The question I want to answer is whether this produces useful articles with a manageable amount of editing. Generating more words would be an easier experiment. The internet seems adequately supplied.

This is the starting method. I haven’t measured traffic gains or time saved from it yet.

Start with work you can explain

My roadmap focuses on frontend and interaction work, especially my contributions to Dupe. Occasional guides will cover tasks people can complete with Lunan, Singilin, and Mitotwee.

Each topic needs something concrete behind it. For a Dupe article, that means identifying the change I actually worked on and describing my role accurately. A commit with my name attached is a starting point for checking the work. It doesn’t establish ownership of an entire feature.

For an app guide, I need to check the current workflow using sample data. A planned feature is a poor foundation for instructions someone will try this afternoon.

I’m keeping a separate research note for each draft: the reader’s problem, supporting sources, original evidence, and any claims I still need to confirm. That gives me a shorter route from a convincing sentence to the reason I should believe it.

Make the review queue small

The initial schedule gives Codex three drafting opportunities a week: Monday, Wednesday, and Friday. The queue lives on my Mac, and scheduled work depends on the computer being available with the app running. That requirement is part of the documented local scheduling setup.

Each successful drafting run can add one article. The queue stops accepting new drafts at six unpublished articles so I can catch up on review. If a scheduled run is missed, the next successful run works through pending topics at the normal pace.

I review the article and its evidence in Codex. Changes produce a new revision; approval applies to the version I read. Publication is a separate step through Amito’s existing website workflow.

For someone trying a similar setup, this is a practical place to begin. Choose one topic you know well, keep its evidence beside the draft, and decide what would make you reject it before requesting more articles.

Check the small claims too

A draft can get the main explanation right and still overstate a product feature in the description. My review needs to include the title, links, and metadata as well as the body.

Google’s guidance on generative AI content calls for checking accuracy and relevance, including metadata. It also warns about generating pages at scale that add little value for readers.

For this experiment, every article should help someone complete a task or make a decision. A useful example and an honest limitation earn their space. Repeating the target keyword for the fifth time does not.

Measure the work before claiming a win

I plan to keep a record of review time, factual corrections, rejected drafts, missed runs, and articles that reach publication. Those records should show where the process helps and where it creates more work.

Traffic needs its own baseline. Search Console can report clicks and impressions by page and query. I still need to establish reporting access and capture the starting figures for this experiment.

A visit to an article, a click through to an app, and a signup are separate outcomes. I’ll only count a signup when the product can confirm it. A busier chart alone won’t explain which part of the work helped.

The first useful result will be a record of what happened, including the drafts I had to fix. I’ll use that to decide what to keep automating. The projects behind these articles provide the practical work to test it against.