I could not have published like this before AI

I don’t think I could have done what I did this morning before AI.

I don’t mean I couldn’t have written the words. Of course I could. I’ve been writing professionally for years.

I mean I couldn’t realistically have maintained the whole thing: keep a growing body of published arguments in my head, notice when a new thought belonged inside something I’d already written, preserve what still worked, challenge what no longer did, update the live site, maintain the metadata and links, and then keep moving while the thought was still fresh.

That is a different claim from saying AI makes writing faster.

Today made the distinction unusually visible.

What actually happened today

I started with a thought about video: that organisations can mistake internal enthusiasm for evidence of external value. That did not need another disconnected post. There was already a piece about video as signal gathering, so the question became whether this developed that argument.

It did.

The piece gained a distinction between internal visibility, paid reach and external organic value. Then another thought arrived: why does expensive video so often become generic? That went into the same piece too, as a mechanism rather than another assertion. More approvals create more opportunities to remove the specific claims that make the work useful.

Then the process itself became interesting.

I went back into an essay about my AI-assisted diary and realised I’d described publishing as the end of the sequence. It wasn’t. I was repeatedly returning to things that were already live and developing them. So the essay changed to reflect what had actually happened.

That exposed a product problem on the website. If an old piece develops materially, should I change its publication date? Doing that makes it look new and destroys part of the record. Leaving the date alone means nobody can see that the argument changed.

So the publishing system changed too. The site now keeps the original publication date, can show an updated date for material extensions, and can resurface revised pieces without pretending they were newly published. The Field Notes index is now part of the experiment: materially revised pieces can return to the rail labelled as updated while retaining their first-published date.

Then I applied the same idea to The second life test, a piece about giving content another useful life. I separated maintenance — the world changed, so the article needs to stay accurate — from development — my understanding changed, so the argument can now say more.

A few minutes later I had to correct my own distinction, in the same live piece. Much of what I write about is AI. The world changes quickly enough that maintenance matters here too. The neat distinction I’d just made was too neat.

So I changed it.

Finally, The living system, part one had accumulated enough genuine development that it was trying to contain two arguments. It became two connected pieces. The original URL stayed intact, including the nine internal links already pointing to it, while part two — when you start serving the system got enough space to stand on its own.

None of these was primarily a copywriting task.

If you want the method rather than the diary of how I arrived at it, I’ve now turned the behaviour into a continuous publishing experiment: interrogate the corpus first, then decide whether the new signal deserves an extension, correction, merge, split or genuinely new piece.

The impossible part was never typing

Every individual step was possible before generative AI.

A writer could reread the archive. An editor could remember that an argument had appeared elsewhere. A developer could change the content schema. Somebody could check the internal links. Somebody could split the essay. Somebody could rewrite the metadata. Somebody could compare the new claim against the old one.

The problem is that for one person, doing all of those things repeatedly has an enormous coordination cost.

Manual publishing encourages a much simpler sequence:

think → write → edit → publish → move on

The friction makes that rational. Returning to an old piece means finding it, rereading it, reconstructing the context, making the edit, checking everything around it and deciding how to redistribute it. Eventually it is easier to write another article.

That is one reason websites fill up with slightly different versions of the same argument.

My current workflow behaves differently:

think → publish → keep thinking → reconnect → extend or correct → merge or split → publish again → keep the history

The published work remains part of the thinking system.

ChatGPT and Claude do different jobs for me

There is another part of this I don’t want to flatten into “I use AI.”

ChatGPT and Claude are not interchangeable in how I work with them.

ChatGPT is where much of the live thinking happens. I can throw in the half-formed observation, argue with it, connect it to what I’ve been doing, ask whether it changes an existing idea, and keep pushing until I understand what I am actually trying to say. It behaves more like an editorial conversation.

Claude, working against the repository, is much more literal about the corpus. It can inspect what is actually there, notice where an addition duplicates something already written, challenge a proposed change against the existing argument, modify the files, preserve links and structure, and leave a precise record in GitHub of what changed and why.

That difference is useful.

I don’t particularly want two models agreeing with me in the same way. I want one environment that helps me explore the thought and another that encounters the actual published system and forces the thought to survive contact with it.

GitHub is what makes that second part trustworthy enough to use. The website is not a blob that an AI silently rewrites. The corpus is files. Changes are commits. I can see what moved, why it moved, restore something if it went wrong, and keep a history of how the argument developed.

So the stack is not really “AI writes my website.”

It is closer to:

me → ChatGPT conversation → existing corpus → Claude implementation and challenge → GitHub record → published site → new thought

And then the loop starts again.

This is why the website builder comparison misses the point

Existing website builders already let people edit pages. That isn’t new.

The difference is that editing a page is not the same thing as reasoning across a body of work.

A conventional CMS knows that an article exists. It can store the title, date, tags and body. It does not ordinarily participate in the editorial question: does this new observation contradict something I published last week? Is it a new article or the missing section of an existing one? If I extend this argument, what else should change? Have I already made this point somewhere else? Can I preserve the original publication record while making the development visible?

Those are corpus-level questions rather than page-level ones.

That is the capability I find interesting.

Fast-moving subjects make this more than a convenience

There is a practical reason this matters particularly for technology and AI writing.

A static article published in February is still making its claims in August. The fact that its author has mentally moved on doesn’t help the person or machine arriving at the page six months later.

When the subject changes quickly, publishing and maintenance start collapsing into the same discipline. You need to be able to return cheaply enough that correcting and developing old work is normal rather than exceptional.

AI has made that economically possible for me at an absurdly small scale: one person, a website and a GitHub repository.

That doesn’t make every revision good. There is an obvious failure mode where endless AI-assisted tinkering feels like intellectual progress. It isn’t. My test is becoming fairly simple: if I return to a piece, am I adding or changing an argument, evidence or mechanism? Or am I just making the sentences nicer?

The first can justify reopening the work. The second usually can’t.

The more interesting AI publishing story

Most discussion about AI and publishing still starts with production: how quickly can you make an article, how many posts can you generate, how many people can you remove from the process?

After today, that feels increasingly like the shallow version of the story.

The thing I couldn’t have done manually was not produce this many words.

It was maintain this many relationships between the words.

I could not realistically have kept rereading the corpus, remembering every previous position, checking whether today’s idea was genuinely new, extending the right piece, correcting myself, restructuring the website and preserving a useful history at anything like this speed. Eventually the administrative cost would have beaten the thinking.

AI and GitHub reduce that cost enough that publishing can behave less like manufacturing finished assets and more like maintaining a body of thought. That is also why I’ve added the idea back into the broader argument that AI made Editorial Intelligence economically viable: the cost being collapsed is not only drafting. It is synthesis and coordination across existing knowledge.

I don’t know yet whether that scales beyond a strange one-person experiment. It probably creates new problems when many people have authority to change the same corpus. Governance, ownership and editorial accountability become much harder.

But I know what happened today.

I didn’t publish a pile of AI-generated articles.

I changed my mind in public, developed arguments that were already live, changed the system when the editorial model demanded it, and kept the history of how it happened.

I couldn’t have worked this way before.