HN-Show: Haystack – IDE zum Erkunden und Bearbeiten von Code auf einer unendlichen Canvas

 (haystackeditor.com)
2 Punkte von GN⁺ 2024-07-26 | 1 Kommentare | Auf WhatsApp teilen
  • Haystack wird als Code-Review-Tool vorgestellt, das Gesprächsverlauf und Änderungen eines PR gemeinsam liest und nur die Änderungen an Reviewer weitergibt, die tatsächlich menschliches Urteil erfordern
  • Saubere PRs werden automatisch gemergt, riskante PRs als zu selektierende Fälle eingestuft, mit dem Ziel eines Ablaufs nahe „human code review time to zero“
  • Im Beispiel-PR werden tenancyInit() und cacheWarmup() mit Promise.all() parallelisiert, wodurch der Cold Start von etwa 4 Sekunden auf 2,4 Sekunden sinkt, zugleich aber eine frühere Entscheidung zur Ausführungsreihenfolge rückgängig gemacht wird
  • Haystack findet im Gesprächsverlauf die Begründung dafür, dass cacheWarmup nach tenancyInit ausgeführt werden muss, und bestätigt in einer Sandbox 31 Abstürze bei 50 Starts
  • Der problematische PR wird an @maya weitergeleitet, die die ursprüngliche Reihenfolge festgelegt hatte; die gebrochene Designentscheidung und die Fehlschläge werden an den PR angehängt, um die Zeit für die Review-Entscheidung zu verkürzen

Ablauf zur automatischen Vorauswahl von PR-Reviews

  • Haystack liest bei allen PRs den Gesprächsverlauf und die Änderungen und bewertet das Risiko
  • Riskante PRs werden end-to-end ausgeführt und verifiziert; nur wenn menschliches Urteil nötig ist, werden Reviewer einbezogen
  • Auf dem Bildschirm ist zu sehen, wie Haystack 16 PRs vorsortiert
    • PRs in verschiedenen Sprachen wie TypeScript, JavaScript, C, Python, Ruby, Go und C++ sind aufgelistet
    • Jeder PR ist mit dem Status analyzing markiert

Beispiel für eine riskante Änderung: Parallelisierung des Service-Bootstraps

  • Der Beispiel-PR platform#3120 feat: parallelize service bootstrap ändert den Service-Bootstrap so, dass Schritte parallelisiert werden
  • Im bisherigen Code wird nach tenancyInit() anschließend cacheWarmup() sequentiell ausgeführt
  • Im geänderten Code laufen beide Aufgaben gleichzeitig mit Promise.all([tenancyInit(), cacheWarmup()])
  • Laut PR-Beschreibung war der Cold Start auf etwa 4 Sekunden angewachsen und wurde nach der Parallelisierung auf rund 2,4 Sekunden gesenkt
  • Da alle bestehenden Tests bestehen, wirkt die Änderung oberflächlich wie eine leicht freizugebende Performance-Verbesserung

Im Gesprächsverlauf sichtbare Designentscheidung

  • Haystack liest die Historie hinter dem PR und erkennt, dass die Änderung eine frühere Designentscheidung rückgängig macht
  • @maya hatte gefordert, dass tenancyInit zuerst abgeschlossen sein muss, damit cacheWarmup keine leere Konfiguration liest
  • In der Testsuite gibt es keinen Eintrag, der diese Ausführungsreihenfolge prüft, weshalb die Regression die Tests besteht
  • Das Haystack-Review hängt dem PR folgende Informationen an
    • die im Gesprächsverlauf festgehaltene Entscheidung
    • das Verhalten, das der aktuelle PR tatsächlich verändert
    • den Grund, warum die Tests bestanden haben

Laufzeitvalidierung und Fehlerergebnisse

  • Haystack bleibt nicht beim Lesen des Codes stehen, sondern führt die Änderung direkt aus
  • Weil der Gesprächsverlauf auf eine Race Condition im Timing hinweist, die in den Tests nicht vorkommt, startet es den Service in einer Sandbox 50-mal
  • In 31 von 50 Starts liest cacheWarmup vor Abschluss von tenancyInit eine leere Konfiguration
  • Dadurch wirft der Service bei der ersten Anfrage eine Exception und stürzt ab
  • Haystack QA zeigt im PR gemeinsam an, warum ausgeführt wurde, welche Tests durchgeführt wurden und an welcher Stelle es gebrochen ist

