Spots 
If you have ever shipped a backend service without a debugger, a hot-reload dev server or decent logs, you remember how painful it was. Now imagine doing it in a world where your "function" is a non-deterministic black box that can rewrite its own output every time you call it. Welcome to building Gen AI applications.
The single biggest productivity multiplier I have found in the last two years of shipping AI apps is a good local debugging tool. Not a hosted dashboard. Not a cloud trace viewer with a 30-second propagation delay. A local tool that runs next to your code, picks up your edits, lets you replay a request with a tweaked prompt, and shows the full trace, tool call by tool call. We will get into the local-vs-hosted trade-off later in the article. This article is about why that matters and how the three leading JS/TS Gen AI frameworks approach it:
They are three very different products solving overlapping problems, and each one makes different trade-offs that are worth understanding before you commit to one. Shift-left, applied to Gen AI
"Shift-left" comes from the world of testing and security: the earlier in the development lifecycle you catch a problem, the cheaper it is to fix. Bugs found in production cost orders of magnitude more than bugs found while you're typing. Gen AI apps make this principle existential, not just economical, because the failure modes are weirder:
A prompt regression doesn't show up as a stack trace. It shows up as the wrong tone, a hallucinated fact or a tool call that misfires once every twenty runs. A new model version can quietly change behavior across thousands of code paths with no warning. A tool that returns slightly different JSON can cause silent downstream breakage. The only way to keep your sanity is to collapse the feedback loop to seconds. You want to be able to: Change a prompt or a piece of orchestration code. Re-run that exact unit, with that exact input. See the model's input, its output, every tool call, every retry, every token used. Compare it to the previous run. Decide if it's better, worse or different.
If any one of those steps requires deploying, redeploying, opening a cloud console or grep'ing logs, you have already lost. Cycle time is the metric. A debugging tool is what makes that cycle time low enough to iterate productively. It is worth being explicit about this trade-off, because all three tools in this article are primarily local:
A local debugging tool runs on your machine, next to your code, with zero network latency between your edits and what you see. Iteration is fast, traces are immediate, and there is no risk of leaking prompts/responses to a third party. The downside is that it's just for you.
A hosted observability platform (Langfuse, LangSmith, cloud-native APM tools, etc.) is shared by your team, persists data long-term and is essential for production monitoring. The trade-off is propagation delay, configuration overhead and, in some cases, data residency concerns.
These are complementary, not competing. The argument here is that the local part of the loop is the one that's still often missing, and that's where shift-left lives. After working with all three of the tools below, I would summarize the qualities of a good Gen AI debugging tool as: Zero-config or near-zero-config — it should pick up your code, not the other way around. Live reload — edit your code, save, hit "run" again. No restart.
Interactive runners — invoke any prompt, tool, model, or higher-level primitive (agent, workflow, etc.) directly with arbitrary input. Full traces — every step of the generation loop, with input/output/usage at each node. Replay and modify — re-run any past trace with a tweak.
If you have ever shipped a backend service without a debugger, a hot-reload dev server or decent logs, you remember how painful it was.