Como continuación de nuestra publicación original sobre problemas, aquí presentamos algunos otros de los problemas que consideramos más importantes para la próxima fase de la programación con IA.

#Predicción de la próxima acción

Cursor viene con Copilot++, una versión más inteligente de Copilot que predice tu próxima modificación. ¿Podemos llevar esta idea a su límite natural?

Al programar, no solo haces modificaciones de baja entropía. En todo el editor, realizas pulsaciones de teclas, clics, acciones de baja entropía. ¿Podemos construir un modelo que prediga cada una con baja latencia?

Para empezar, hemos extendido Copilot++ para predecir tu próxima ubicación en el editor. Combina esto con la predicción de la siguiente modificación y el modelo puede reproducir una secuencia de cambios de baja entropía:

Estamos trabajando en predecir cuál será el próximo archivo al que te moverás. El próximo comando de terminal que ejecutarás. La siguiente modificación, condicionada por tus comandos de terminal anteriores. Un modelo de predicción de la próxima acción.

Además, el modelo debería mostrarte la información en el momento en que la necesites, ya sea el fragmento de código o la documentación adecuados.

Cursor debería sentirse como una extensión de tu voluntad. En el momento en que piensas en un cambio, el modelo de lenguaje necesita una intención mínima por tu parte para ejecutarlo al instante.

#Líneas de trabajo prometedoras

• Investigación fundamental sobre action prediction en toda la base de código.

• Pre-entrenamiento y post-entrenamiento continuos en modelos de código con ~5–13B parámetros activos (para predicciones de baja latencia limitadas por el prefill).

• Trucos de inferencia adicionales similares a Speculative Edits

UX ingenioso para presentar “acciones” de una manera no intrusiva. (¿Cómo sugerir el siguiente archivo al que un usuario debería pasar? ¿O la siguiente ubicación fuera del área visible actual?)

#Ediciones perfectas

¿Podemos escalar el cómputo en tiempo de inferencia para producir ediciones más grandes y de mayor calidad? ¿Cómo compensamos la mayor latencia?

Puede ser necesario realizar la edición en segundo plano. Es decir, lanzar una unidad de trabajo que puedas delegar en modelos inteligentes.

Necesitaremos modelos con sólidas capacidades de uso de herramientas específicas de edición, un contexto más inteligente a nivel de toda la base de código y un razonamiento a largo plazo mejorado.

¿Y cómo podemos hacer que la generación de código asíncrona preserve el flujo? Esto suena contradictorio, pero creemos que una investigación creativa sobre las capacidades de los modelos y la UX podría hacer esto posible.

#Pseudocódigo alucinado

Los usuarios escribirán pseudocódigo que describa el cambio deseado. Después, podemos confiar en que Cursor compile ese pseudocódigo en el cambio completo, en segundo plano.

#Ediciones en varios archivos

Cmd-k ya es fantástico, pero ¿y si pudieras solicitar un cambio genérico en toda tu base de código? En particular, uno que se aplique correctamente a varios archivos.

#Líneas de trabajo prometedoras

• Escalar la capacidad de cómputo en tiempo de inferencia. Sabemos que los modelos de recompensa y el muestreo por rechazo ofrecerán mejoras rápidas y sencillas, pero ¿hasta dónde podemos llegar?

• Mejores modelos de razonamiento (GPT-5, Claude-4, Gemini 2.0)

• Ejecutar múltiples copias del language server y del sistema de archivos para un espacio de trabajo de usuario dado. Esto requerirá uso de herramientas por parte del modelo y reproducir de forma remota los entornos de ejecución.

• Entrenar/mejorar el rendimiento del modelo en trayectorias de agentes

• Amplia experimentación de UX para ediciones asíncronas en flujo

#Contexto óptimo

Puede haber millones de tokens de documentación, decenas de millones de tokens de código fuente, otros tantos millones de tokens de historial de commits; todos ellos potencialmente útiles para resolver una sola consulta.

Sin mencionar los píxeles de tu interfaz de usuario, los registros en producción y en localhost, los mensajes en Slack, etc.