Punkt, an dem menschliche Review nötig ist

  • Haystack mergt diesen PR nicht automatisch, sondern empfiehlt, @maya einzubeziehen, die die ursprüngliche Ausführungsreihenfolge festgelegt hatte
  • Im PR werden die gebrochene Designentscheidung und die fehlgeschlagenen Boot-Ergebnisse gemeinsam angezeigt
  • Der Review-Bildschirm bietet Auswahlmöglichkeiten wie „Request review“, „Chat with @maya“ und „Doesn’t need review“
  • Der Ablauf von Haystack zielt darauf ab, die meisten PRs automatisch zu mergen und nur riskante Änderungen wie in diesem Beispiel an die passende Person weiterzugeben

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-07-26
Meinungen auf Hacker News

  • Bei den AI-Funktionen bin ich mir nicht sicher, aber das Konzept, auf einer Canvas mit Code zu arbeiten und dazu eine Flowchart-UI zu nutzen, wünsche ich mir schon lange.
    Ich mache vor allem Datenverarbeitung und zeichne oft Flussdiagramme, um Pipelines zu erklären oder selbst zu verstehen.
    Eine Entwicklungs-UI in diese Richtung wäre vermutlich hilfreich, um schwer handhabbare Codebasen zu bearbeiten, die von Leuten ohne CS-Hintergrund erstellt wurden.

    • Denken Sie da an Tools wie LabView?
      https://www.ni.com/en/shop/labview.html
    • Ist das ähnlich wie das, was BlueJ in Java macht?
    • Ich frage mich, ob es bei dem Problem eher darum geht, Datenfluss zu visualisieren, oder Kontrollfluss.
    • Es wäre großartig, wenn man Diagramme und Code gemeinsam auf derselben Canvas skizzieren könnte.
      Visuelle Dokumentation würde dadurch wohl deutlich einfacher.

  • Wirklich cool. Mir gefällt, dass beim Springen zu einer Methode oder Deklaration nicht die ganze Datei in einem Nebentab geöffnet wird, bis zur Definition gescrollt, sondern dass nur die relevanten Codeausschnitte angezeigt werden.
    Ich muss oft vergleichen, wo eine Methode aufgerufen wird und wo sie definiert ist, und verliere dabei häufig die Methode aus den Augen, die ich gerade gelesen habe; das ist ziemlich frustrierend.
    Es ist gut, eine Methode daneben „anheften“ zu können und sie in einer angehefteten Ansicht durchzusehen, ohne aus Versehen in der ganzen Datei zu scrollen.
    Beim kurzen Ausprobieren war es leider stark mauszentriert, und als ich Methoden innerhalb anderer Methoden gefolgt bin, hatte ich am Ende zu viele schwebende Fenster zu verwalten.
    Wenn es Pfeile oder Linien gäbe, mit denen man verfolgen kann, welches Fenster das „Eltern“-Fenster ist, ließe sich daraus leicht eine Art Flussdiagramm bauen.
    Persönlich habe ich ein paar Kritikpunkte, aber es ist schön, in diesem Bereich eine andere Denkweise zu sehen, und ich hoffe, dass es Erfolg hat.

    • Ich verstehe, warum dir das gefällt, aber langfristig könnte der Nettoeffekt meiner Meinung nach negativ sein.
      Ich halte es für nützlich, einigermaßen zu wissen, was im Code wo liegt.
      Man könnte jahrelang an einem Projekt arbeiten und trotzdem nicht wissen, was die Dateien eigentlich tun, weil man immer nur mit kleinen Ausschnitten arbeitet.
    • Literarisches Programmieren setzt das in einer Dimension um, also mit vertikalem Scrollen, und bietet zwei Ansichten.
      Es gibt den Quellcode, in dem Kommentare und Text gemischt sind, und eine schön gesetzte Codeansicht mit formatiertem Text und Hyperlinks zur Navigation.
      http://literateprogramming.com/
    • Stimmt, wir müssen daran arbeiten, die Navigation per Tastatur einfacher zu machen.
      Mich würde interessieren, was du dir als Bezugspunkt für das „Eltern-Fenster“ vorstellst.
      Möchtest du ein bestimmtes Fenster als Anchor markieren können, oder soll eine Heuristik so einen Anchor finden?

  • Glückwunsch zum Launch. Ich bewege mich zurzeit in die genau entgegengesetzte Richtung; wegen Konzentration und ADHS-Tendenzen hilft es mir, weniger hin und her zu springen und mich weniger überwältigt zu fühlen.
    Ein Fenster, alles minimieren und vor allem keine Tree-Navigation.
    Wenn ich zu einer Datei muss, nutze ich in IntelliJ das Menü der zuletzt verwendeten Elemente oder springe zu Datei-Markern.
    Das bedeutet, dass ich mir Datei-Marker merken und die Absicht haben muss, dorthin zu gehen. Für vim-Shortcuts nutze ich das IdeaVim-Plugin.
    Für mich macht diese Arbeitsweise Programmieren viel fokussierter und angenehmer.
    Das ist Teil einer Entwicklung von Multiscreen zu Widescreen und dann wieder zurück zu einem einzelnen Bildschirm.
    In großen, ausgereiften Codebasen wie den erwähnten nutze ich ein LLM als Wegweiser.

    • Wie verwendest du es? Mich würde auch interessieren, was du unter einer großen, ausgereiften Codebasis verstehst.
      Meiner Erfahrung nach machen LLMs schon bei einer einzelnen Datei ziemlich viele Fehler und Annahmen.
    • Verstehe. Mich würde interessieren, wie du ein LLM als Wegweiser nutzt.
      Nach meiner Erfahrung liefern LLMs, wenn man sie fragt, wo der Ablauf eines Features liegt, zwar gute Einstiegspunkte, aber die Details musste ich oft selbst herausfinden; manchmal zeigen sie auch auf Stellen, die zwar relevant sind, aber nicht das, was ich gesucht habe.

  • Interessant. Ein paar Notizen:
    Obsidian hat eine ähnliche Funktion namens „Canvas“, deren Workflow man sich ansehen könnte.
    Für mich ist es als eigenständiges Tool nutzlos; ich bräuchte es als Idea-Plugin.
    Am meisten stört mich das Erstellen von Layouts. Schön wäre eine AI, die einen Git-Patch oder Bugfix nimmt und ein passendes Layout dafür erstellt.
    Layout-Sharing sollte sehr einfach sein.
    Es wäre gut, die Git-Historie als weitere Dimension zu integrieren. Diff- und Blame-Anzeigen direkt im Editor wären schön.
    Es gibt Daten, die man für AI-Training nutzen kann: Git-Commits.
    Debugging sollte ebenfalls als weitere Dimension integriert werden, ebenso Profiler-Daten.

    • Im Demovideo sieht es so aus, als würde es nicht eigenständig laufen, sondern innerhalb von VSCode.
      Was dort angeboten wird, bekommt man also mit.
      Wenn man Tools aus der Idea-Familie nutzt, scheint es derzeit keinen Weg zu geben.
    • Das Tool sieht gut aus, und ich würde es gerne beruflich ausprobieren. Da ich mit Android/Kotlin arbeite, noch eine Stimme für IDEA-Integration.

  • So etwas wollte ich schon lange ausprobieren. Gibt es eine Möglichkeit, Updates zu bekommen?
    Besonders warte ich darauf, zumindest beim ersten Ausprobieren, die AI-Funktionen deaktivieren zu können.
    Besonders gefällt mir die Funktion, in eine Funktion hineinzuzoomen und den Rest der Datei auszublenden. Es gab überraschend viele Momente, in denen ich mir genau so etwas gewünscht habe.
    Man könnte das wohl auch nutzen, um die Funktionen, an denen man gerade arbeitet, innerhalb einer Datei einfach nebeneinander zu ziehen und so eine einzelne Datei virtuell neu anzuordnen.
    Abgesehen von der Bearbeitungsoberfläche sehe ich in einem Editor viele Möglichkeiten für Visualisierungen.
    Möglich wären die Interaktion zwischen meinem Code und Third-Party-Dependencies, der Dependency-/Call-Graph meines Codes oder Teile davon, Dependency-Graphen auf Klassen- oder Modulebene sowie verschachtelte Call-Graphen, in die man bis zu Aufrufen innerhalb von Objekten hineinzoomen kann.
    In all diesen Fällen nahtlos zwischen Visualisierung und Bearbeitung wechseln zu können, ist die Killerfunktion, auf die dieses Tool offenbar abzielt.
    Sobald Grafik überhaupt in den Editor einzieht, werden noch viele weitere interessante Visualisierungen möglich, etwa Heatmaps zur Häufigkeit von Codeänderungen, Performance-Heatmaps für Code oder das Nachverfolgen der Nutzung von Variablen.
    https://adamtornhill.com/articles/crimescene/codeascrimescen...
    Und schließlich: Falls du The Programmer's Brain nicht gelesen hast, lohnt sich zumindest dieser Podcast:
    https://se-radio.net/2021/06/episode-462-felienne-on-the-pro...
    Es gibt viele Editor-Ideen, die damit zusammenhängen, wie unser Gehirn funktioniert, aber ich habe noch nicht gesehen, dass Editoren sie gut unterstützen.
    Ihr habt in diese Richtung bereits einen Schritt gemacht, vielleicht gibt es also noch mehr Chancen.

    • Leider haben wir noch keinen cleveren Weg gebaut, um sich für Updates anzumelden.
      Ich werde mir überlegen, was der beste Weg ist, und letztlich werden wir Updates direkt im Produkt pushen.
      Ich bin gerade dabei, ein Opt-out für Copilot hinzuzufügen.
      Die Ideen hier sind gut, und ein paar davon würde ich gern gemeinsam besprechen. Wenn es okay ist, schicke ich eine E-Mail/DM.
      Generell würde ich gern mit mehreren Leuten sprechen; Feedback kann an feedback@haystackeditor.com geschickt werden.

  • Mir gefällt wirklich, wie man von Funktion zu Funktion, von Datei zu Datei und wieder zurück navigiert.
    Noch nützlicher wäre es mit einem Navigationsverlauf-Fenster, ähnlich wie der Verlauf im Browser.
    Es sollte beim Wechsel zwischen Dateien und Funktionen eine Liste anzeigen, sodass man vor- und zurückgehen oder direkt an eine beliebige Stelle im Navigationsverlauf springen kann, ohne mühsam durch geöffnete Fenster zu suchen.
    Mit Navigationsverlauf meine ich etwas völlig anderes als den Bearbeitungsverlauf.
    Undo/Redo für Bearbeitungen sollte den Navigationsverlauf nicht vor- und zurückbewegen, und umgekehrt genauso wenig.
    Natürlich könnte es Tastenkürzel geben, um durch den Navigationsverlauf zu gehen.

    • Gute Idee. Ich werde überlegen, wie man das am besten umsetzt.

  • Cool. Hat Bezug zu Code Bubbles: https://dl.acm.org/doi/abs/10.1145/1753326.1753706

    • Genau, Bubbles ist großartig. Besonders das Minimap-Konzept gefällt mir.

  • „Wir speichern Ihren Code nicht und protokollieren ihn nicht. Wir senden Code-Snippets als Eingabe für den Navigations-Copilot an Open AI. Wir werden bald eine Option hinzufügen, um das zu deaktivieren.“
    Wenn diese Option drin ist, würde ich es mir gern ansehen.

    • Auf dem Mac haben wir ein Opt-out für den Navigations-Copilot hinzugefügt.
      Öffne die Command Palette (CMD+SHIFT+P) und verwende den Befehl „Opt out of navigational copilot“.
      Windows/Linux werden bald ebenfalls unterstützt.
      Bitte beachte auch, dass Daten nur dann an Open AI gesendet werden, wenn eine Diagnose vorliegt, dass eine nicht existierende Funktion aufgerufen wird.
    • Ging mir genauso. Ich wäre bereit, die Entwicklung eines solchen Tools zu unterstützen, aber ein direkterer Weg wäre mir lieber.
    • Stimme zu. Es hätte von Anfang an Opt-in sein müssen.
    • In diesem Zustand dürfte es in einem Unternehmen schwer auszuprobieren sein.

  • Ich habe ein Paper veröffentlicht, das die Navigationszeit zwischen einem Canvas-basierten Editor (Code Bubbles), einem traditionellen tab-basierten Editor (Eclipse) und einem von mir entworfenen Carousel-basierten Editor (Patchworks) vergleicht.
    Unser Ergebnis war, dass Canvas zu viel Freiheit bietet.
    https://austinhenley.com/pubs/Henley2014CHI_Patchworks.pdf

    • Interessant. Über die räumliche Anordnung einer IDE habe ich bisher kaum tiefer nachgedacht.
      Rückblickend nutze ich selbst in VS Code keine Tabs mehr, weil ich zu viele Dateien geöffnet habe.
      Ich sehe mir einfach immer nur eine Datei an und suche, wenn ich wechseln muss, mit Cmd-P oder springe zwischen zuletzt genutzten Dateien.
      Das funktioniert gut, aber man muss Datei-/Verzeichnisnamen ständig im Kopf behalten.
    • Ich habe das Paper nur kurz angelesen, aber nach der Diskussion zu Eclipse scheint es, als wären die Teilnehmer deutlich effizienter gewesen, wenn sie es eher wie eine IDE statt wie einen Mehr-Tab-Editor genutzt hätten.
      Methoden zu finden wäre mit einer alphabetisch sortierten Outline-Ansicht wahrscheinlich ein viel kleineres Problem gewesen.
    • Wirklich interessant. Wir haben zwischen Grid und Canvas abgewogen, uns aber für Canvas entschieden, weil wir glauben, dass die Navigation in der Praxis einfacher ist.
      Wenn es okay ist, würde ich gern darüber sprechen und dir eine E-Mail schicken.
    • Interessant. Patchworks ähnelt in gewisser Weise der Art, wie ich Doom Emacs konfiguriere.
      Ich habe über mehrere Workspaces hinweg 4–6 Code-Panels und wechsle mit SPC TAB Zahl.
    • Hervorragende Analyse. Für mich nimmt sowohl ein Canvas-basierter als auch ein Carousel-basierter Ansatz beim Arbeiten mit sehr großen Codebases die Last, ständig eine beträchtliche Menge kognitiver Daten im Kopf behalten zu müssen.
      Um das Tool richtig zu nutzen, braucht man praktisch auch ausreichend Widescreen.
      Der Kern ist, sich daran zu gewöhnen, Dateien horizontal statt vertikal zu behandeln.
      Dieses vertikale Denken ist ziemlich tief darin verwurzelt, wie wir damals unser erstes Hello World geschrieben haben.

  • Glückwunsch zum Launch. Sieht nach einem großartigen und gut umgesetzten Tool aus, ich freue mich darauf, es auszuprobieren.
    Mir fällt dabei eine Funktion ein, die ich mir schon lange wünsche und ein paar Mal manuell gebaut habe, aber nie in einer teilbaren Form: die Möglichkeit, einen Codepfad in ein einzelnes Skript oder eine einzelne Quelldatei aufzulösen.
    Ich würde gern so etwas wie einen Breakpoint setzen und auf einen „Unravel“-Button klicken, sodass am Ende eine einzelne Datei übrig bleibt, die alles zeigt, was bis zu diesem Punkt passiert.
    Idealerweise wäre diese Datei sogar als einzelnes Skript ausführbar.
    Im Kern entspricht das der Ansicht, die ein Schritt-für-Schritt-Debugger bietet, aber statt über mehrere Dateien und mehrere Ebenen zu springen, möchte ich alles von Anfang bis Ende in einer einzigen Datei sehen.

    • Warum brauchen Sie das? Welches Problem versuchen Sie zu lösen? Was ist das gewünschte Ergebnis?
      Meiner Ansicht nach geht bei der Kommunikation viel verloren, wenn sich Leute statt auf Anforderungen, Parameter und Ergebnisse auf konkrete Implementierungsdetails konzentrieren.
      Mich interessiert, warum Sie genau diese Implementierung wollen und welche Funktion oder welchen Zweck sie erfüllen soll.