Editing files does not make an application run. A program must be started, kept running, and connected to a place where you can see its output. This is why a terminal tab that looks busy is often one of the most important parts of your workspace.

A process is a program that is currently running

When you run a development command, such as the project command for starting a website, you create a process. The process reads the project files and keeps working until it finishes, fails, or you stop it.

Project filesStart commandRunning processTerminal logsBrowser preview at localhost

The terminal where the server is running is occupied on purpose. Do not type unrelated commands into it. Open another tab for Codex, Claude, Git, or tests.

Ports: the numbered doors on your computer

Your computer can run several local services at once. A port is the numbered door that tells the browser which service to reach.

http://localhost:3000  → one local app
http://localhost:4321  → another local app

The number does not matter as much as the idea. If two programs try to use the same port, one will fail. The log will usually say the port is already in use. You can stop the earlier process, choose a different port, or ask the agent to explain the safest fix.

Logs are the running story of the app

Logs are messages produced by a process: started successfully, page requested, database unavailable, test failed, port busy, or configuration missing.

Do not paste only the last red line into an AI chat. Give the agent the surrounding log and explain what you were trying to do. The context before an error often explains the cause.

Stop a process intentionally

Most terminal servers stop when you press Control + C in the tab that is running them. That is different from closing your browser. Closing the browser hides the preview; it may not stop the process.

When a process will not stop or behaves strangely, ask the agent to identify it first. Do not kill random processes because they have technical-looking names.

Errors are a debugging starting point, not an instruction

An error message is evidence about one failed operation. It is not proof that the first fix an AI proposes is correct. Ask the agent to explain the likely cause, name the file or service involved, and propose the smallest reversible test. If the error says a configuration value is missing, do not immediately invent a value; find where the project documents that value and whether it belongs in local or cloud settings.

The best debugging loop is: reproduce the problem, collect the relevant log, form a small hypothesis, test one change, and verify the result. That is slower than random command retries for one minute, and much faster than random command retries for an hour.

Your local test loop

1. Start the app in one terminal. 2. Open the localhost address in the browser. 3. Use another terminal or VS Code to make a focused change. 4. Watch the logs after the change. 5. Refresh and test the behavior yourself. 6. Stop the server when you are done.

Practical exercise

Ask an AI to identify the project's local start command without running it. Then approve it, open the localhost page, and ask the AI to explain the first ten lines of the log. Stop the process intentionally when finished.

Check your understanding

1. What is a running process? 2. Why does a local app have a port number? 3. Why should the server have its own terminal tab? 4. What information should you preserve when asking an AI to diagnose an error?