Turning AI Work into a Workflow from Logs to Translation Review#
How can we use AI better?
That is a big question in itself. There are countless things to think about: how to write prompts, how to choose tools, how to use different models, and how to break work down.
But when I brought the question back to my own repository, the things I could try right away became much more concrete.
For this blog, I have started building a flow where I save interactions with AI as logs and write Japanese posts from those logs. I can also see the next part of the workflow taking shape: extracting Japanese posts into gettext .po files, machine-translating them, and then using both AI and human review to turn them into natural English.
In this session, the goal was not to copy external AI usage tips as-is, but to turn them into something I could immediately adopt in this repository.
As a result, I ended up refining the following flow.
Log sessions with AI
Write Japanese articles from logs
Have a human review the post
Generate translation targets with gettext
Machine-translate it
Have AI and a human revise it into natural English
What I want to do is not flashy. But if I want to avoid getting lost each time I work through the process, fixing these plain workflow steps in place is surprisingly effective.
What I Thought First#
My first concern was: “How can I incorporate AI know-how into this blog workflow?”
At that point, the repository already had several pieces in place.
export_sessions.py allows you to export VS Code / Copilot Chat sessions as Markdown.
docs/agents/ai-log-blog-writer.md contains instructions for agents to write articles from logs.
translate-po-ja-en.py can assist with machine translation for English .po files.
On the Sphinx side, there are gettext tasks, and I can run the translation and build flow with rye run doit gettext and rye run doit doc.
In other words, the parts were already there.
However, having the pieces and being able to use them reliably every time are two different things.
When turning logs into posts, simply accepting an AI summary as-is can mix facts and speculation together.
In translation, machine-translated text can look plausible at first glance while still drifting from the Japanese source text or breaking technical terms.
So the focus this time was not to “expand the range of work handed to AI,” but to “create a structure that makes AI output easier for humans to review.”
Create a Checklist for Turning Logs into Posts#
The first thing added was docs/agents/log-extraction-checklist.md.
This is a checklist to look at before writing an article from AI logs.
The main review points were as follows.
Can I state what I wanted to do in one sentence?
Can I explain why I investigated it?
Is there a clear source of friction or confusion?
Are the things I tried organized chronologically?
Are the things I learned separated from the unresolved points?
Is there at least one next action left to try?
I think these perspectives matter a lot when turning logs into posts.
If I leave a conversation log with AI as-is, it is pulled along by the order of the conversation. But readers do not want a verbatim reproduction of that conversation.
What readers want to know is why I started the investigation, where I got stuck, what I tried, how far I got, and what still remains.
The log contains the raw material. But to make it into a post, that material has to be rearranged into a structure for readers.
For that reason, I also added a self-check prompt to the checklist that separates “facts,” “speculation,” and “unconfirmed items.”
This was a very practical addition for me. It lets me do more than ask AI to extract material for a post: I can also ask AI to critique the extracted material once more.
Instead of trusting AI output as-is, I can have AI inspect it once, and then have a human review it.
This order makes human review a little easier.
Create an Entry Point for Translation Review#
The next thing I organized was the translation workflow.
I added two new files: docs/agents/po-validation-guide.md and docs/agents/translation-workflow.md.
translation-workflow.md summarizes the broad flow from a Japanese post to English publication.
The flow is as follows.
rye run doit gettext
rye run python translate-po-ja-en.py <対象.po>
rye run doit intl_validate
rye run doit doc
The key point in that flow is intl_validate.
I added a new task to dodo.py so the state of English .po files can be checked mechanically.
The task mainly checks three things:
Untranslated entries where
msgstris emptyTranslations that still have
#, fuzzyEntries where
msgidandmsgstrare still the same
The report is written to docs/_build/_intl/validation-report.md.
At first, I thought a simple summary would be enough, but partway through the session we started talking about wanting to see priorities as well.
So I added Priority score and Priority columns based on the counts of untranslated, fuzzy, and source-identical entries.
This is groundwork before asking AI to fix anything.
The hardest part of translation review is not knowing where to start. If everything has the same weight, each review becomes heavy.
First, mechanically identify risky areas, then start with the highest-priority files.
After that, I can use the viewpoints in po-validation-guide.md to check meaning alignment, terminology consistency, natural English, and preservation of technical terms.
With this flow, machine translation can be used as a first draft while still narrowing down the places a human should check before publication.
Keep Human Review at the Center of the Workflow#
I think the quietly important point this time was that I did not remove “human review.”
When thinking about AI usage, it is tempting to increase automation.
It becomes tempting to leave log storage, article writing, translation, and translation review to AI as much as possible.
But for this blog, the Japanese draft is the source of truth. The English version is a translated version, and checks of meaning and reasons for changes need to be recorded in Japanese.
Given that premise, it is better to separate the parts left to AI from the parts that humans should judge.
For example, when turning logs into posts, AI is good at organizing events chronologically and extracting discussion points. On the other hand, humans should check questions such as: “Do I really agree with that conclusion?” “Is this the right level of detail to publish as a post?” “Have any unresolved concerns been erased?”
The same is true for translation.
AI can suggest revisions toward natural English. However, those revisions still need to be checked against the Japanese source text to confirm that they preserve the original intent and do not break technical proper nouns or commands.
The documents I created this time are not meant to distrust AI.
Rather, I think they are meant to bring AI output into a form that humans can review more easily, so that AI can continue to be used.
The Flow I Wanted to Demonstrate#
At the end of the session, we talked about demonstrating the whole flow using this exchange itself as the subject.
The assumed flow was as follows.
Save logs with
export_sessions.pyWrite Japanese articles from saved logs
Have a human review the post
Create translation targets with
rye run doit gettextMachine-translate with
translate-po-ja-en.pyCheck untranslated or suspicious parts with
intl_validateRevise it into natural English using
po-validation-guide.mdCheck the build with
rye run doit doc
I also organized which files to look at later when I need to remember how to do the same thing again.
When turning logs into posts, I should look at docs/agents/ai-log-blog-writer.md and docs/agents/log-extraction-checklist.md.
To recall the translation flow, I should look at docs/agents/translation-workflow.md.
To recall the translation review viewpoints, I should look at docs/agents/po-validation-guide.md.
To check the actual commands and tasks, I should look at dodo.py and translate-po-ja-en.py.
At that point, we also discussed creating a one-page runbook for the demonstration.
However, as far as the logs show, docs/agents/session-demo-runbook.md was never actually created.
In other words, what was completed this time was the setup of the checklist, the translation review guide, the translation workflow, and the validation task. The demonstration runbook remained as a useful next item to add.
What I Learned#
The lesson this time was that AI usage does not continue just by “remembering one useful prompt.”
At least for my own blog workflow, it seems more effective to set up the whole flow like this.
Keep the input
Have AI organize it
Validate AI’s organization
Revise it into a form a human can accept
Translate it
Check the translation mechanically
Finally, have a human confirm the meaning
The number of places where I use AI is increasing. At the same time, the places where humans need to look are becoming clearer.
Rather than saying automation has not progressed, it feels more accurate to say that the footing for putting automation into the workflow is taking shape.
Especially for a personal blog like this one, rules such as “the Japanese source text is authoritative,” “the English version is treated as a translation,” and “reasons for changes are recorded in Japanese” mean that I cannot publish AI output as-is.
That’s why checklists and verification reports are so effective.
If I know what to look at, how far to check, and what order to follow each time, there is less unnecessary hesitation around using AI itself.
What to Do Next#
If I do this next, I want to start with this topic and actually run the flow all the way through.
I will finalize this post as the Japanese source text, update gettext, machine-translate the English .po file, check the intl_validate report, and continue through revisions into natural English.
After that, it would be useful to add docs/agents/session-demo-runbook.md so I can refer back to it later.
For now, the steps are still split across several files. That is not bad by itself, but on the day of a demonstration, a one-page runbook would make it easier to avoid getting lost.
This session was not an abstract discussion of AI usage. It was work that moved the workflow of my own repository forward a little.
Leave logs, turn them into posts, review, translate, and review again.
If I keep developing this sequence, the work with AI itself will become material for the next post.
Article information
- Author:
mtakagishi
- Publication date:
2026-05-31