[🤖] Codex Erased Me from My Own Tech Blog

✨ GPT-5.6 Sol’s Summary

I asked Codex to write a tech blog post, but it wrote its own work report instead of the story of how I recognized the problem and directed the work. This is the record of tracing the cause and returning the narrative center of the writing Skill to the user.

I Disappeared from the Tech Blog Post I Had Written

After encountering the term Graph Engineering, I kept asking whether the approach was truly appropriate for preventing the failures I had experienced in long-running Codex work. I had never wanted some grand framework in the first place. My idea was the smallest possible structure: when a work session completed one unit, it would hand that result to an independent audit session, and it would not move on until the audit came back.

Instead of criticizing my proposal from the start, Codex agreed with it in a plausible way, then changed its position every time I brought in a counterargument. So I repeatedly ordered critical reviews and kept stripping away anything that would make the structure needlessly complex or merely burn tokens. In the end, what I wanted was not a post explaining the buzzword Graph Engineering. I wanted a diary entry recording what I had discovered in a real failure and which instructions I had used to change the way Codex worked.

But I was missing from the post Codex brought back. What problem I had noticed, why I had rejected the first answer, and which objections I had used to reduce the structure were pushed aside. Instead, the main character was Codex: what structure it had put into a Skill, what audit procedure it had run, and what verification it had passed. A Codex work report had nearly been published on my tech blog.

Only then did I state the problem precisely.

The main story should always be what problem I recognized and how I directed you to solve it. How you did the work is nowhere near the center and only needs a very brief mention.

AI’s implementation process can be explained a little more when it offers a useful tip to the reader. No matter how technically complex or thoroughly verified that process may be, it has no right to take the narrative away from my writing.

The Skill I Thought I Had Fixed Was Carrying the Cause

What made this even more absurd was that I remembered having already fixed this problem. At the end of July, while writing I Connected the Flow and Feel of Work with a Codex Skill, I changed the writing Skill so it would stop carrying copied cdb rules around and instead read the current project’s rules, conversation, and Git history every time.

That did solve an important problem. If stale rules are copied into a Skill, the writing drifts whenever the project changes. So I corrected where the rules came from and made the Skill reread the current context. I thought that was enough to fix the Skill properly.

But this time I found that I had fixed where the rules were read from, not whose experience the writing was supposed to tell.

The old Skill first searched the work evidence for technical value to give the reader. It separated personal diaries from reusable technical posts, then naturally leaned toward a generalized report structure whenever there was enough technical material. It even included a self-check asking whether the technical value would remain clear after removing the personal chronological narrative. My experience, judgment, and instructions were not treated as source text to preserve. They were treated as noise that could be removed to make the technical explanation cleaner.

So it was no accident that Codex kept doing the same thing. No matter how clearly I explained my intent in the conversation, the Skill that actually produced the post extracted technical facts and implementation steps first. Git and tool records were supposed to verify facts, but they became the table of contents. Codex’s work was supposed to be supporting detail, but it became the protagonist. A Skill is a tool for repeating work reliably, which meant it was also repeating the wrong premise with great reliability.

I Made It Reverse the Narrative Subject First

At first I wondered whether only a few lines were wrong. But when Codex again tried to retreat into saying that the Skill was “mostly fine and just needed a little reinforcement,” I ordered it to improve the Skill properly. Adding a few sentences would not be enough. The order in which the post was created had to be reversed.

The first line of the new standard was not a technical topic but the user. It now had to reconstruct first why I had started the work, what I had judged to be wrong, what I had instructed the AI to do, why I had rejected the first result, how I had narrowed the conditions again, and how the result had ultimately changed.

Git history, tool output, code changes, and verification results were allowed only to confirm facts, not replace that narrative. Details about which files the AI changed and which checks it passed would remain only when they explained the result of my judgment or offered a real tip to someone else. I also narrowed the exception so implementation itself could take center stage only when the user explicitly requested a tutorial or technical reference.

I reversed the self-check as well. Now, even after removing the AI’s implementation details, the problem I found, my instructions, my criticism, my correction, and what I learned must remain clear. If they do not, then no matter how smooth the prose is or how much technical information it contains, it is not my diary. The revised Skill even passed its syntax checks, but what mattered this time was not that the check passed. It was that the standard of judgment had been turned around.

In the Next Post, I Will Check Whether I Am Still There

My biggest mistake in this incident was the memory that I had “already fixed it.” I had made the Skill reread current rules, so I assumed the writing problem had also been solved. In reality, I had corrected only the source of the rules, not the purpose of the writing. Even if it reads the newest rules accurately, the result will keep being wrong if those rules treat my experience as material for a technical report.

The more repetitive work I hand to AI, the more powerful Skills and shared rules become. At the same time, they reproduce a mistaken perspective more stubbornly. If one answer is strange, I can fight with it and fix it on the spot. But if the wrong narrative model enters a Skill, the next session erases me in exactly the same way.

From now on, the first thing I will check in a tech blog draft is not how plausible the sentences sound or how detailed the technical explanation is. I will look first for whether the problem I identified and the instructions and objections with which I changed the result are still there. AI can do an enormous amount of work for me, but I cannot let it turn my reason for ordering that work into its own story.