I’ve been using Cursor extensively on TS projects and noticed a big improvement in speed and code quality by enforcing clear guardrails (strict types, linting, formatting) combined with rigorous TDD. When I hit an error or exception, I explicitly tell the agent to pause and first figure out the best way to debug and quickly pinpoint the root cause. This approach generally works well, provided I’ve decomposed the problem enough that we’re debugging just one thing at a time (though that’s not always trivial).
I’m interested to try this out to see if or how much it speeds things up further.
I used to run into dead loops until I changed the way I prompt cursor. Asking it to focus on 1 error at a time massively improves the success rate. Had an old project in node 10 project that hadn’t been touched since ~2017 and after several attempts with cursor. Asked if to fix 1 issue at a time until it moved from node 10>12>14…>22 and after about 15 minutes it succeeded. That included updating all the dependencies and removing deprecated/dead/dropped packages and getting them to latest and updating Vue from 1 to 3.5
Related but I decided to try out Claude Code and one of the first things I noticed is that it didn't seem to be checking for basic transpilation errors (this was in a Typescript project). I added the following bit to the CLAUDE.md file (which is the equivalent of the assistant's LLM guidelines):
- `npm run build` - Run TypeScript compilation + Vite build. You should periodically run this to check for errors.
Up to you, but there's actually a formal logging pathway[1] in MCP that has the potential to put this message somewhere that either of the two consumers[2] of your service could see it https://github.com/hyperdrive-eng/mcp-nodejs-debugger/blob/v...
1: https://spec.modelcontextprotocol.io/specification/2024-11-0...
2: the person, and (while I don't have evidence of it) I also can't think why the LLM couldn't see the message, either
We'll have to look with fresh eyes on the print debugging vs debugger debate for LLMs.
LLMs can not only add tons of log statements fast but parse the large output from a program faster.
How exactly is debugger connection better for LLMs compared to log statements?
MCP = Model Context Protocol
(I didn't know what MCP was.)
Exciting to see more development in this direction!
I've been using a VS Code extension that I built to enable Claude / Cursor / Continue to automatically debug.
It's language agnostic and also uses MCP.
https://github.com/jasonjmcghee/claude-debugs-for-you
LSP and debugging support are incredibly useful for LLMs, and I'm hoping to see general support for these capabilities in the existing tools soon!
Unless I'm misunderstanding this - Cline can do this off the shelf (no need to install & subscribe to cursor), I'm surprised you can't do this in cursor actually?
This is really useful. LLMs need external feedback to self-correct reasoning.
this doesnt really help get out of loops in my experience
none of these agents or ide can fix the underlying issue with the blackbox
until the blackbox is capable of genuine reasoning and awareness
calculated brute force is our only path forward
Does it work with bun?
There's a facinating number of posts mentioning MCP in the last week or two. Many of them from young accounts, or accounts with a post years ago, then nothing, and suddenly MCP.
MCP itself just seems to be JSON-RPC with a schema to be self-describing, so it's not really that interesting that it warrants one post per day. The web page touts it as the magic needed to ensure you don't have to write API adapters for your LLM uses. Well, except you need to write or use an MCP server to do the translation. So unless you're using one that already exists (though hundreds have been advertised on HN recently,) you're just shifting the problem by adding a layer of indirection.
They also specifically say that authentication is something we'll work out later, so it seems none of these will have access to the data that actually has value.
I have no idea about this account specifically, but I'm starting to suspect there's a bot ring somewhere.
[flagged]
[flagged]
Cursor often gets into "dead loops" trying to fix code [1][2]. But, Cursor also seems to get out of dead loops when it adds `console.log` statements everywhere.
We thought: "What if Cursor could access Node.js at runtime?". That would save it from adding `console.log` everywhere, and still get out of dead loops.
We looked into it and got Cursor to debug Node.js on its own.
It's a prototype, but if you're interested in trying it out, we'd love some feedback!
Github: github.com/hyperdrive-eng/mcp-nodejs-debugger
---
References:
[1]: "At this point I feel like giving up on Cursor and just accept that WE'RE NOT THERE YET." ~Source: https://forum.cursor.com/t/cursor-for-complex-projects/38911
[2]: "We've all had the issue. You're trying to build a complex project with your AI companion. It runs into a dead loop, coding in circles, making suggestions it already tried that didn't work." ~Source: https://www.reddit.com/r/ChatGPTCoding/comments/1gz8fxb/solu...