The prototype is yours, a small AI helper that answers policy questions, and it is on the conference room screen in front of the director who decides whether it gets funded. You type the demo question and press send. The reply usually lands in about three seconds; the spinner is past twenty. The engineer you brought for backup reaches over, opens a panel of cryptic rows beside your frozen demo, clicks one, and says the request went out but nothing came back, so the problem is on the server, not in this room. The director asks what that means. She read that verdict off one row in ten seconds, and you cannot yet read the row.
That panel is DevTools, the inspection panel built into every major browser, and each row in it is one round trip, the loop under every tap, click, and send. We will walk the loop, dissect one captured row, and end at the second hop inside every AI answer, so next time you can make the ten-second read yourself.
The round trip, step by step
Take the moment you hit send and stretch it out.
Your device packages a request. Your browser or phone wraps what the other side needs into a small structured note: your text, which conversation it belongs to, proof of who you are. The note is the request; the device sending it is the client.
The request travels. It passes machine to machine until it reaches a computer run by the company behind the product, on the territory we mapped in where software lives.
The server works. The computer receiving the request is the server. It checks who you are, loads your conversation, and sets the model generating an answer.
A response returns. Whatever the server produced comes back as the response; your device unpacks it, the screen updates, and the loop is closed.
The cargo changes, but the loop does not: a like asks the server to add one to a stored count, and a search, a checkout, and a sent message just carry different notes.
Every interaction with a connected product is a round trip: a request goes out, a computer somewhere does some work, and a response comes back.
One captured request, read field by field
Here is a row we captured in the Network tab, the part of DevTools that lists every request the page sends, right after sending one message to an AI chat; the product is generic, but the fields are universal:
Name Method Status Time
messages POST 200 4.63 s
Click the row and it unfolds to show the full address:
Request URL: https://chat.example.com/api/messages
Read it field by field.
- The URL is the destination. The part after the site's name, /api/messages, is the endpoint, the specific door on the server the request knocked on. Different actions knock on different doors, the subject of APIs, how systems talk to each other.
- The method is the kind of action. POST means here is new material to act on; GET, the other one you will meet constantly, means fetch me something.
- The status code is the verdict. 200 means it worked, codes starting with 4 mean the request was refused, and codes starting with 5 mean the server tried and failed. The row in our opening scene never got one, which told the engineer the response never arrived.
- The time is the wait. The 4.63 s ran from the request leaving to the response finishing. That number is the latency, the wait your user feels.
Every wait is distance plus work
The 4.63 s is two costs added together. Distance is travel time across the physical gap to the server, and it stays small: crossing an ocean and back takes around a tenth of a second. Work is everything the server does before it can answer. A like button is nearly all distance, because adding one to a count is barely any work, while an AI answer is nearly all work, because generating text takes seconds.
like button [distance][work] well under a second
AI answer [distance][work..................] several seconds
When a product of yours feels slow, ask which half got bigger; Monitoring, how you know it broke (and what it costs) answers that with data instead of guesses.
Why learn the loop when a tool wires it for you
The objection is fair: an AI coding tool writes all of this plumbing, and a chat can explain any row you paste into it. Neither covers the two moments that stay yours.
Approving a plan. Hand a tool your idea and its plan will say something like "add an endpoint to receive the message and return the reply." You are the one saying yes, the job Decode the technical questions that stop you gave you, and now you can picture the door being added instead of nodding at a word.
Reading a live failure. No tool stands beside you in the conference room. The read the engineer made, did the request go out and did a response come back, takes one glance and no code, and you must know the row exists before you can paste it anywhere.
Streaming is one answer arriving in pieces
Nobody watched a spinner for the full 4.63 s, because words appeared almost at once. You know the pattern from video, where a film plays long before the whole file arrives; an AI answer does the same with text. The typewriter effect is not many tiny round trips: the server starts sending while the model is still generating, and your screen paints each piece as it lands. You will fire one yourself in Make your first model call.
Streaming is one request and one response, delivered in pieces: the server starts sending before the model has finished, so you start reading sooner while the total time stays the same.
The second hop behind every AI answer
One fact is still missing: the server at chat.example.com did not generate that answer itself. Most AI products, and every product you will build in this course, rent the model from a provider, the company running it on racks of specialized machines. So the round trip you watched is only the first hop; the server turns around, becomes a client itself, and sends a request of its own to the provider. The day the product is yours, the journey looks like this:
request: user's browser --> your server --(+ API key)--> model provider
response: user's browser <-- your server <--(streamed)--- model provider
The second request carries your API key, the credential telling the provider whose account to bill. The key rides only the middle leg, between your server and the provider, and never travels to anybody's browser; why it never can is settled in the backend, where the real work happens. The latency story ends here too: most of the 4.63 s was work at the far end of the second hop.
Every AI answer you will ship is two round trips chained together: your user's browser to your server, then your server to the model provider, with the API key riding only the second leg.
Try it now
The drill takes about ten minutes and spends nothing; the tooled path spends a few cents at most. You arrive with the verdict list from where software lives: pick an app you marked remote, an AI chat is ideal.
No setup: Open the app in a desktop browser, right-click the page, and choose Inspect (menu wording varies by browser; see Sources for the current docs). Click the Network tab and expect a wall, often two hundred cryptic rows, because a modern page fires a separate round trip for every image, font, and script it loads. The wall means the tab is working, not that you broke something. Press the clear control so the list empties, then send one message; the row that appears at the top is yours. Read its four fields, URL, method, status, time, then watch the reply stream in. Before you close the panel, note one line about the slowest request in the Time column: what it was, how long, and your verdict, distance or work. You leave with that line. We keep this tab open whenever a build misbehaves; it shows at a glance whether the request went out and a response came back.
With your tools: Give Claude Code a small task, such as reading one file and summarizing it, and watch the terminal. The pause after you press enter is a request traveling to a model provider and work starting on its machines; the text that flows in afterward is the response streaming back, the same journey in your terminal. If nothing is installed yet, the Setup Clinic gets you running. In Codex or Cursor the move is the same: hand the sidebar a small task and watch the response stream into the panel.
Chapter Summary
- Every interaction with a connected product is a round trip: your device sends a request, a server does some work, and a response comes back.
- The device that sends the request is the client, and the computer that receives it and does the work is the server.
- A captured Network row reads in four fields: the URL is the destination (its path is the endpoint, the door on the server), the method is the kind of action, the status code is the verdict, and the time is the wait.
- Status codes read at a glance: 200 means it worked, codes starting with 4 mean the request was refused, and codes starting with 5 mean the server failed.
- Latency is always distance plus work. A like button is nearly all distance, an AI answer is nearly all work, so when a product feels slow, ask which half got bigger.
- Streaming is one response delivered in pieces: the server starts sending before the model has finished, so you start reading sooner even though the total time is the same.
- Every AI answer you ship is two round trips chained together, browser to your server and your server to the model provider, with the API key riding only the second leg.
- A busy page fires dozens of round trips at once, so the Network tab shows a wall of rows; clear the list, act once, and the newest row is yours.
- The first question for any misbehaving build is answered in that tab at a glance: did the request go out, and did a response come back?
- Next on the map is what both ends of this journey are written in, and how to approve a tool's pick with confidence, in Languages and frameworks: approve the pick.
Sources
- Chrome DevTools documentation, Network panel reference (last verified July 2026).
- Firefox Source Docs, Network Monitor section (last verified July 2026).
- MDN Web Docs, HTTP overview and status code reference (last verified July 2026).