Nuestros problemas

por Sualeh Asif en investigación

Actualización: escribimos sobre algunos otros problemas.

Una lista no ordenada de problemas breves y concretos:

  • Mejor contexto: Hay muchas fuentes de información en un editor de código: archivos abiertos, fragmentos de código semánticamente similares, clases conectadas de forma simbólica, salidas de linters, trazas de ejecución, historial de git, historial de escritura, documentación externa y más. Queremos que el modelo entienda al instante qué es lo más relevante para la pregunta del usuario, y actualmente estamos entrenando un modelo de reranking personalizado y rápido para resolver este problema. Para cada solicitud, reuniremos 500k tokens de todas las fuentes distintas y usaremos nuestro reranker para filtrarlos hasta los 8k tokens más relevantes. Esto es tanto un problema de modelo como, cada vez más, un problema de infraestructura.

  • Un “copilot para ediciones”: Aunque GitHub Copilot es tremendamente útil para eliminar las pulsaciones de teclas de baja entropía al escribir código nuevo, no te ayuda a ahorrar pulsaciones de baja entropía cuando necesitas hacer cambios pequeños y simples en bloques de código existentes. Piensa en las pulsaciones de navegación, eliminación y entrada que necesitas hacer para un cambio de nombre que es solo un poco más complicado de lo que puede hacer un cambio de nombre simbólico con F2. Necesitaremos innovación tanto en UX (diffs poco intrusivos que se te muestran mientras programas) como en el lado del modelo (el prompting no es suficiente, debido a problemas de costo, latencia e inteligencia).

  • Agentes limitados y en flujo: Piensa en el code interpreter de OpenAI, pero para ingeniería en grandes bases de código. Le dices a un agente limitado, de pocos pasos, qué hacer, y este busca, escribe y ejecuta código por ti, mientras que de vez en cuando te consulta para obtener feedback. El primer paso para lograr esto, en el que estamos trabajando ahora mismo, es crear un agente como este que funcione en carpetas de unos pocos cientos de miles de tokens. Si eso tiene éxito, lo ampliaremos para que funcione con bases de código completas.

  • Detección de bugs: Aquí hay dos modos: (1) en segundo plano, Cursor estará siempre escaneando pasivamente tus archivos para encontrar posibles bugs por ti, y (2) cuando estés inmerso en una sesión de depuración, Cursor buscará activamente el bug con tu ayuda. Hay muchos aspectos interesantes de recopilación de datos por explorar aquí.

  • Ediciones más grandes: Cursor debería poder modificar archivos completos e incluso directorios completos por ti. Este es un reto tanto de capacidades como de UX. Para lograr velocidad, el modelo debe ser lo suficientemente inteligente como para seleccionar las partes a modificar sin reescribirlo todo. Para que la experiencia sea buena, los cambios deben mostrarse en una forma interpretable y en tiempo real.

  • Escala: Tenemos 1.4 mil millones de vectores y 150 mil bases de código indexadas, al 12 de octubre de 2023. Es probable que esto crezca 10x para fin de año. Ya hemos creado un motor de sincronización de bases de código muy rápido basado en árboles de Merkle en Rust, y probablemente necesitaremos construir pronto un sistema de indexación personalizado.

Ideas futuras:

  • Time warp: Predecir y mostrar los cambios de código entre archivos que harás en los próximos 15 minutos. Un solo comando para aceptar todas las inserciones/eliminaciones.

  • Comprensión: Nuestros modelos deberían entender en profundidad todos los conceptos de cualquier base de código, dentro de sus pesos.

  • Modo lector: Hacer que la comprensión de código sea sencilla con documentación en cualquier nivel de especificidad y un bot que te guíe por las rutas de código relevantes, explicando según sea necesario.

  • Modo pseudocódigo: Editar una representación tipo “esquema” de tu código y que los cambios se apliquen automáticamente a nivel de fuente.

  • No volver a preocuparte por las stack traces: El IDE simplemente debería entenderlas y corregir automáticamente el código por ti.

Intentamos recopilar todos los problemas en los que estamos pensando ahora mismo, pero —y esta es una de las cosas maravillosas de crear un producto que tú mismo usas 12 horas al día— constantemente tenemos nuevas ideas y volvemos a priorizar, así que esto no debe verse como una hoja de ruta definitiva. Dicho esto, esperamos que dé una idea de en qué invertimos nuestra energía mental cada día.

Además, has leído bastante hasta aquí, así que es muy probable que tengas cierto interés en los problemas que nos interesan :). Si es así, ¡deberías considerar unirte a nosotros! Aquí tienes algunas otras razones por las que creemos que te encantaría trabajar con nosotros:

  • A la gente le gusta usar Cursor. Estamos muy contentos con nuestro crecimiento inicial.

  • Aquí trabajarás con gente muy inteligente. Creemos profundamente en la densidad de talento. Todas las personas con las que trabajes aquí serán muy, muy buenas.

  • La programación con IA es un mercado enorme. Y podemos liderarlo.

  • Es divertido. ¡Esto es muy importante para nosotros! Es divertido trabajar con gente que te cae bien, es divertido crear un producto en el que pulsas Cmd-Shift-R y obtienes feedback instantáneo de los usuarios porque tú mismo, mientras programas, eres el usuario al que va dirigido, y es divertido avanzar un poco cada día hacia la automatización de todas las partes aburridas de la programación.

  • Trabajamos duro. Nos sentimos afortunados de trabajar en estos problemas y disfrutamos dando todo de nosotros para resolverlos.

Nuestros problemas · Cursor