In Network you see “POST /api/save 500”. What does it mean?

A server error: check the server logs. Code 500 means an error on the server side. 404 would be a wrong address, 401 or 403 an access problem.

What's best to tell the agent about a bug?

The whole error, the steps and what you expected. With the full error, the steps and the expected result, the agent sees what broke and how it should work. With “it's broken” it can only guess.

The agent “fixed” a bug by deleting the login check. What do you do?

Roll back and ask it to find the real cause. Without the login check, anyone can write into other people's data. The error vanished, but the problem got worse: you need the cause, not a removed safeguard.

Bugs: reading the error

Lesson 21 of 26 in the course “Vibe coding”. Free, with animations and a quiz.

Where errors live

A bug is a mistake in a program. Example: in your workout tracker you tap “Save” and nothing happens. Errors hide in three places. The Console in DevTools, the browser's developer tools (F12 on Windows, Cmd+Option+I on Mac): red lines from the page's code. The Network tab in the same place: every request the page sends to the server. And the logs on your host: a record of what the server and the build did.

Network and status codes

You open Network, tap “Save” and see the line from the diagram: “POST /api/save 500”. POST is a request that sends data. /api/save is an address on your server. 500 is the status code. Cheat sheet: 200 all good, 404 not found (wrong address), 401 and 403 no access (not logged in, or not allowed), 500 server error. So the button isn't the problem: go check the server logs.

Recipe: from bug to fix

Step 1: reproduce the bug on purpose and write down the steps. Step 2: copy the whole error, from the console or the logs. Step 3: give the agent the error, the steps and what you expected. Step 4: write “first explain the cause, don't touch the code yet”. Step 5: the fix and your own check. Step 6: commit. Sending the whole error came up in the lesson on briefing AI; this is the full loop.

Trap: a “fix” by deleting

An agent can “fix” a bug by simply removing whatever gets in the way. Example: saving failed at the check that the user is logged in. The agent deletes that check. The error is gone, but now anyone can write into other people's workouts. Agents also sometimes delete a failing test or hide the error. Read the diff: the red line “check removed?” in the diagram is your cue to ask “why?”.

Stuck in a loop? Roll back

Fifth attempt, and it only got worse: the agent fixes one thing and breaks another. Stop. Roll back to the last working commit, like the “rollback” arrow in the diagram. Start a new session: the old one is cluttered with failed attempts, and the agent gets tangled in them. Describe the task again, smaller: not “fix saving” but “save one workout with a date”. A small step is quicker to fix.

Check yourself

In Network you see “POST /api/save 500”. What does it mean?
Correct answer: A server error: check the server logs. Code 500 means an error on the server side. 404 would be a wrong address, 401 or 403 an access problem.
What's best to tell the agent about a bug?
Correct answer: The whole error, the steps and what you expected. With the full error, the steps and the expected result, the agent sees what broke and how it should work. With “it's broken” it can only guess.
The agent “fixed” a bug by deleting the login check. What do you do?
Correct answer: Roll back and ask it to find the real cause. Without the login check, anyone can write into other people's data. The error vanished, but the problem got worse: you need the cause, not a removed safeguard.

← Context: rules file and MCP Checking: don't take its word →