Creemos que los mejores sistemas de desarrollo usarán una combinación de recuperación, recurrencia y atención de contexto largo para procesar toda esta información.

Enfatizamos sistemas porque, a corto plazo, esto puede ser un conjunto de modelos e infraestructura que conforman un motor de contexto infinito para programar. A largo plazo, esperamos que esté integrado en la arquitectura.

Nos entusiasma especialmente pensar de forma creativa sobre el futuro de la recuperación. Más allá de los embeddings, ¿cuál es el mejor rendimiento posible dada la primitiva de un paso de indexación costoso y un paso de consulta barato (sublineal en el tamaño del corpus)?

Quizá se parezca a alguna variante de memoria de transformer como índice de búsqueda diferenciable. Tal vez sea algo completamente distinto. Es una línea de investigación poco explorada.

#Contexto multi-hop

Dentro de mi base de código, quiero calcular un diff entre dos cadenas. Con embeddings, obtengo el fragmento:

function computeDiff(
  firstModel: ITextModel,
  secondModel: ITextModel,
): string {
  //...
}

Para responder a la consulta original, debo determinar cómo crear un ITextModel a partir de una cadena. Esta es una consulta que requiere dos saltos para resolverse.

Las preguntas y consultas más difíciles en una base de código requieren varios saltos. La recuperación básica solo funciona para un único salto.

#Líneas prometedoras

• Embeddings y rerankers especializados/mejorados para bases de código.

• Entrenar embedders de múltiples saltos. Dada una consulta y el código relevante que hemos encontrado hasta ahora, determinar la siguiente porción de código a la que saltar.

• Caché de prefijos inteligente y, quizá, máscaras de atención personalizadas mejor adaptadas a bases de código.

• Investigación novedosa sobre recuperación a nivel de base de código.

• Enseñar a un modelo a aprender una base de código en sus propios pesos, de forma similar a usar transformers como índice de búsqueda.

#Detección de errores y depuración

Los sistemas de detección de errores existentes tienen dificultades con la calibración y con lograr un entendimiento suficiente de la base de código.

Los modelos son lo bastante inteligentes como para identificar errores correctamente, pero sufren de muchos falsos positivos. Identificar los errores más difíciles requiere una comprensión más profunda de la base de código. Y un código que parece defectuoso puede resultar inofensivo cuando se observa el panorama completo.

Una manifestación de esto podría ser una experiencia de revisión de código mucho mejor gracias al uso de modelos de lenguaje:

#Detección de errores en la revisión con IA

La ventaja de la “revisión con IA” es que el usuario es más tolerante a los falsos positivos, ya que está solicitando una revisión. La desventaja es que implica cambiar el comportamiento del usuario.

#Linting con IA

La mejor versión de la detección de errores es un linter siempre activo que detecta tus errores en segundo plano. Tiene que ser un modelo más económico y rápido que AI-review, ya que lo ejecutaríamos varias veces por minuto. También debe estar ajustado para producir una tasa de falsos positivos más baja.

#Depuración más inteligente

Quizás más impresionante que la detección de bugs sea depurar problemas difíciles.

Necesitaremos ir más allá del análisis estático basado en LLM. Por ejemplo, hemos creado un paquete cursor/debug. Cuando se inyecta en tu código, registra información en tiempo de ejecución.

En segundo plano, incluso podemos usarlo para registrar estados adicionales de variables (similar a la depuración mediante prints, con las salidas relevantes enviadas al contexto de Cursor).

#Líneas prometedoras

• Curación inteligente de conjuntos de datos (probablemente datos sintéticos) y RL en modelos de código de vanguardia para mejorar la calibración.

• Registrar información relevante desde otros entornos (como el navegador o una terminal no integrada).

• Mejorar el rendimiento de los modelos de vanguardia en el uso de herramientas específicas del depurador y cadenas de herramientas.

• Contexto infinito y comprensión casi perfecta de la base de código.

• Ampliar el alcance de nuestra biblioteca cursor/debug para registrar toda la información útil sobre el estado del programa.

Si te interesa alguno de estos temas, escríbenos a hiring@cursor.com