Presentan en HN: Haystack, un IDE para explorar y editar código en un lienzo infinito

 (haystackeditor.com)
2 puntos por GN⁺ 2024-07-26 | 1 comentarios | Compartir por WhatsApp
  • Haystack se presenta como una herramienta de revisión de código que lee el historial de conversaciones y los cambios de un PR en conjunto, y solo envía al revisor los cambios que realmente requieren juicio humano
  • Hace merge automático de los PR limpios y clasifica los PR riesgosos como candidatos a revisión, con el objetivo de acercarse a un flujo de “human code review time to zero”
  • El PR de ejemplo paraleliza tenancyInit() y cacheWarmup() con Promise.all() para reducir el cold start de aproximadamente 4 segundos a 2.4 segundos, pero revierte una decisión previa sobre el orden de ejecución
  • Haystack encuentra en el historial de conversación la razón por la que cacheWarmup debe ejecutarse después de tenancyInit, y confirma en un sandbox 31 fallos en 50 arranques
  • El PR problemático se envía a @maya, quien definió el orden original, y al PR se adjuntan la decisión de diseño rota y los resultados fallidos para reducir el tiempo de evaluación del review

Flujo para clasificar automáticamente los PR en revisión

  • Haystack lee el historial de conversaciones y los cambios de todos los PR para evaluar su nivel de riesgo
  • Los PR riesgosos se ejecutan y validan de extremo a extremo, y solo involucra a un revisor cuando realmente hace falta juicio humano
  • En la pantalla se muestra a Haystack clasificando 16 PR
    • Aparecen PR en varios lenguajes como TypeScript, JavaScript, C, Python, Ruby, Go y C++
    • Cada PR se muestra con estado analyzing

Ejemplo de cambio riesgoso: paralelización del bootstrap del servicio

  • El PR de ejemplo platform#3120 feat: parallelize service bootstrap introduce un cambio para paralelizar las etapas de bootstrap del servicio
  • El código original ejecutaba tenancyInit() y luego cacheWarmup() de forma secuencial
  • El código modificado ejecuta ambas tareas al mismo tiempo con Promise.all([tenancyInit(), cacheWarmup()])
  • Según la descripción del PR, el cold start había subido hasta unos 4 segundos, y tras paralelizarlo bajó a aproximadamente 2.4 segundos
  • Todas las pruebas existentes pasan, así que a simple vista parece una mejora de rendimiento fácil de aprobar

La decisión de diseño que aparece en el historial de conversación

  • Haystack lee el historial detrás del PR y detecta que el cambio revierte una decisión de diseño previa
  • @maya había pedido que tenancyInit terminara primero para evitar que cacheWarmup leyera una configuración vacía
  • La suite de pruebas no incluye ninguna verificación de ese orden de ejecución, por lo que la regresión pasa las pruebas
  • La revisión de Haystack adjunta al PR la siguiente información
    • La decisión registrada en el historial de conversación
    • El comportamiento que el PR actual realmente modifica
    • La razón por la que las pruebas siguen pasando

Validación en ejecución y resultados del fallo

  • Haystack no se detiene en leer el código, sino que ejecuta directamente el cambio
  • Como el historial de conversación apunta a una condición de carrera de timing que no está en las pruebas, arranca el servicio 50 veces en un sandbox
  • En 31 de 50 arranques, cacheWarmup lee una configuración vacía antes de que tenancyInit termine
  • Como resultado, el servicio lanza una excepción en la primera solicitud y se cae
  • Haystack QA también muestra en el PR por qué ejecutó esa validación, qué prueba realizó y en qué punto se rompió

