Having spent the last quarter extensively using Cursor across several client projects, I've arrived at a conclusion that seems counterintuitive at first glance: Cursor's utility is inversely proportional to the age and complexity of the codebase you're working on. For greenfield development, it's a paradigm shift. For legacy systems, it can become a significant source of friction and even risk.
The core of the issue lies in Cursor's reliance on context—both from the current file and the broader project via its @-references and automatic codebase analysis. In a greenfield Terraform or Kubernetes configuration, or a new microservice written in Go, this is a superpower. The AI has a clean, coherent architectural pattern to infer, and its suggestions are consistently aligned with the project's nascent conventions.
However, in a legacy monolith, this context becomes a minefield. Consider these specific pain points:
* **Pattern Amplification:** Legacy code is often inconsistent. If you use Cursor to refactor a module, it will aggressively pattern-match against the nearest, most similar code—which may itself be an anti-pattern or deprecated style. You can end up efficiently replicating bad practices.
* **Hallucinated Dependencies:** When asked to implement a feature that references an older internal library, Cursor will often invent APIs or methods that *feel* like they should exist, based on other parts of the codebase, but do not. This is far more dangerous than a simple "I don't know."
* **@-Reference Overload:** Trying to explain the byzantine flow of a legacy system through @ references is impractical. The AI's context window gets filled with contradictory patterns, leading to confused or nonsensical outputs.
A concrete example from a recent engagement with a legacy PHP application:
```php
// Attempting to have Cursor generate a new service class that follows "the existing pattern"
// It correctly referenced an adjacent class but imported a non-existent `LegacyValidator` trait,
// because three other files in the directory used a similar-looking but differently named trait.
// The suggestion compiled syntactically but failed at runtime.
```
The mitigation strategies become manual and tedious: you must pre-load the chat with extremely precise, almost legalistic context about which patterns to follow and which to ignore, effectively writing a specification to countermand the AI's own analysis. This negates the velocity benefits.
In contrast, for a new project implementing a Zero-Trust service mesh configuration with Envoy and Terraform, Cursor can operate with breathtaking efficiency, maintaining consistency and even suggesting robust security postures that align with modern frameworks. The difference is stark.
Ultimately, Cursor functions best as an accelerator for coherent, well-defined systems. It struggles as a translator or interpreter for the accumulated technical debt and inconsistency of legacy environments. For those, a more traditional, manual refactoring approach, supplemented by very targeted Cursor use for isolated, well-scoped tasks, remains the safer path.
Oh, you've discovered the "garbage in, gospel out" principle. It's not just legacy code, it's any codebase where the team wasn't dogmatic about style. The tool's greatest strength - inferring patterns from context - becomes its greatest flaw when the context is a decade of conflicting decisions and band-aids.
I'd argue the real risk is when it *does* work on legacy cruft, because then you get a false sense of security. It confidently automates a change that seems correct based on the surrounding mess, and you don't question it because the output looks coherent. At least when it fails obviously, you're forced to actually look at the code.
The vendor's marketing always shows it building something perfect from scratch. They never show it faithfully reproducing a 2012 jQuery pattern because that's what's in the adjacent file.
Buyer beware.
You mentioned that Cursor's suggestions get aligned with the project's nascent conventions in greenfield work. That makes me wonder, how much does the initial prompt or setup matter? If you feed it a really detailed style guide at the very start of a greenfield project, does it stick to that better than it would trying to follow a messy, established pattern later on?
I'm also curious about the risk part with legacy code. It seems like the real danger is when the output *looks* coherent, like user541 said. Have you found any practical way to mitigate that, or is it just a hard limitation of the tool's design right now?