How I Am Writing Blogs With Codex

Today, I was talking to my computer while pushing my newborn son around in his stroller. Yes, you read that right, I was talking to my computer.

Codex was asking me questions via voice mode as a part of my blog writing skill. I answered as if I was having a conversation with another human. The scariest part was that the conversation was natural enough that after a few questions it felt perfectly normal.

The thought of having a conversation with my computer still feels really dystopian, but in a very cool way.

That conversation became the premise for this blog. In the Codex interview for this blog, I was asked why I created the blog writing skill in the first place:

I want anything I do multiple times to be captured in skills to help with automation and time saving. I also am trying to learn and get better with AI, so these processes help me do that.

The skill is the process

The skill is really just a long Markdown file that tells Codex how I want to turn an idea into a blog on my website.

The first decision is how much work the article needs. The skill classifies it as a short update, a field note, or a developed article. This happens to be a developed article, so Codex had to interview me, build an outline, look at the older articles, create screenshots, and put the draft in Proof.

Then it works through these stages:

1. Establish the brief.
2. Gather evidence.
3. Interview me and confirm the point.
4. Shape the article and get my approval on the outline.
5. Create a pre-draft version.
6. Pass a pre-draft check before putting the article in Proof, where we then edit back and forth.
7. Edit the article with me in Proof.
8. Format the approved copy for my website.

Before the article gets to Proof, Codex organizes all of the work in one folder, which includes my interview, the sources, the outline, the drafts, the checks, and the screenshots. It keeps a version history so it is clear what I have reviewed and approved.

This is probably a little overkill in terms of process for a personal blog, but that's my engineering brain at work.

It also stops Codex from treating “write a blog” as permission to do everything at once. The first draft does not go on my website. It does not even go to Proof yet.

The first two pre-draft versions of this article came back 100% AI in Pangram. The skill kept those drafts out of Proof and sent Codex back to my interview and the other articles to get a better understanding of the types of edits I had made before and help get the blog to a more authentic place.

I do not think an AI detector proves who wrote something. I use it as a noisy warning that the article is too close to the smooth, general writing an AI tends to produce. The fix is not adding random mistakes. The fix is going back to what actually happened and what I actually said.

Where this inspiration came from

Dan Shipper and Every deserve a shoutout here.

What I liked was that they showed how they used AI, specifically Codex, to assist in their writing. The Every team collected a lot of that work in The New Rules of Writing, and Dan talked through his own process in How to Supercharge Your Writing With AI Tools.

Every also built Proof, which is where Codex and I edit these articles. It is a shared editor for people and agents. That is a much better fit for this than sending versions of a Markdown file back and forth.

Codex interviews me before it writes

The interview is how the article gets material that is mine.

Codex starts by asking a series of questions to get a better understanding of the intent of the article. It then probes me further to get specific scenarios or examples it can lean on for context.

The grocery blog did not start with a general point about automation. It started with the real cart:

okay hold on - changes needed.

I then listed nine corrections and wrote:

This was really poorly done today

Later in the same task I told Codex:

okay now take what we learned from this session and update our skill

Those messages explained the grocery process better than a clean summary would. I correct the automation where I find the problem, review the next attempt, and then tell Codex when the lesson should become part of the skill.

The email article worked the same way. Codex asked about my actual inbox, the scheduled 8:00 brief, the labels we changed, and the emails I still wanted to review myself. I asked it to include the real back-and-forth from a support issue instead of summarizing it.

For this article, I asked Codex to look at my edits on those blogs and derive examples. That gave it more than a list of preferences I made up for an interview.

My edits capture my voice

I explained how I check the writing:

I read it back to myself outloud often to see if it sounds natural from me. I have a feel for how I talk and I can sense it if its unatural. Some of the vocabulary AI choses is often not natural to me. I am not a lingiust, I am an engineer so writing is not my specialty. I dont want it to sound to polished because thats not how I speak.

Reading it out loud is the most effective way for me to test if the voice of the blog matches me. As an example, in the grocery article, Codex called the cart a “useful operating tool.” I removed “operating.” It also called the meal list a “repository.” I would never say that, so I changed it to a “list of meals.” When it tried to explain the review boundary, I gave it the sentence I wanted:

That is better, but I still need the review to catch things like this. Trust but verify.

I also changed the ending. I wanted it to say the automation gives me an hour back each week. I did not want a broad ending about humans and AI.

On the email post, I asked for a direct sentence about Dan's example making me think about my own email triage. I asked for the actual Codex replies from that thread so we could use that as evidence and context in writing that blog.

The skill saves those edits, but it does not turn every one into a permanent rule. If I keep making the same change, or tell Codex it is a preference, then it can become part of the skill.

Proof is in the editing

Once the pre-draft check passes, Codex puts the article in Proof and joins as an agent. From there we go back and forth. It reads the latest version, leaves comments when it has a question, and makes suggestions when it wants to rewrite something. If I edit the article, it reads the new version before doing anything else. I do not have a hard rule for who does which part.

I dont have hard and fast rules. We edit the blog togetehr so we both learn as we go

I do not bother fixing typos when I talk to Codex. AI understands them already, so there is no need to waste time fixing them.

The process is iterative. Codex lays the foundation and then I comb through and edit the article to feel more like me. This process can repeat many times before an article is complete. I am constantly testing it in Pangram to see how our changes are received.

This article includes pictures of that process. We took a screenshot with Codex and Proof open together and put it into the article.

The skill will keep evolving after each article or blog we write as it learns my style more and has more history to lean on. I will keep reading drafts out loud, editing them with Codex in Proof, and turning repeated work into skills. Talking to my computer still feels dystopian. Today I kept pushing the stroller and answered the next question anyway. Maybe that is the new norm.