How We Use Cursor for Debugging

Public Beta means real customers hitting real edge cases. When a ticket comes in — email sending from the wrong address, a CRM field misbehaving, Slides not fullscreen — someone on the team opens the repo, reproduces the issue, and starts debugging. Increasingly, that debugging session starts in Cursor.

What Cursor gives us

Cursor is an AI-native code editor. That sounds like marketing copy until you’re three layers deep in a stack trace at 4pm and need to know why a handler fires twice. The model sees the file you’re in, the imports, the call sites, and — when you point it there — the error log. You’re not pasting snippets into a chat window in another tab. Context stays in the editor.

For Salestrics, that matters because the platform spans a lot of surface area: CRM records, Workspace apps, Comms, Orbit!, billing, auth. A bug in one module often touches shared middleware, org scoping, or permissions defined somewhere else. LLMs are good at the boring part — tracing “who calls this?” across files — so engineers can focus on whether the behavior is actually wrong.

How we use it for debugging

Our workflow is practical, not mystical:

• Reproduce first. Cursor doesn’t replace a minimal repro. We still write down steps, grab request IDs, and note which org hit the issue.
• Ask with context. Select the failing function, paste the stack trace, and ask what conditions lead to this path. The answer is often faster than spelunking alone.
• Propose fixes, then review. We treat model output like a junior engineer’s PR — useful, but never merged without a human read. Especially for auth, billing, and data writes.
• Ship and post. Fixes from beta week land in the product and in our System Status Center when customers need to know.

June 16 was a heavy ship day — list view edits, org-branded outbound email, billing addresses on accounts, column sorting, Orbit! in CRM feeds. Some of that work moved faster because Cursor helped navigate unfamiliar corners of the codebase without losing an afternoon to grep.

Why LLMs help software engineering

The benefit isn’t “AI writes all our code.” It’s compression:

• Context switching costs less. Jumping from a React component to a SQL migration to an email template is smoother when the model summarizes each layer.
• Onboarding is shorter. New contributors ask how routing, org scope, or list views work and get answers anchored in our repo — not generic docs.
• Incidents de-escalate faster. During beta, volume matters. Tools that shorten the path from “broken” to “root cause” keep the queue manageable.
• Quality still depends on judgment. LLMs hallucinate. Tests, review, and production monitoring stay non-negotiable. We sell software to revenue teams; we don’t ship vibes.

We also build Salestrics AI into the product — pipeline intelligence on live CRM records, transparent token metering, org-level pools. Using LLMs internally while shipping AI externally keeps us honest about what the tools are good at and where they need guardrails.

Building in the open

We’re not claiming Cursor replaced our team. We’re saying that in Public Beta — when feedback arrives fast and fixes need to land faster — LLM-assisted debugging is a genuine advantage. If you’re running a small engineering org on a large surface area, it’s worth trying seriously: real bugs, real repos, real review gates.

Curious what we shipped this week? Read the June 16 changelog or Orbit! launch post. And if something’s broken in your workspace, tell us — support is how beta gets better.