Cursor en un monorepo de Rust: lo que sí, lo que no

Pasé dos semanas usando Cursor a tiempo completo en un monorepo de Rust con cinco crates internos y un par de dependencias C++ que se compilan con build scripts. La experiencia fue mixta y vale la pena desglosarla.

Lo que sí

El autocompletar de Cursor sigue siendo lo mejor del mercado. En Rust, donde el sistema de tipos te obliga a ser explícito en mil partes, ahorrar incluso la mitad de las firmas y los match exhaustivos es una mejora notoria de productividad. Cuando el modelo entiende los traits que tu crate define, completa implementaciones enteras razonables al primer intento.

La función de “edit selection” también funciona bien para reescribir bloques pequeños. Le marcás veinte líneas, le decís “convertí esto a un iterator chain”, y casi siempre lo hace bien.

Lo que no

Donde Cursor sufre es en navegación cross-crate. Si el código relevante está en un crate vecino del monorepo, la latencia de indexación se nota. A veces sugiere usar un tipo que está en una crate que no importaste, o peor, inventa un módulo que no existe.

El otro problema es cargo. Cursor tiene un agent mode que puede correr comandos, pero cuando un build de Rust tarda dos minutos, el agent se queda esperando y consume tokens en logs que no aportan nada. Aprendí a desactivar el agent y correr los builds yo mismo.

Veredicto

Para un equipo que trabaja en TypeScript o Python, Cursor sigue siendo mi recomendación por defecto. Para Rust en monorepo grande, la cosa cambia: el valor está en el autocompletar, no en el agent. Si tu flujo es más “leer mucho, editar poco”, probablemente seas más feliz con un editor más liviano y Claude Code para los refactors grandes.

No descalifico Cursor para Rust. Solo digo que estás pagando por features que vas a usar a medias.