The Bug That Was Hiding in the API Layer

The table view loaded. The canvas rendered. The table existed in the database.

But when the front end asked the server for the current table state — the seats, the stacks, who is sitting where — the server returned a 404. Nothing. No seats, no game data, nothing for the renderer to work with.

The canvas was blank because it had nothing to draw.

Here is the technical explanation, kept as short as possible: the API gateway in front of the table engine strips a prefix from every URL before forwarding the request. /api/v1/tables/... arrives at the table engine as /tables/.... The table engine’s routes, as written by the build session, were registered expecting the full prefix — so the server was listening on /api/v1/tables/... but receiving /tables/.... Every request missed.

Not a logic error. Not a broken algorithm. A routing table with the wrong addresses. The kind of thing that only surfaces when you test the full stack together.

How Long Did It Take to Find?

Start to fix: under an hour.

That is fast. Here is what made it fast: the debugging methodology.

Working with an AI agent on this does not mean asking “what is wrong?” and hoping for an answer. It means giving the agent the right context simultaneously — the proxy configuration that handles the prefix, the route registration files in the table engine, the request logs showing 404 — and asking it to trace the discrepancy.

When those pieces are visible together, the agent can pattern-match across a surface area that would take a human engineer twenty minutes just to navigate to. The agent found the mismatch between the proxy rewrite rule and the route registration in about three minutes.

The Bug Behind the Bug

Finding the routing bug exposed the next one.

The endpoint now responded. But the data it returned was in the wrong format.

The table engine speaks one language internally: seat numbers, status codes like occupied, raw chip counts as plain integers. The front-end renderer speaks another: seat indexes, formatted currency strings like $235.50, specific field names it expects by contract from a type definition it was written against.

Nobody wrote a translation layer. The build session wrote the endpoint and it returned the internal format. The renderer received data it did not recognize and silently produced nothing.

This is the class of bug that is notoriously hard to write a test for in advance. You have to have both systems running, connected, and trying to talk to each other to see it. No unit test covers the gap between two systems when neither system has a bug by itself.

What This Means for the Build Methodology

The testing phase does not mean the methodology failed. It means the methodology got us to testing.

Every software platform has an integration layer where the pieces have to meet each other in the real world. Spec-driven development gets you to that layer faster. It does not skip it.

The next post in this series covers what happened when we applied the fixes — and the browser showed the same broken result anyway.

For the engineering methodology behind how we build — the spec, the sessions, what the agent does during a session and what the architect does — the full write-up is at The Salty Korean.

Stay salty.