When I started building my website, the way I worked with AI was cumbersome.
I would explain what I wanted in ordinary language to ChatGPT. ChatGPT would help me make sense of the problem, turn my explanation into a more precise prompt, and then I would paste that prompt into Codex.
Codex would do the coding.
Whatever Codex produced, I would bring back to ChatGPT. Sometimes I wanted ChatGPT to explain what Codex had done. Sometimes I wanted it to evaluate the result. Sometimes I wanted it to help me decide what to do next. And often I wanted it to write the next prompt for Codex.
Then I would go back to Codex.
And repeat.
For a small task, this is manageable. For a website that has taken months to build and has stretched across dozens of separate sessions, it becomes tedious very quickly.
But after trying a very different way of working on another project, I am starting to wonder whether some of that inefficiency was doing something useful.
Perhaps the question is not simply how to make AI work faster.
Perhaps it is how to stop AI from moving faster than my own understanding of the work.
The slow way I learned to build with AI
For the website, the division of labour between ChatGPT and Codex became quite clear.
ChatGPT was my thinking partner.
I could describe something badly, incompletely or in completely non-technical language, and ChatGPT could help me work out what I really meant. It could point out missing details, explain technical choices and turn my description into something much more precise for Codex.
Codex was the builder.
Once we had agreed on what should be done, I gave Codex the instruction and let it work on the actual website.
Then came the review loop.
Codex would tell me what it had changed. I would inspect the website, bring the relevant output back to ChatGPT, discuss what happened, decide whether it was correct and work out what should happen next.
The process was slow.
It was also tedious.
There was a lot of copying and pasting between ChatGPT and Codex. If I pasted a Codex response into ChatGPT, I sometimes had to explain what I wanted ChatGPT to do with it. Simply pasting the output did not always mean ChatGPT understood that I wanted it reviewed, explained or turned into the next instruction.
And every new section of the website created another loop.
Think.
Prompt.
Build.
Inspect.
Copy.
Discuss.
Prompt again.
Over a project lasting months, the number of handoffs becomes substantial.
There is also a larger problem with using separate AI sessions on a long project: each one has its own context.
My ChatGPT session needs to understand what Codex is doing. Codex needs to understand the current state of the website. A new session needs enough information from the previous session to continue correctly. The actual files need to remain consistent with all of those conversations.
Keeping everything aligned is work in itself.
Yet the result of that cumbersome process has been surprisingly valuable.
I understand my website.
I do not mean that I could sit down and recreate all of the code myself. I could not.
But I understand why most of the major pieces exist. I understand what we were trying to solve when we built them. I know where to look when something needs changing. I can usually explain why we made a particular decision.
That happened because almost every meaningful part of the website passed through a cycle like this:
decide → build → inspect → understand → decide again
The website progressed, but my understanding progressed with it.
At the time, I mostly saw the copying and pasting as inefficient overhead.
I am less sure about that now.
I removed the friction, and discovered what it had been doing
When I started another project for a client, I deliberately tried to work differently.
I will call it Project X.
Project X is much less obvious than building a website.
With a website, even if I do not know how to code one, I roughly know what a website is supposed to do. I know what pages are. I know what navigation is. I know what a form is. I can look at a screen and decide whether it makes sense.
Project X started much further upstream.
The client has years of operational data and an existing way of running the business. Before building anything, I first needed to understand how the business actually worked.
What decisions were being made?
What information was being used?
Which parts of the existing process were logical and repeatable?
Which parts depended on judgement?
What should go into a database?
What should eventually become software?
In other words, I did not begin Project X by knowing what I wanted the software to look like.
I first had to work out what should be built.
That was one reason I chose Claude Cowork rather than going directly into Claude Code.
The other reason was much more practical.
I did not want to repeat the constant copying-and-pasting workflow I had used for the website.
I wanted the AI I was thinking with to be able to read and write files in the project folder, maintain records of what had been decided, and give future sessions something concrete to read.
A serious project cannot live inside one conversation.
It may take a month, several months or longer. It may involve tens of sessions. Decisions made in week two can become important again in week eight.
So I wanted the project itself to hold the memory.
Cowork was much better suited to that style of working.
But it introduced another problem.
The boundary between thinking about the work and doing the work became much less obvious.
As we worked through Project X, Cowork did not only help me reason about the client's data and operations. It also began producing technical parts of the system: a PostgreSQL database, a console for data input, dashboards and other components.
From my point of view, the transition could feel seamless.
We would discuss a problem.
Cowork would reason about it.
Something would be created.
It would be tested.
Then we would move to the next thing.
This was far more efficient than my website workflow.
It was also much easier for me to continue without fully understanding what had just happened.
At one point, I found myself following instructions involving database dumps, different execution environments and moving state between systems without really understanding why the project had been set up that way.
I could follow the instructions.
The system worked.
But I could no longer explain the build with the same confidence that I could explain the website.
That bothered me.
The difference was not that Cowork was necessarily doing bad work.
The problem was that the project was beginning to progress faster than my understanding of the project.
That is when I started looking differently at the friction in my original ChatGPT-and-Codex workflow.
The extra handoff had forced a checkpoint.
Codex could finish a task, but before the next major piece was built, I would usually return to ChatGPT.
That meant I had to stop.
I had to inspect what happened.
I had to ask questions.
I had to decide whether I understood it.
And I had to agree on what came next.
What looked like inefficiency had also been a mechanism for keeping me involved.
A waveform reminded me why the extra thinking layer matters
A much smaller experiment brought the same issue back into focus.
I wanted to create a simple animation of a waveform moving across a screen.
I could picture what I wanted very clearly.
I assumed I could simply describe it.
I tried.
The result was wrong.
I refined my description.
Still wrong.
I tried again.
What seemed extremely simple inside my head turned out to be surprisingly difficult to express precisely enough for the AI to reproduce.
Eventually I went to Google Gemini and asked it to turn my requirement into a proper prompt.
The difference was striking.
My own explanation might have been around ten lines.
Gemini's version expanded the idea into many individual requirements. It described details I had not thought to specify explicitly: the shape, movement, direction, spacing, proportions, behaviour and visual constraints.
When I used that prompt, the result improved substantially.
It still was not perfect.
But the experiment reminded me of something I had been taking for granted throughout the website project.
There is a difference between:
knowing what I want
and
knowing how to specify what I want.
ChatGPT had been bridging that gap for me.
Looking back, I think my thinking partner was performing at least three different jobs.
The first was translation.
I could describe an outcome in my own language, and the AI could turn it into something much more explicit for the execution agent.
The second was advice.
When the coding agent produced something technical, I could ask another AI to help me understand what had happened, whether it made sense and what choices I actually had.
The third was a checkpoint.
The act of moving between two systems created a natural point at which execution stopped and thinking resumed.
I had originally thought of the first two as useful and the third as an inconvenience.
I am beginning to think the third may be just as important.
The question is no longer which AI I should use
It would be easy to turn this into a comparison between ChatGPT, Codex, Claude Cowork or Claude Code.
I do not think that is the interesting question.
The tools are changing too quickly anyway, and their capabilities increasingly overlap.
The more useful question is:
Where should I deliberately separate thinking from execution?
For a serious project, the process may need several distinct stages.
I may begin with only a vague understanding of the problem.
I need to think through it.
I need to examine the evidence.
I need to decide what should be built.
Then, at some point, I need to stop.
I need to understand the proposed solution well enough to agree with it.
Only then should implementation continue.
And after implementation, there may need to be another stop.
What was built?
Why was it built that way?
What did we learn?
What should happen next?
The workflow could therefore look something like this:
unclear problem → think → investigate → decide → stop and understand → build → stop and understand → continue
Different AI products may perform several of those jobs.
That may actually be the problem.
When the boundary between them disappears, the AI can move from helping me think to building something before I have consciously noticed that an important decision has already been made.
For a small experiment, that might not matter.
That is not the kind of work I am interested in.
The projects I am working on can take months.
The requirements change.
Problems that were not visible at the beginning emerge later.
The work spans many sessions.
Decisions accumulate.
Parts built today may need to be modified six months from now.
And ultimately I remain responsible for the result.
For that kind of work, I do not only want AI to produce something that works.
I want to understand what we are building.
I want to understand why we are building it.
And I want to understand enough of how it works that I remain in control of the project.
That does not mean I need to become the programmer, database engineer or AI agent doing the implementation.
But it may mean I should be careful about removing every bit of friction from the process.
Some friction is simply waste.
But some friction creates a place for human understanding to catch up with machine execution.
I do not yet know exactly where that boundary should sit.
For now, I am increasingly convinced that the goal should not be to make AI-assisted work as seamless as possible.
The better goal may be to decide where I want the seams to remain.
When I started building my website, the way I worked with AI was cumbersome.
I would explain what I wanted in ordinary language to ChatGPT. ChatGPT would help me make sense of the problem, turn my explanation into a more precise prompt, and then I would paste that prompt into Codex.
Codex would do the coding.
Whatever Codex produced, I would bring back to ChatGPT. Sometimes I wanted ChatGPT to explain what Codex had done. Sometimes I wanted it to evaluate the result. Sometimes I wanted it to help me decide what to do next. And often I wanted it to write the next prompt for Codex.
Then I would go back to Codex.
And repeat.
For a small task, this is manageable. For a website that has taken months to build and has stretched across dozens of separate sessions, it becomes tedious very quickly.
But after trying a very different way of working on another project, I am starting to wonder whether some of that inefficiency was doing something useful.
Perhaps the question is not simply how to make AI work faster.
Perhaps it is how to stop AI from moving faster than my own understanding of the work.
The slow way I learned to build with AI
For the website, the division of labour between ChatGPT and Codex became quite clear.
ChatGPT was my thinking partner.
I could describe something badly, incompletely or in completely non-technical language, and ChatGPT could help me work out what I really meant. It could point out missing details, explain technical choices and turn my description into something much more precise for Codex.
Codex was the builder.
Once we had agreed on what should be done, I gave Codex the instruction and let it work on the actual website.
Then came the review loop.
Codex would tell me what it had changed. I would inspect the website, bring the relevant output back to ChatGPT, discuss what happened, decide whether it was correct and work out what should happen next.
The process was slow.
It was also tedious.
There was a lot of copying and pasting between ChatGPT and Codex. If I pasted a Codex response into ChatGPT, I sometimes had to explain what I wanted ChatGPT to do with it. Simply pasting the output did not always mean ChatGPT understood that I wanted it reviewed, explained or turned into the next instruction.
And every new section of the website created another loop.
Think.
Prompt.
Build.
Inspect.
Copy.
Discuss.
Prompt again.
Over a project lasting months, the number of handoffs becomes substantial.
There is also a larger problem with using separate AI sessions on a long project: each one has its own context.
My ChatGPT session needs to understand what Codex is doing. Codex needs to understand the current state of the website. A new session needs enough information from the previous session to continue correctly. The actual files need to remain consistent with all of those conversations.
Keeping everything aligned is work in itself.
Yet the result of that cumbersome process has been surprisingly valuable.
I understand my website.
I do not mean that I could sit down and recreate all of the code myself. I could not.
But I understand why most of the major pieces exist. I understand what we were trying to solve when we built them. I know where to look when something needs changing. I can usually explain why we made a particular decision.
That happened because almost every meaningful part of the website passed through a cycle like this:
decide → build → inspect → understand → decide again
The website progressed, but my understanding progressed with it.
At the time, I mostly saw the copying and pasting as inefficient overhead.
I am less sure about that now.
I removed the friction, and discovered what it had been doing
When I started another project for a client, I deliberately tried to work differently.
I will call it Project X.
Project X is much less obvious than building a website.
With a website, even if I do not know how to code one, I roughly know what a website is supposed to do. I know what pages are. I know what navigation is. I know what a form is. I can look at a screen and decide whether it makes sense.
Project X started much further upstream.
The client has years of operational data and an existing way of running the business. Before building anything, I first needed to understand how the business actually worked.
What decisions were being made?
What information was being used?
Which parts of the existing process were logical and repeatable?
Which parts depended on judgement?
What should go into a database?
What should eventually become software?
In other words, I did not begin Project X by knowing what I wanted the software to look like.
I first had to work out what should be built.
That was one reason I chose Claude Cowork rather than going directly into Claude Code.
The other reason was much more practical.
I did not want to repeat the constant copying-and-pasting workflow I had used for the website.
I wanted the AI I was thinking with to be able to read and write files in the project folder, maintain records of what had been decided, and give future sessions something concrete to read.
A serious project cannot live inside one conversation.
It may take a month, several months or longer. It may involve tens of sessions. Decisions made in week two can become important again in week eight.
So I wanted the project itself to hold the memory.
Cowork was much better suited to that style of working.
But it introduced another problem.
The boundary between thinking about the work and doing the work became much less obvious.
As we worked through Project X, Cowork did not only help me reason about the client's data and operations. It also began producing technical parts of the system: a PostgreSQL database, a console for data input, dashboards and other components.
From my point of view, the transition could feel seamless.
We would discuss a problem.
Cowork would reason about it.
Something would be created.
It would be tested.
Then we would move to the next thing.
This was far more efficient than my website workflow.
It was also much easier for me to continue without fully understanding what had just happened.
At one point, I found myself following instructions involving database dumps, different execution environments and moving state between systems without really understanding why the project had been set up that way.
I could follow the instructions.
The system worked.
But I could no longer explain the build with the same confidence that I could explain the website.
That bothered me.
The difference was not that Cowork was necessarily doing bad work.
The problem was that the project was beginning to progress faster than my understanding of the project.
That is when I started looking differently at the friction in my original ChatGPT-and-Codex workflow.
The extra handoff had forced a checkpoint.
Codex could finish a task, but before the next major piece was built, I would usually return to ChatGPT.
That meant I had to stop.
I had to inspect what happened.
I had to ask questions.
I had to decide whether I understood it.
And I had to agree on what came next.
What looked like inefficiency had also been a mechanism for keeping me involved.
A waveform reminded me why the extra thinking layer matters
A much smaller experiment brought the same issue back into focus.
I wanted to create a simple animation of a waveform moving across a screen.
I could picture what I wanted very clearly.
I assumed I could simply describe it.
I tried.
The result was wrong.
I refined my description.
Still wrong.
I tried again.
What seemed extremely simple inside my head turned out to be surprisingly difficult to express precisely enough for the AI to reproduce.
Eventually I went to Google Gemini and asked it to turn my requirement into a proper prompt.
The difference was striking.
My own explanation might have been around ten lines.
Gemini's version expanded the idea into many individual requirements. It described details I had not thought to specify explicitly: the shape, movement, direction, spacing, proportions, behaviour and visual constraints.
When I used that prompt, the result improved substantially.
It still was not perfect.
But the experiment reminded me of something I had been taking for granted throughout the website project.
There is a difference between:
knowing what I want
and
knowing how to specify what I want.
ChatGPT had been bridging that gap for me.
Looking back, I think my thinking partner was performing at least three different jobs.
The first was translation.
I could describe an outcome in my own language, and the AI could turn it into something much more explicit for the execution agent.
The second was advice.
When the coding agent produced something technical, I could ask another AI to help me understand what had happened, whether it made sense and what choices I actually had.
The third was a checkpoint.
The act of moving between two systems created a natural point at which execution stopped and thinking resumed.
I had originally thought of the first two as useful and the third as an inconvenience.
I am beginning to think the third may be just as important.
The question is no longer which AI I should use
It would be easy to turn this into a comparison between ChatGPT, Codex, Claude Cowork or Claude Code.
I do not think that is the interesting question.
The tools are changing too quickly anyway, and their capabilities increasingly overlap.
The more useful question is:
Where should I deliberately separate thinking from execution?
For a serious project, the process may need several distinct stages.
I may begin with only a vague understanding of the problem.
I need to think through it.
I need to examine the evidence.
I need to decide what should be built.
Then, at some point, I need to stop.
I need to understand the proposed solution well enough to agree with it.
Only then should implementation continue.
And after implementation, there may need to be another stop.
What was built?
Why was it built that way?
What did we learn?
What should happen next?
The workflow could therefore look something like this:
unclear problem → think → investigate → decide → stop and understand → build → stop and understand → continue
Different AI products may perform several of those jobs.
That may actually be the problem.
When the boundary between them disappears, the AI can move from helping me think to building something before I have consciously noticed that an important decision has already been made.
For a small experiment, that might not matter.
That is not the kind of work I am interested in.
The projects I am working on can take months.
The requirements change.
Problems that were not visible at the beginning emerge later.
The work spans many sessions.
Decisions accumulate.
Parts built today may need to be modified six months from now.
And ultimately I remain responsible for the result.
For that kind of work, I do not only want AI to produce something that works.
I want to understand what we are building.
I want to understand why we are building it.
And I want to understand enough of how it works that I remain in control of the project.
That does not mean I need to become the programmer, database engineer or AI agent doing the implementation.
But it may mean I should be careful about removing every bit of friction from the process.
Some friction is simply waste.
But some friction creates a place for human understanding to catch up with machine execution.
I do not yet know exactly where that boundary should sit.
For now, I am increasingly convinced that the goal should not be to make AI-assisted work as seamless as possible.
The better goal may be to decide where I want the seams to remain.
Continue reading