When I started using AI to build software, I thought mostly about the AI model.
Was I using ChatGPT or Claude?
Was I using Codex or Claude Code?
Which one was better at reasoning?
Which one was better at coding?
I paid much less attention to another question:
Where is the AI actually doing the work?
That question became important after two projects I was building behaved very differently.
For my website, Codex worked with the project on my Mac. It could modify the website files, and I could run and test those same files locally before deciding whether to commit them.
For Project X, Claude Cowork could also work with project files and create technical components. But when it executed code, some of that work happened inside an isolated environment rather than directly inside the normal environment on my Mac.
That difference eventually mattered.
Project X involved PostgreSQL. Cowork initially built and tested the database inside its isolated environment. Later, when that database needed to become part of the persistent project on my Mac, its state had to be transferred out.
I followed the instructions and things worked.
But I did not really understand why.
Terms such as terminal, shell, CLI, GUI, sandbox, virtual machine, localhost, local and cloud started appearing.
You do not need to become a systems engineer to use these tools.
But once AI starts reading files, running programs, manipulating data or building software for you, it helps to understand where its hands are actually working.
Start with the brain and the hands
The first distinction that helped me was separating the AI's intelligence from the environment where actions happen.
The AI model is the brain.
It might decide:
Open this file.
Change these lines.
Run this test.
Query this database.
But something still needs tools and permission to actually perform those actions.
I think of those tools as the AI's hands.
And the hands have to work somewhere.
That somewhere can be my computer, an isolated environment on my computer, or a machine somewhere in the cloud.
Local means the work is happening on my computer
If an AI agent operates locally, its tools work in relation to my actual computer.
That was essentially the arrangement for my website.
The repository already existed on my Mac.
When Codex changed a file, that file changed in the local project.
I could run the site, inspect it in the browser and eventually record the approved changes in Git.
There was no separate finished website waiting somewhere else to be copied back.
The version I was testing was already my local working copy.
GUI and terminal: two doors into the same room
Another distinction I needed was the difference between using a graphical application and using the terminal.
I now think of them as two doors into the same room.
The room is the project on my Mac.
One door is a graphical user interface, or GUI.
With Codex, I can communicate in natural language, review changes and work with the project through a graphical application.
The terminal gives me another way to interact with the same local environment.
For example:
npm run dev
starts the website locally.
And:
git status
shows me which files have changed.
The GUI and terminal are not two copies of the website.
They are different interfaces around the same project.
I could work on one part through a graphical coding-agent interface and later work on the same repository through a command-line coding agent.
The files do not care which interface produced them.
There is one important qualification.
The project files may be the same while the conversation context is not.
A new coding-agent session can read the same repository without automatically inheriting all the reasoning from the previous conversation.
That is why the project-memory method from the previous article still matters.
The two doors enter the same room, but they do not necessarily carry the same conversation through them.
Terminal, shell and CLI are related but different
The command-line side has several terms that are easy to confuse.
Terminal
The terminal is the text-based window where I type commands.
Shell
The shell is the program behind that window that interprets what I type.
So, simply:
Terminal = the window
Shell = the command interpreter
CLI
CLI means command-line interface.
A CLI is a program designed to be operated from the command line.
Git has one.
npm has one.
Coding agents can have one.
So I might:
open a terminal
↓
use the shell
↓
launch a CLI program
And if that CLI program is an AI coding agent, I may still talk to it in natural language.
The command line does not necessarily mean that I personally have to write the code.
Cloud means the work is happening on another computer
The word cloud makes this sound more mysterious than it is.
A cloud computer is still a computer.
It is simply not sitting on my desk.
A remote AI environment might contain:
- a copy of my project;
- temporary files;
- programming languages;
- command-line tools;
- a temporary database;
- and whatever else the task requires.
But it is not automatically the same environment as my Mac.
If work happens there, the result eventually has to be transferred, synchronized, restored, merged or otherwise brought into the persistent project I actually use.
Neither local nor cloud execution is automatically better.
They simply create different working arrangements.
A virtual machine is another computer, even when it lives inside mine
A virtual machine, or VM, is a software-created computer that behaves as though it were a separate physical computer.
It has:
- its own operating system;
- its own running programs;
- its own view of files;
- its own idea of what
localhostmeans.
A VM may run physically on my Mac, or on a remote server.
In either case, software inside the VM behaves as though the VM is its computer.
That separation can be useful because an AI can experiment inside the VM without automatically receiving unrestricted access to everything on my real machine.
A sandbox is a boundary, not necessarily a VM
A sandbox simply means a program is operating under restrictions.
An AI coding agent might be allowed to read and write inside one project while being restricted from modifying unrelated parts of the computer.
A VM can provide strong isolation, but a sandbox does not necessarily require a complete virtual machine.
For me as a user, the most useful question is therefore not:
Which sandboxing technology is this?
It is:
What can this AI reach, and where are its commands actually running?
Seeing my folder does not mean seeing my whole computer
This distinction became important in Project X.
Imagine my Mac contains:
a project folder
and
a PostgreSQL database server running as a program.
Cowork may be allowed to read and write files in the project folder.
But suppose the Python code Cowork creates runs inside a separate VM.
That Python program is executing on the VM's computer.
Access to selected project files does not automatically give programs inside the VM access to every other program running on my Mac.
That was the distinction I had not understood:
File access is not the same thing as access to the whole machine.
Giving someone a document from my office does not give them a key to every room in the building.
A live database is not just another file
That explains why PostgreSQL became important.
I initially thought:
If Cowork can see my files, why can't it simply use the PostgreSQL database on my Mac?
Because PostgreSQL is not simply another document in the folder.
It is a running service.
A CSV can be opened or copied.
A database server is a program waiting for other programs to connect to it.
To reach it, software has to connect to the particular environment where the database is running.
And that is where localhost becomes useful.
“Localhost” means the machine this program is running on
Suppose PostgreSQL is running on my Mac.
A program running directly on my Mac can use:
localhost
to mean:
this Mac.
Now suppose Cowork runs Python inside a separate VM.
From inside that Python program:
localhost
means:
this VM.
It does not mean my Mac outside the VM.
So even if the VM is associated with my Mac and can exchange selected files with it, software inside the VM still sees the VM as its own computer.
That finally explained why Project X needed a more complicated database arrangement.
How Project X's PostgreSQL database moved
There were really two stages.
Stage one: build inside the AI environment
At the beginning, Cowork helped reason through the data, establish the logic and design the database.
PostgreSQL was created inside Cowork's isolated environment and developed there until it reached a useful state.
The flow was roughly:
understand the business
↓
design the database
↓
create PostgreSQL in the isolated environment
↓
build and test
But the VM was not where I wanted the long-term database to live.
The persistent copy needed to move onto my Mac.
Stage two: transfer the database state
The AI created a database dump.
I think of a dump as a photograph of the database at a particular moment.
The live database is the thing itself.
The dump contains enough information to recreate that state elsewhere.
So:
PostgreSQL inside the AI environment
↓
create dump
↓
move the dump through project files
↓
restore it into PostgreSQL on my Mac
Now the project had a persistent database on my own machine.
Later, if Cowork needed to work with the latest database state, the dump could serve as the bridge in the other direction:
current Mac database
↓
create dump
↓
AI environment restores a working copy
↓
AI works and tests
↓
create updated dump
↓
approved state returns to the Mac
Once I understood that these were separate computers from the software's point of view, the process stopped looking arbitrary.
Why not simply let AI work directly on everything?
That would certainly be simpler in some situations.
A locally operating coding agent may have fewer boundaries to cross.
But fewer boundaries also change what a mistake can affect.
The closer an AI works to the real environment, the more directly it may be able to modify files, use local services, run commands or affect a live database.
Isolation creates friction.
It can also contain mistakes.
The lesson is not that one arrangement is always better.
It is that I should understand which arrangement I have.
Four questions I now want answered
Once an AI starts doing serious work, I want to know:
Where is the AI executing the work?
My computer, an isolated environment, or the cloud?
What can that environment reach?
Files? Other programs? A database? The network?
Which copy is persistent?
My real working project, or something temporary?
How does the result become part of my actual project?
Is it already there, or must it be transferred, restored, merged or committed?
Those questions would have saved me considerable confusion in Project X.
The product name does not answer the question
It is too simplistic to say:
OpenAI works locally.
or:
Claude uses virtual machines.
A provider may offer several products and execution modes.
The useful question is:
Where is this particular agent doing this particular piece of work?
That determines what it can see, what it can affect and how its result becomes part of my project.
And it leads directly to the next question in this series.
Knowing what an AI can technically do still does not tell me what I want it to be responsible for doing.
Capability and responsibility are different things.
That is where the human has to make the next decision.
When I started using AI to build software, I thought mostly about the AI model.
Was I using ChatGPT or Claude?
Was I using Codex or Claude Code?
Which one was better at reasoning?
Which one was better at coding?
I paid much less attention to another question:
Where is the AI actually doing the work?
That question became important after two projects I was building behaved very differently.
For my website, Codex worked with the project on my Mac. It could modify the website files, and I could run and test those same files locally before deciding whether to commit them.
For Project X, Claude Cowork could also work with project files and create technical components. But when it executed code, some of that work happened inside an isolated environment rather than directly inside the normal environment on my Mac.
That difference eventually mattered.
Project X involved PostgreSQL. Cowork initially built and tested the database inside its isolated environment. Later, when that database needed to become part of the persistent project on my Mac, its state had to be transferred out.
I followed the instructions and things worked.
But I did not really understand why.
Terms such as terminal, shell, CLI, GUI, sandbox, virtual machine, localhost, local and cloud started appearing.
You do not need to become a systems engineer to use these tools.
But once AI starts reading files, running programs, manipulating data or building software for you, it helps to understand where its hands are actually working.
Start with the brain and the hands
The first distinction that helped me was separating the AI's intelligence from the environment where actions happen.
The AI model is the brain.
It might decide:
Open this file.
Change these lines.
Run this test.
Query this database.
But something still needs tools and permission to actually perform those actions.
I think of those tools as the AI's hands.
And the hands have to work somewhere.
That somewhere can be my computer, an isolated environment on my computer, or a machine somewhere in the cloud.
Local means the work is happening on my computer
If an AI agent operates locally, its tools work in relation to my actual computer.
That was essentially the arrangement for my website.
The repository already existed on my Mac.
When Codex changed a file, that file changed in the local project.
I could run the site, inspect it in the browser and eventually record the approved changes in Git.
There was no separate finished website waiting somewhere else to be copied back.
The version I was testing was already my local working copy.
GUI and terminal: two doors into the same room
Another distinction I needed was the difference between using a graphical application and using the terminal.
I now think of them as two doors into the same room.
The room is the project on my Mac.
One door is a graphical user interface, or GUI.
With Codex, I can communicate in natural language, review changes and work with the project through a graphical application.
The terminal gives me another way to interact with the same local environment.
For example:
npm run dev
starts the website locally.
And:
git status
shows me which files have changed.
The GUI and terminal are not two copies of the website.
They are different interfaces around the same project.
I could work on one part through a graphical coding-agent interface and later work on the same repository through a command-line coding agent.
The files do not care which interface produced them.
There is one important qualification.
The project files may be the same while the conversation context is not.
A new coding-agent session can read the same repository without automatically inheriting all the reasoning from the previous conversation.
That is why the project-memory method from the previous article still matters.
The two doors enter the same room, but they do not necessarily carry the same conversation through them.
Terminal, shell and CLI are related but different
The command-line side has several terms that are easy to confuse.
Terminal
The terminal is the text-based window where I type commands.
Shell
The shell is the program behind that window that interprets what I type.
So, simply:
Terminal = the window
Shell = the command interpreter
CLI
CLI means command-line interface.
A CLI is a program designed to be operated from the command line.
Git has one.
npm has one.
Coding agents can have one.
So I might:
open a terminal
↓
use the shell
↓
launch a CLI program
And if that CLI program is an AI coding agent, I may still talk to it in natural language.
The command line does not necessarily mean that I personally have to write the code.
Cloud means the work is happening on another computer
The word cloud makes this sound more mysterious than it is.
A cloud computer is still a computer.
It is simply not sitting on my desk.
A remote AI environment might contain:
- a copy of my project;
- temporary files;
- programming languages;
- command-line tools;
- a temporary database;
- and whatever else the task requires.
But it is not automatically the same environment as my Mac.
If work happens there, the result eventually has to be transferred, synchronized, restored, merged or otherwise brought into the persistent project I actually use.
Neither local nor cloud execution is automatically better.
They simply create different working arrangements.
A virtual machine is another computer, even when it lives inside mine
A virtual machine, or VM, is a software-created computer that behaves as though it were a separate physical computer.
It has:
- its own operating system;
- its own running programs;
- its own view of files;
- its own idea of what
localhostmeans.
A VM may run physically on my Mac, or on a remote server.
In either case, software inside the VM behaves as though the VM is its computer.
That separation can be useful because an AI can experiment inside the VM without automatically receiving unrestricted access to everything on my real machine.
A sandbox is a boundary, not necessarily a VM
A sandbox simply means a program is operating under restrictions.
An AI coding agent might be allowed to read and write inside one project while being restricted from modifying unrelated parts of the computer.
A VM can provide strong isolation, but a sandbox does not necessarily require a complete virtual machine.
For me as a user, the most useful question is therefore not:
Which sandboxing technology is this?
It is:
What can this AI reach, and where are its commands actually running?
Seeing my folder does not mean seeing my whole computer
This distinction became important in Project X.
Imagine my Mac contains:
a project folder
and
a PostgreSQL database server running as a program.
Cowork may be allowed to read and write files in the project folder.
But suppose the Python code Cowork creates runs inside a separate VM.
That Python program is executing on the VM's computer.
Access to selected project files does not automatically give programs inside the VM access to every other program running on my Mac.
That was the distinction I had not understood:
File access is not the same thing as access to the whole machine.
Giving someone a document from my office does not give them a key to every room in the building.
A live database is not just another file
That explains why PostgreSQL became important.
I initially thought:
If Cowork can see my files, why can't it simply use the PostgreSQL database on my Mac?
Because PostgreSQL is not simply another document in the folder.
It is a running service.
A CSV can be opened or copied.
A database server is a program waiting for other programs to connect to it.
To reach it, software has to connect to the particular environment where the database is running.
And that is where localhost becomes useful.
“Localhost” means the machine this program is running on
Suppose PostgreSQL is running on my Mac.
A program running directly on my Mac can use:
localhost
to mean:
this Mac.
Now suppose Cowork runs Python inside a separate VM.
From inside that Python program:
localhost
means:
this VM.
It does not mean my Mac outside the VM.
So even if the VM is associated with my Mac and can exchange selected files with it, software inside the VM still sees the VM as its own computer.
That finally explained why Project X needed a more complicated database arrangement.
How Project X's PostgreSQL database moved
There were really two stages.
Stage one: build inside the AI environment
At the beginning, Cowork helped reason through the data, establish the logic and design the database.
PostgreSQL was created inside Cowork's isolated environment and developed there until it reached a useful state.
The flow was roughly:
understand the business
↓
design the database
↓
create PostgreSQL in the isolated environment
↓
build and test
But the VM was not where I wanted the long-term database to live.
The persistent copy needed to move onto my Mac.
Stage two: transfer the database state
The AI created a database dump.
I think of a dump as a photograph of the database at a particular moment.
The live database is the thing itself.
The dump contains enough information to recreate that state elsewhere.
So:
PostgreSQL inside the AI environment
↓
create dump
↓
move the dump through project files
↓
restore it into PostgreSQL on my Mac
Now the project had a persistent database on my own machine.
Later, if Cowork needed to work with the latest database state, the dump could serve as the bridge in the other direction:
current Mac database
↓
create dump
↓
AI environment restores a working copy
↓
AI works and tests
↓
create updated dump
↓
approved state returns to the Mac
Once I understood that these were separate computers from the software's point of view, the process stopped looking arbitrary.
Why not simply let AI work directly on everything?
That would certainly be simpler in some situations.
A locally operating coding agent may have fewer boundaries to cross.
But fewer boundaries also change what a mistake can affect.
The closer an AI works to the real environment, the more directly it may be able to modify files, use local services, run commands or affect a live database.
Isolation creates friction.
It can also contain mistakes.
The lesson is not that one arrangement is always better.
It is that I should understand which arrangement I have.
Four questions I now want answered
Once an AI starts doing serious work, I want to know:
Where is the AI executing the work?
My computer, an isolated environment, or the cloud?
What can that environment reach?
Files? Other programs? A database? The network?
Which copy is persistent?
My real working project, or something temporary?
How does the result become part of my actual project?
Is it already there, or must it be transferred, restored, merged or committed?
Those questions would have saved me considerable confusion in Project X.
The product name does not answer the question
It is too simplistic to say:
OpenAI works locally.
or:
Claude uses virtual machines.
A provider may offer several products and execution modes.
The useful question is:
Where is this particular agent doing this particular piece of work?
That determines what it can see, what it can affect and how its result becomes part of my project.
And it leads directly to the next question in this series.
Knowing what an AI can technically do still does not tell me what I want it to be responsible for doing.
Capability and responsibility are different things.
That is where the human has to make the next decision.
Continue reading