I've spent a fair bit of time over the past year having agents build webapps for me. Typically, they're built out of some nodejs backend and then some client-side js framework.

One debugging pattern that comes up again and again is that there's a bug in the client side JavaScript. Often a current-gen model running in a coding agent is able to solve a client-side bug just by inspecting the code.

When it works, it's amazing. But "often" is not the same thing as "every time". If the agent can't solve the problem by inspection it will often fire up a browser MCP and attempt to debug the problem interactively. What it's really trying to do is to get a peek at the browser's console log. This works, but it burns a ton of tokens and takes forever.

There's a better way.

One of the first things I ask my agents to build when we're doing web dev is a frontend to backend bridge for console logs. There are two parts to this:

  1. A tiny development-mode JavaScript shim in the frontend code that sends almost any console.log() (or console.whatever()) message to a backend API endpoint. You want to be careful to make sure that the shim doesn't try to send its own "I can't talk to the backend endpoint" errors to the backend.

  2. A backend endpoint that receives frontend log messages from clients and logs them to the server log.

With those two things, claude or whomever you've got coding for you can see frontend and backend log messages in one place, just by tailing a log. It's amazingly useful, really straightforward and so quick to build.

It turns out that it's helpful for any humans who are working on your software, too.