This was supposed to be a simple question.
I asked Codex: “Can you set up something that reads your Substack piece for users?”
What I meant was: does Substack already have a native listen-to-this-post feature?
What happened instead was much stranger, and much more interesting.
Codex started building.
First, it made a small local app that could take a Substack link, extract the post text, and read it aloud. Then it added a download button, so the post could become a podcast-style audio file.
At that point I had to stop and say: wait. This is cool, but it is not useful if it lives outside Substack. A reader is not going to copy a link, open another app, paste the post, and make their own audio.
So the question changed.
Not: can a reader turn this into audio?
But: can my publishing workflow automatically create an audio version when I publish something new?
That is when this turned from a toy into a workflow.
We connected it to my Substack RSS feed. We set it up to detect new posts. We added text extraction, OpenAI text-to-speech, an outbox folder, metadata, upload notes, and even a desktop shortcut so I could find the audio files later.
Then we tested it on a previous post.
It worked.
A written Substack piece became an audio file.
And here is the irony.
The first post I wanted to turn into audio was called “Who Is Better Off When AI Speeds up the Workflow?”
That piece argued that AI efficiency is not automatically a good thing. The real question is not whether AI makes a workflow faster. The real question is who benefits when it does.
Then I used AI to speed up my own workflow.
So the question applies here too.
Who is better off because this audio workflow exists?
If the answer is “the dashboard,” then this is just another way to produce more content faster. More formats. More outputs. More proof that something happened.
That is not enough.
The only reason this workflow matters is if it helps people engage with the ideas in a format they can actually use. If someone listens while walking, commuting, cooking, resting their eyes, or moving through a day when reading is not possible, then the workflow has created access. If it simply adds another production expectation to my plate, then it has recreated the problem my original post was warning about.
That is the test I want to keep in front of me:
Does this create capacity, or does it create another obligation?
Does it help the reader, or just feed the content machine?
Does it make the work more accessible, or merely faster?
That is the first “wow” for me, but it is a qualified wow.
The second “wow” came after the workflow existed.
I wanted to share the story. I wanted to explain what had happened and why it mattered.
I did not start with a blank page.
I stayed in the same working context and asked Codex to draft a bonus post about how this came to be.
That connects to something I wrote last year called “The Power of Staying in the Thread.” In that piece, I argued that when you keep work in the same AI thread, the model can use the history of the project. You do not have to re-explain the decisions, the voice, the false starts, or the goal.
I still believe that.
But this experience updated the point.
You do not always have to stay in the exact same thread. What matters is that the context can travel.
In this case, Codex knew the original question. It knew I had not meant to build a standalone app. It knew the first voices were terrible. It knew we shifted from a reader tool to a publishing workflow. It knew the API key problem. It knew the RSS feed. It knew the generated audio file. It knew I kept saying: this is not really about Substack. It is about what people can now do with AI.
So when I asked for a bonus post, I did not have to reconstruct the story.
I did not have to say: here is the whole sequence of events, here is what mattered, here is the lesson, here is the earlier post this connects to.
The context was already there.
That is context carry.
Not just staying in one thread forever. Not just memory as a vague feature. Context carry means preserving enough of the project that AI can help you move from doing the work to explaining the work.
The first surprise was that AI helped me build the audio workflow.
The second surprise was that, because the context was still available, AI could help me turn the workflow into this piece.
That distinction matters.
The audio app shows what AI can help you make.
This post shows what happens when the context of making it is still available.
You can build something, reflect on it, turn it into a story, revise the story, and even generate an audio version of the story without starting over each time.
That is not just convenience. It changes the rhythm of work.
The friction drops between idea, prototype, output, reflection, and sharing.
You do not need to begin with “I want to build software.”
You can begin with friction.
This should be easier.
This should happen automatically.
This should become another format.
This should reach people in a different way.
Then you can ask AI to help you work backward from the wish to the workflow.
And if you preserve the context, you can also ask it to help you explain what happened after the workflow exists.
That is the shift.
The question is no longer just: what can AI write for me?
A better question is:
What can AI help me make possible?
And maybe the follow-up is:
Once I make it, how can AI help me understand it, improve it, and share it?
Anthralytic is a social impact strategy and evaluation studio that asks hard questions about who AI benefits, how, why, and when.
