Your Coding Agent Says 404. Now What? HTTP Status Codes for Vibe Coders

It is 9:30 on a Monday. Four developers on a full-stack web team are at stand-up. Listen in for a minute, and count the numbers.

Avery (front end): "Checkout works locally, 200s across the board. On staging, the cart call comes back 401."

Sam (back end): "That's the token. The staging key rotated on Friday, so as far as the API knows, you're not signed in. If it were a 403, I'd be worried about roles."

Avery: "Also, the old promo page is a 404 now."

Riley (DevOps): "On purpose. Marketing renamed it. I'll add a 301 to the new offers page, so old links and search engines follow it."

Sam: "Heads-up: the nightly import is getting 429s from the payment provider. We're hammering them. I'm adding a back-off."

Jordan (full stack): "Bigger one. Saturday night we had a burst of 502s, then 504s."

Riley: "The app container ran out of memory. The load balancer was fine; the thing behind it stopped answering. I restarted it and we're back to 200s. We also served 503s for about two minutes during the deploy, which is expected."

Jordan: "And the sign-up form now returns 422 when the email is missing, so the page can highlight the field. It used to throw a 500."

Sam: "Good. A 500 means we blew up. A 422 means you sent something we understood but can't accept."

Avery: "So: fix the token, add the redirect, back off on the 429s, watch for 5xx tonight. Done."

Eleven different numbers in two minutes, and nobody opened a file. Each number told the team which part of the system to look at before anyone touched the code. If you followed all of it, you already speak HTTP. If you did not, that is the gap this essay closes, because your coding agent talks to you in exactly the same numbers.

What a status code is

An HTTP status code is a three-digit number a server sends back with every response to say how the request went. Your browser, your app and your coding agent all receive it, usually in a first line such as HTTP/1.1 200 OK. The codes are defined in RFC 9110, the HTTP Semantics standard, and MDN Web Docs keeps a readable reference of every one.

What about HTTPS? HTTPS is HTTP sent through an encrypted connection. The status codes are exactly the same: a 404 over HTTPS means what a 404 over HTTP means. When the encryption itself fails, for example because a certificate expired, you get no status code at all, only a browser warning or a connection error.

Read the first digit first

You do not need to memorize sixty codes. The first digit names the class, and the class tells you where to look.

1xx, informational: the server is still working on it. You will almost never see these. 2xx, success: it worked. 3xx, redirection: what you want is somewhere else, and the browser usually follows on its own. 4xx, client error: something is wrong with the request, such as the address, the key or the data you sent. 5xx, server error: the server received a fine request and failed to handle it.

“4xx: look at what you sent. 5xx: look at the server that answered.”

The codes you will actually meet

2xx: it worked

200 OK is the everyday success. 201 Created means something new was saved, such as a new account after sign-up. 204 No Content means it worked and there is nothing to send back, which is common after a delete. One warning: 200 means the server finished the request, not that the result is right. An API can return 200 with an error message inside, and a page can return 200 and still be blank. Read the body too.

3xx: go somewhere else

301 Moved Permanently and 302 Found send the visitor to a new address, for good or for now. 307 and 308 do the same but keep the request exactly as it was, so a form submission stays a form submission. 304 Not Modified means your copy is still current, so use what you have cached. A real example: I recently renamed the setup installer my CSE 642 students download, and the old file name now answers 308 and points to the new one. Every link already shared still works.

Even the standards site does this. While researching this essay, the short address of RFC 9110 answered 301 and sent me to its new page.

4xx: fix the request

400 Bad Request: the server could not read what you sent, such as broken JSON. 401 Unauthorized: despite the name, it means unauthenticated. The server does not know who you are, because the sign-in, key or token is missing, wrong or expired. 403 Forbidden: the server knows who you are and still says no, so the fix is a permission, not a new key. 404 Not Found: nothing at that address. 405 Method Not Allowed: the address exists, but not for this kind of request, such as reading a page that only accepts form submissions.

409 Conflict: the request clashes with what is already there, such as signing up with an email that is already registered. 422 Unprocessable Content: the server understood the request but the data breaks a rule, such as a missing required field. 429 Too Many Requests: slow down. You hit a rate limit, and the response often says how long to wait. When an AI model provider answers 429, your app is calling it faster than your plan allows.

5xx: fix the server

500 Internal Server Error: the server's own code crashed. The cause is in the server log, never in the status code. 502 Bad Gateway: a server in front, such as a load balancer or proxy, got a bad answer from the app behind it. 503 Service Unavailable: the server is overloaded, starting up, or down for a deploy or maintenance, and often recovers on its own. 504 Gateway Timeout: the server in front waited for the app behind it, and the app was too slow to answer.

And one for fun: 418 I'm a teapot comes from an April Fools' joke standard published in 1998. RFC 9110 now reserves the number as unused, so no real server needs it, but developers still smile when they see it.

When your coding agent says 404

Back to the question that started this. You ask your coding agent to run the app and test a page, and it reports: the endpoint returns 404. Here is what that means. The server is up, the connection worked, and the server answered you. It just has nothing at that exact address. That is good news: a 404 is a server telling you something. Compare it with connection refused, which means nothing is listening at all.

The common causes, in the order I check them:

1. A typo in the path. /api/user is not /api/users, a trailing slash can matter, and on most servers /About is not /about.

2. The wrong server. Your app runs on port 3002, but the agent called port 3000, where another project answered.

3. The route does not exist yet, or the file is in the wrong folder. Many web frameworks build their addresses from where files sit, so a page in the wrong folder lives at a different address.

4. The server is running the old version. A development server may read its list of pages when it starts, so a page added afterwards answers 404 until a restart. It happened to me while building the downloads for my course, and a restart fixed it.

5. It is not deployed yet. It works on localhost and returns 404 on the live site, because the change is not committed, not pushed, or the deploy is still running. When I renamed that installer, production answered 404 for the new name for several minutes. Nothing was broken. The new version simply had not arrived.

6. A deliberate 404. Some services answer 404 instead of 403 so they do not reveal that something private exists. GitHub, for example, shows 404 for a private repository you cannot see. Check that you are signed in before you conclude it is missing.

Ask your coding agent better questions

"It doesn't work, fix it" invites the agent to guess, and a guessing agent rewrites code that was fine. Give it the number and ask it to look in the right half of the system first. Prompts like these work in any Coding Agent App:

"You got a 404 from GET /api/users. List the routes this app defines and compare them with the URL you called. Don't change anything yet."

"Show me the full request and response, including the status line and headers, so I can see which server answered."

"It's a 500. Read the server log, show me the first error, and explain the cause before you change any code."

"We're getting 401 on staging but not locally. Without showing me the key, check whether the staging key is set and still valid."

Notice the last one. Never paste a key or password into a prompt. Ask the agent to check that it exists, not to show it.

From vibe coder to AI-native developer

A vibe coder accepts whatever the agent reports and types "try again". An AI-native developer reads the number, knows which half of the system it points to, and gives the agent a sharper instruction. The difference is not typing code by hand. It is knowing what the agent is telling you, so you can judge its work instead of hoping.

You can practice this today, free: the HTTP and HTTPS Foundations deck walks through requests, responses and status codes, and shows you how to see the status line yourself. If you lead a team that is adopting coding agents and want to know where they will pay off first, the AI Transformation Assessment is a private session that names the use cases worth building.