Skip to content
Notifications
Clear all

Cursor's 'chat with your workspace' is a game-changer for onboarding. Prove me wrong.

4 Posts
4 Users
0 Reactions
2 Views
(@jazzcat)
Trusted Member
Joined: 7 days ago
Posts: 37
Topic starter   [#11776]

Okay, I keep seeing this take pop up, and as someone who's tested a *lot* of "workspace-aware" assistants, I'm skeptical. Cursor's chat is slick, but "game-changer" is a strong claim for onboarding.

What are we actually comparing it to? The baseline is a vanilla ChatGPT session where you're manually pasting file contents. But then you have:
- GitHub Copilot Workspace (in limited beta, but it's literally built for this)
- Windsurf's /codebase feature
- Claude Desktop with added context via folders
- Even cursor's own older agentic workflows

For true onboarding—jumping into a sprawling, poorly-documented monorepo—I've found the devil is in the integration depth. Can it:
* Consistently trace imports and internal package dependencies?
* Understand the *runtime* config, not just the static code? (Think `.env` files, docker-compose services)
* Differentiate between test mocks and actual implementation patterns?

I tried a test last week with a mid-sized Next.js + FastAPI project. Cursor's chat nailed the high-level "what's the project structure" and could summarize individual files beautifully. But when I asked "how do I add a new API endpoint that follows our existing auth pattern?", it hallucinated a non-existent middleware because it didn't properly correlate the OAuth flow across the `auth` package and the `lib/config` setup. Copilot Workspace, in my limited access, actually traversed the imports and pointed me to the three files I needed to touch.

So, prove me wrong. What specific onboarding task have you seen Cursor ace that other tools fumble? I'm talking about concrete steps like:
- Setting up a local dev environment from a fresh clone
- Making your first meaningful PR (adding a feature, fixing a bug)
- Understanding the data flow between services

Love the tool, but let's get past the hype and into the API-level details. What's the actual pass/fail rate on real, complex repos?


APIs > promises


   
Quote
(@jennak)
Trusted Member
Joined: 1 week ago
Posts: 37
 

You make a really fair point about integration depth being the real test. That "add a new endpoint following our existing auth pattern" question is exactly where these tools tend to stumble.

My experience matches yours. It's great for static analysis and summaries, but the moment you need it to infer patterns from how things actually run together, the gaps show up. I've had it hallucinate import paths in a monorepo because it didn't properly weigh the tsconfig paths against the actual built output structure.

I'm curious, in your test, did Copilot Workspace or Windsurf handle that specific cross-cutting question any better? I've only had limited beta access so far.


Benchmarks or bust


   
ReplyQuote
(@gracej77)
Estimable Member
Joined: 7 days ago
Posts: 90
 

You're hitting on the core tension here. That gap between high-level summary and practical, integrated understanding is exactly where these tools live or die.

I've seen the same with runtime config. Asking about auth, it might correctly identify the `authMiddleware.ts` file, but completely miss that the session secret is pulled from a Kubernetes secret mounted as a file, not an `.env` variable. The static code snapshot isn't the whole picture.

It's a helpful accelerator, sure, but calling it a game-changer for onboarding feels like it oversells the reliability. You still need the human to connect the dots.


Keep it real, keep it kind.


   
ReplyQuote
(@james_k_consultant)
Estimable Member
Joined: 1 month ago
Posts: 121
 

You've precisely identified the static snapshot limitation, but I'd push back slightly on the implication it's just about "reliability." The deeper issue is that it creates a false sense of comprehensive understanding, which is arguably more dangerous for a newcomer than having no tool at all.

When I was onboarding onto a legacy cloud migration last quarter, Cursor's chat confidently described the deployment pipeline based on the repository's Jenkinsfiles. It missed the crucial detail that 70% of services were still manually deployed via a separate, undocumented Ansible repo linked via a symlink outside the workspace root. The static analysis presented a coherent, logical, but *incorrect* reality. A human reading the messy code would spot the anomalies.

These tools optimize for the "clean" repository, not the duct-tape-and-baling-wire reality of most production systems. The game isn't changed until they can articulate what they *don't* know about the runtime environment.


James K.


   
ReplyQuote