El punto donde hace falta revisión humana

  • Haystack no hace merge automático de ese PR, y recomienda involucrar a @maya, quien definió el orden de ejecución original
  • En el PR se muestran tanto la decisión de diseño rota como los resultados fallidos del arranque
  • La pantalla de revisión ofrece opciones como “Request review”, “Chat with @maya” y “Doesn’t need review”
  • El flujo de Haystack se enfoca en hacer merge automático de la mayoría de los PR y enviar solo los cambios riesgosos, como este ejemplo, a la persona adecuada

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-07-26
Opiniones de Hacker News

  • No sé bien lo de las funciones de IA, pero la idea de trabajar con código sobre un lienzo y usar también una interfaz de diagramas de flujo es algo que quería desde hace mucho tiempo.
    Trabajo principalmente con procesamiento de datos y dibujo muchos diagramas de flujo para explicar pipelines o entenderlos yo mismo.
    Creo que una UI de desarrollo en esta dirección sería útil para lidiar con codebases difíciles de manejar creadas por personas que no estudiaron CS.

    • ¿Estás pensando en herramientas como LabView?
      https://www.ni.com/en/shop/labview.html
    • ¿Es parecido a lo que hace BlueJ en Java?
    • Me pregunto si el problema que enfrentas va más por visualizar el flujo de datos o por visualizar el flujo de control.
    • Sería genial poder bocetar diagramas y código juntos en el mismo lienzo.
      Creo que la documentación visual se volvería mucho más fácil.

  • De verdad está genial. Me gusta que, al ir a un método o una declaración, no abra todo el archivo en una pestaña auxiliar desplazada hasta la definición, sino que muestre solo el fragmento de código relevante.
    Suelo perder de vista el método que estaba leyendo porque necesito comparar dónde se llama un método con su definición, y eso es bastante frustrante.
    Me gusta poder dejar un método “fijado” al lado y revisarlo sin desplazar por accidente todo el archivo en esa vista fijada.
    Lo probé un momento y, lamentablemente, estaba muy centrado en el mouse; además, al seguir métodos dentro de otros métodos terminé con demasiadas ventanas flotantes que administrar.
    Si hubiera flechas o líneas para poder rastrear qué ventana es la “padre”, sería más fácil crear una especie de diagrama de flujo.
    Aunque personalmente le veo puntos flojos, me alegra ver otra forma de pensar en esta área y espero que les vaya bien.

    • Entiendo por qué te gusta, pero creo que a largo plazo el efecto neto podría ser negativo.
      Creo que es beneficioso saber más o menos qué está en dónde dentro del código.
      Me pregunto si alguien podría pasar años en un proyecto y, por trabajar solo viendo pequeños fragmentos, terminar sin saber qué hacen realmente los archivos.
    • La programación literaria implementa esto en una dimensión, es decir, con desplazamiento vertical, y ofrece dos vistas.
      Está el código fuente con comentarios y texto mezclados, y también el código bien maquetado, con texto enriquecido e hipervínculos para navegar.
      http://literateprogramming.com/
    • Sí, necesitamos trabajar en que sea más fácil navegar con el teclado.
      Me da curiosidad qué imaginas como punto de referencia para la “ventana padre”.
      Quisiera saber si quieres designar una ventana específica como ancla, o si prefieres que alguna heurística encuentre esas anclas.

  • Felicitaciones por el lanzamiento. Últimamente voy justo en la dirección contraria, y por mi concentración y tendencia al ADHD me ayuda a reducir el estar saltando de un lado a otro hasta sentirme abrumado.
    Una sola ventana, todo minimizado y, lo más importante, sin navegación por árbol.
    Si necesito ir a un archivo, uso el menú de elementos recientes de Intellij o salto con marcadores de archivo.
    Eso significa que tengo que recordar los marcadores de archivo y tener la intención de ir ahí. Uso el plugin IdeaVim para los atajos de vim.
    Para mí, esta forma de trabajar hace que programar sea mucho más enfocado y disfrutable.
    Es parte de un cambio de multimonitor a widescreen, y luego de vuelta a una sola pantalla.
    En codebases grandes y maduras como las que mencionas, uso un LLM como guía.

    • ¿Cómo lo usas? También me da curiosidad qué tan grande consideras una codebase grande y madura.
      En mi experiencia, los LLM cometen bastantes errores y hacen muchas suposiciones incluso con un solo archivo.
    • Lo entiendo. Me da curiosidad cómo usas un LLM como guía.
      En mi experiencia, cuando le pregunto a un LLM dónde está el flujo de una funcionalidad, suele crear buenos puntos de entrada, pero a menudo tengo que averiguar los detalles por mi cuenta, y a veces apunta a lugares relacionados pero que no eran lo que estaba buscando.

  • Interesante. Tengo algunas notas.
    Obsidian tiene una función parecida llamada “Canvas”, así que vale la pena tomar como referencia ese flujo de trabajo.
    Para mí no sirve como herramienta independiente; la necesito como plugin de Idea.
    La parte de crear layouts es lo que más detesto. Sería bueno tener una IA que tome un parche de Git o una corrección de bug y genere un layout acorde.
    Compartir layouts debería ser muy fácil.
    Sería bueno integrar el historial de Git como otra dimensión. También estaría bueno tener diff y anotaciones de blame dentro del editor.
    Hay datos que se pueden usar para entrenar IA: los commits de Git.
    También sería bueno integrar el debugging como otra dimensión, e integrar datos del profiler.

    • Por el video demo, parece que no es standalone, sino que se ejecuta dentro de VSCode.
      Es decir, obtienes tal cual lo que eso ofrece.
      Si usas herramientas de la familia Idea, por ahora no parece haber forma.
    • La herramienta se ve buena y me gustaría probarla para el trabajo. Como uso Android/Kotlin, sumo otro voto por la integración con IDEA.

  • Hace mucho que quería probar algo así. ¿Hay alguna forma de recibir actualizaciones?
    En especial, estoy esperando aunque sea al principio una opción para desactivar las funciones de IA.
    Me gusta especialmente la función de hacer zoom dentro de una función y ocultar el resto del archivo. Sorprendentemente, hubo muchos momentos en los que quise algo así.
    También parece que podría usarse para arrastrar fácilmente al costado las funciones en las que estoy trabajando dentro de un archivo, como una forma de reorganizar virtualmente un solo archivo.
    Además de la interfaz de edición, creo que dentro del editor hay muchas oportunidades de visualización.
    Podrían hacerse visualizaciones de la interacción entre mi código y las dependencias de terceros, el grafo de dependencias/llamadas de mi código o una parte de él, grafos de dependencias a nivel de clase o módulo, o grafos de llamadas anidados que permitan profundizar hasta el grafo de llamadas internas de un objeto.
    En todos estos casos, poder pasar sin fricción entre la visualización y la edición parece ser la función estrella a la que apunta esta herramienta.
    Con solo incorporar gráficos al editor se abren muchas más visualizaciones interesantes, como mapas de calor de frecuencia de cambios en el código, mapas de calor de rendimiento del código, seguimiento del uso de variables, etc.
    https://adamtornhill.com/articles/crimescene/codeascrimescen...
    Por último, si no leíste The Programmer's Brain, al menos estaría bueno escuchar este podcast.
    https://se-radio.net/2021/06/episode-462-felienne-on-the-pro...
    Hay muchas ideas para editores relacionadas con cómo funciona nuestro cerebro, pero todavía no vi que estén bien soportadas en los editores.
    Como ya dieron un paso en esa dirección, quizá haya muchas más oportunidades.

    • Lamentablemente todavía no armamos una forma ingeniosa de suscribirse a actualizaciones.
      Vamos a pensar cuál es la mejor manera y, eventualmente, enviaremos actualizaciones directamente desde el producto.
      Justo ahora estoy agregando el opt-out de copilot.
      Las ideas de acá son buenas, y me gustaría conversar algunas. Si te parece bien, te voy a mandar un email/DM.
      En general queremos hablar con varias personas, y pueden enviarnos feedback a feedback@haystackeditor.com.

  • Me encanta la forma de navegar de función a función, de archivo a archivo, y volver otra vez.
    Para que sea más útil, estaría bueno tener un panel de historial de navegación, como el historial de visitas del navegador.
    Al moverse entre archivos y funciones, que muestre una lista y permita ir hacia atrás o adelante, o saltar directo a cualquier punto del historial de navegación, sin tener que rebuscar entre las ventanas abiertas.
    El historial de navegación del que hablo es completamente independiente del historial de edición.
    Deshacer/rehacer ediciones no debería mover el historial de navegación hacia atrás o adelante, ni viceversa.
    Por supuesto, podría haber atajos de teclado para moverse por el historial de navegación.

    • Buena idea. Voy a pensar cuál es la mejor forma de implementarla.

  • Genial. Está relacionado con Code Bubbles: https://dl.acm.org/doi/abs/10.1145/1753326.1753706

    • Sí, Bubbles es excelente. Me gusta especialmente el concepto de minimapa.

  • “No guardamos tu código ni lo registramos en logs. Enviamos fragmentos de código a Open AI como entrada para el copilot de navegación. Pronto agregaremos una opción para desactivar esto.”
    Cuando esté esa opción, me gustaría echarle un vistazo.

    • En Mac agregamos el opt-out del copilot de navegación.
      Hay que abrir la paleta de comandos (CMD+SHIFT+P) y usar el comando “Opt out of navigational copilot”.
      El soporte para Windows/Linux llegará pronto.
      También vale aclarar que solo enviamos datos a Open AI cuando hay un diagnóstico que indica que se está llamando a una función inexistente.
    • Tuve la misma reacción. Estoy dispuesto a apoyar el desarrollo de herramientas como esta, pero preferiría una forma más directa.
    • De acuerdo. Desde el principio debería haber sido opt-in.
    • En su estado actual, sería difícil probarlo en mi empresa.

  • Publiqué un paper que compara el tiempo de navegación entre un editor basado en canvas (Code Bubbles), un editor tradicional basado en pestañas (Eclipse) y un editor basado en carrusel que diseñé (Patchworks).
    El resultado fue que el canvas ofrece demasiada libertad.
    https://austinhenley.com/pubs/Henley2014CHI_Patchworks.pdf

    • Interesante. Nunca pensé demasiado a fondo en la disposición espacial de un IDE.
      Mirando hacia atrás, en VS Code ya casi no uso pestañas, porque tengo demasiados archivos abiertos.
      Simplemente veo un archivo a la vez y, cuando necesito cambiar, busco con Cmd-P o me muevo entre archivos recientes.
      Funciona bien, pero me obliga a tener siempre en la cabeza los nombres de archivos/directorios.
    • Leí apenas un poco el paper, pero por la discusión sobre Eclipse me parece que los participantes habrían sido mucho más eficientes si lo hubieran usado como un IDE, en vez de como un editor multipestaña.
      Encontrar métodos habría sido mucho menos problemático con una vista de outline ordenada alfabéticamente.
    • Muy interesante. Estuvimos dudando entre grilla y canvas, pero al final elegimos canvas porque en la práctica pensamos que la navegación es más fácil.
      Si te parece bien, me gustaría conversar, y te voy a mandar un email.
    • Interesante. Patchworks se parece en cierta medida a la forma en que configuro Doom Emacs.
      Tengo de 4 a 6 paneles de código repartidos en varios espacios de trabajo, y cambio entre ellos con SPC TAB número.
    • Excelente análisis. Para mí, ya sea basado en canvas o en carrusel, al trabajar con bases de código muy grandes ayuda a reducir la carga de tener una cantidad considerable de datos cognitivos en la cabeza.
      Para usar bien la herramienta, en la práctica también hace falta suficiente pantalla ancha.
      La clave es acostumbrarse a tratar los archivos en dirección horizontal, no vertical.
      Ese pensamiento vertical está bastante arraigado en la forma en que escribimos nuestro primer Hello World.

  • Felicidades por el lanzamiento. Parece una herramienta excelente y bien implementada, y me entusiasma probarla.
    Me recuerda a una función que he querido desde hace tiempo y que intenté crear manualmente algunas veces, pero nunca pude llevar a una forma compartible: la capacidad de desenrollar una ruta de código en un solo script o archivo fuente.
    Me gustaría poder poner algo como un punto de interrupción y presionar un botón “unravel”, para que quede un único archivo que muestre todo lo que ocurre hasta ese punto.
    Idealmente, sería aún mejor si ese archivo pudiera ejecutarse como un script único.
    En esencia es la misma vista que ofrece un depurador paso a paso, pero en lugar de referenciar varios archivos y varias capas, quiero verlo todo de principio a fin dentro de un solo archivo.

    • ¿Para qué lo necesitas? ¿Qué problema intentas resolver? ¿Cuál es el resultado que buscas?
      Creo que cuando la gente se enfoca en detalles concretos de implementación en lugar de requisitos, parámetros y resultados, mucho se pierde en la comunicación.
      Me da curiosidad por qué quieres esta implementación y qué función u objetivo debería cumplir.