DEV Community

Sherotree
Sherotree

Posted on

Paste the failing Network panel into the agent, not a vague “API broken”

#frontend #ai #debugging #dx

I used to type “the API is broken” into the agent and watch it invent three wrong theories: CORS, a stale token, a missing header that was never missing. Then it rewrote the fetch wrapper “just in case.”

The bug was usually sitting in DevTools the whole time — a red row in the Network panel with a status, a request URL, and a response body I never pasted.

So I stopped narrating. I paste the failing request.

What I actually paste

Not a screenshot. Text the model can grep.

From the failed request in Network:

  1. Method + URL (full path, query string included)
  2. Status (and status text if useful)
  3. Request headers that matter — Authorization redacted to Bearer ***, Content-Type, any custom X-* the API cares about
  4. Request payload (trimmed if huge)
  5. Response body (or the first ~2KB if it’s a wall of HTML)
  6. Timing note — “fails only after hard refresh” / “only on the second click” / “only in the deployed preview”

Example of what goes in the prompt:

Failed request (Chrome Network → Copy as fetch, then edited):

POST https://api.example.com/v1/orders?include=line_items
Status: 422 Unprocessable Entity

Request headers:
  Content-Type: application/json
  Authorization: Bearer ***
  X-Idempotency-Key: ord_9f3a…

Request body:
  {"sku":"tee-blue","qty":2,"promo":"SPRING"}

Response body:
  {"error":"promo_expired","message":"SPRING ended 2026-03-01","code":42201}

Repro: fails every time from the cart Checkout button; same payload works in curl from my machine against staging.
Enter fullscreen mode Exit fullscreen mode

That’s enough for the agent to aim at promo validation instead of “rewrite the client.”

Why “API broken” wastes a whole turn

Vague prompts invite architecture fanfic. The model doesn’t know if:

  • the browser never sent the request
  • the request left and got 401
  • you got 200 with an empty array
  • the UI ignored a successful response

Each of those is a different fix. Without the Network row, the agent picks a story and starts editing the wrong file.

I’ve also seen it “fix” client code that was fine while the real issue was a 307 to the wrong host after a env typo. The Network panel would’ve ended that in ten seconds.

Tiny workflow I reuse

  1. Reproduce once with Network open (Preserve log on).
  2. Right-click the red/failed row → Copy → Copy as fetch (or copy URL + response).
  3. Paste into the agent prompt before any “please fix” prose.
  4. Add one sentence of expected vs actual: “expected 201 + order id; got 422 promo_expired.”
  5. Ban drive-by refactors: “Do not rewrite the fetch client unless the response proves the client is wrong.”

If I’m in a hurry I still paste status + URL + response JSON. Headers and body are the upgrade when that isn’t enough.

What I reject from the agent

  • “Maybe it’s CORS” with no OPTIONS / ACAO evidence in what I pasted
  • A new retry/backoff layer when the server returned a clear 422 business error
  • Silent swaps of the base URL “to match docs” without showing the failing host
  • Deleting the idempotency header because “it might confuse the API”

If the pasted response already names the bug (promo_expired), the patch should touch promo handling — not the transport layer.

Prompt add-on that keeps it honest 

Use only the Network evidence below. List: (1) failing hop, (2) status meaning, (3) smallest client or server change that matches the response body.
If evidence is missing (no status / no URL / no body), ask for it — do not invent a root cause.
Do not refactor unrelated fetch utilities.
Enter fullscreen mode Exit fullscreen mode

Tiny habit

Next time a UI call “just fails,” don’t describe the feeling. Copy the failing Network row into the agent: method, URL, status, payload, response.

Agents are decent at reading HTTP. They’re terrible at reading your mind when all you said was “API broken.”

Top comments (0)