El coste de migrar no es instalar la herramienta

Cambiar de editor cuesta una tarde. Cambiar de flujo de trabajo con IA cuesta semanas, porque no estás cambiando solo la herramienta, estás cambiando cómo piensas el problema antes de escribirlo. Por eso, cuando sale un IDE de IA nuevo, ya sea una variante de Cursor, Windsurf, Claude Code u otro, no lo pruebo en el proyecto que tengo entre manos. Lo pruebo en algo desechable, con una checklist fija, antes de decidir si vale la pena migrar algo real.

Esta checklist ha ido cambiando con el tiempo, pero la versión actual tiene cuatro partes.

Primero: contexto real, no un hola mundo

Lo primero que pruebo no es "genera una función que haga X". Eso lo hace bien cualquier herramienta decente hoy y no me dice nada. Lo que pruebo es si la herramienta entiende un proyecto con historia: varios módulos, alguna decisión de arquitectura no obvia, un par de sitios donde el código es feo a propósito porque resuelve un caso raro.

Cojo un repo pequeño mío, con un par de miles de líneas, y le pido algo que requiera tocar tres archivos relacionados sin decirle explícitamente cuáles son. Si la herramienta encuentra los archivos correctos sin que se lo indique, eso me dice más sobre su utilidad real que cualquier demo.

Aquí es donde más se diferencian las herramientas entre sí: no en la calidad del código que generan aisladamente, sino en cuánto contexto del proyecto son capaces de recuperar y usar sin que yo se lo dé masticado.

Segundo: qué pasa cuando le corrijo

La segunda prueba es más importante que la primera y casi nadie la hace: le doy una instrucción deliberadamente incompleta o algo ambigua, veo qué asume, y luego la corrijo. Lo que me interesa no es si acierta a la primera. Es si, tras corregirla, aplica el criterio nuevo de forma consistente el resto de la sesión, o si vuelve a la asunción original dos prompts después.

Hay herramientas que "olvidan" la corrección rápido. Eso no se ve en un hola mundo, se ve en una sesión de veinte minutos con idas y vueltas, que es como trabajo de verdad.

Tercero: cuánto control tengo sobre lo que se aplica

Esto es innegociable para mí: necesito ver el diff antes de que se aplique, poder aceptar por partes, y poder decir que no a un cambio sin perder el resto de la conversación. Un entorno que aplica cambios directamente sin ese paso intermedio me hace perder más tiempo revirtiendo que el que ahorra generando.

No todas las herramientas dan el mismo nivel de granularidad aquí, y esto pesa más en mi decisión que la calidad pura del modelo por debajo. Prefiero un modelo algo peor con un flujo de revisión bueno que un modelo mejor que aplica cambios a ciegas.

Cuarto: cómo se comporta fuera del caso feliz

La última prueba es forzar un error: pedir algo que no se puede hacer con las dependencias del proyecto, o algo que contradice una decisión ya tomada en el código. Quiero ver si la herramienta se da cuenta y lo dice, o si inventa una solución que compila pero no tiene sentido.

Esto importa más de lo que parece porque en el día a día no vas a estar siempre pidiendo cosas bien definidas. Vas a pedir cosas a medio pensar, y la herramienta que te avisa de que tu petición no encaja con el resto del código vale mucho más que la que simplemente obedece.

Qué hago con el resultado

Con estas cuatro pruebas hechas en un repo desechable, en un par de horas tengo una idea bastante clara de si vale la pena migrar algo real. Si la herramienta falla en la parte de contexto (la primera prueba), no sigo, porque eso no se arregla con mejores prompts, es una limitación de cómo indexa o razona sobre el proyecto.

Si falla en la parte de corrección persistente o de control sobre los cambios aplicados, la uso igualmente para tareas puntuales y aisladas, pero no la convierto en mi entorno principal.

Migro de verdad solo cuando pasa las cuatro pruebas razonablemente bien y, además, el cambio de flujo respecto a lo que ya uso es lo bastante grande como para justificar las semanas de reaprendizaje. Si la mejora es marginal, me quedo donde estoy, aunque la herramienta nueva sea objetivamente buena. El coste de cambiar de hábito rara vez lo compensa una mejora del diez por ciento.

La recomendación

No pruebes una herramienta nueva en tu proyecto principal ni con tareas triviales. Prueba con un repo real pero desechable, fuerza la corrección de una asunción equivocada, y mide cuánto control tienes sobre lo que se aplica. Si no pasa esas tres cosas, no importa cuánto ruido haga en redes: no es una mejora para tu flujo, es una distracción.

Relacionado: Cómo uso Cursor IDE sin perder el control del código