Die Engine, die unseren Agenten das ganze Repository zeigt
Diese haben wir für uns selbst gebaut. Ein Agent, der Code prüfen oder umbauen sollte, sah bisher die geöffnete Datei und wenig mehr, also las er sich Vermutung für Vermutung durch das Projekt. Die Engine zerlegt eine Codebasis in Syntaxbäume und einen Nutzungsgraphen, gewichtet, was rund um eine Änderung zählt, und beantwortet Anfragen, die exakte Treffer mit Bedeutung verbinden. Jede Prüfung und jeder Umbau beginnt bei uns jetzt bei der Struktur des ganzen Repositorys statt bei der geöffneten Datei.
- BrancheEntwicklerwerkzeuge
- Art der ArbeitInterne Engine, für unsere eigenen Agenten gebaut
- StatusIm Einsatz in unserer eigenen Arbeit, wird weiter ausgebaut
Zuerst für unsere eigenen Agenten
Das ist kein Kundenprojekt. Es ist der Teil unserer eigenen Werkzeugkette, der entscheidet, was ein Agent zu sehen bekommt, bevor er irgendetwas anfasst. Er indexiert ein Projekt einmal, hält diesen Index beim Speichern aktuell und beantwortet strukturelle Fragen zum Code: was ist wo definiert, was nutzt es, was zieht eine Datei herein und wer zieht diese Datei herein.
Prägend war eine einzige Einschränkung, das Denkbudget. Eine Antwort, die technisch vollständig, aber zu groß zum Lesen ist, taugt weniger als eine kleinere, die hineinpasst. Deshalb wird jede Antwort auf ein festes Budget gekürzt und bleibt dabei gültige strukturierte Ausgabe, und Dateien kommen als Signaturen zurück statt als ganze Rümpfe. Das Budget soll in die Arbeit fließen, nicht ins Lesen.
Das Problem war unser eigenes
Kein Kunde hat danach gefragt. Es entstand beim Zuschauen, wie unsere eigenen Agenten mit dem falschen Bild großer Codebasen arbeiteten.
Eine geöffnete Datei ist keine Codebasis
Ein Agent, der eine Funktion ändern sollte, sah die Funktion und die Datei drumherum. Was sie aufrief, was sie ihrerseits aufrief und welche Teile des Projekts die Änderung bemerken würden, lag außerhalb des Rahmens. Die Änderung wurde isoliert gedacht und ebenso isoliert geprüft.
Ein ganzes Projekt lesen, um eine Sache zu finden
Ohne Karte heißt die richtige Stelle finden: Dateien öffnen und wieder verwerfen. Jede verworfene Datei ist bereits aus demselben Budget bezahlt, das die eigentliche Arbeit braucht. In einem großen Repository fällt dieser Preis an, bevor ein einziger nützlicher Gedanke beginnt.
Eine Art von Suche hat nie gereicht
Eine exakte Namenssuche übersieht Code, der dieselbe Aufgabe unter anderem Namen erledigt. Eine bedeutungsbasierte Suche übersieht genau den Bezeichner, den jemand gerade getippt hat. Sich für eine von beiden zu entscheiden, machte das Werkzeug jedes Mal auf andere Weise falsch.
Was wir gebaut haben
Ein Index, der Struktur versteht, eine Suchschicht, die drei Blickweisen mischt, und harte Grenzen dafür, was eine einzelne Antwort kosten darf.
Eine Strukturkarte statt eines Stapels Dateien
Die Engine zerlegt Quelltext in Syntaxbäume und holt heraus, was in jeder Datei tatsächlich deklariert ist. So lässt sich ein Projekt über seine Struktur beschreiben statt über seinen Text.
- Funktionen, Klassen, Methoden, Schnittstellen, Typen, Aufzählungen, Strukturen, Merkmale und Implementierungen werden über zehn Sprachen hinweg extrahiert
- Eine Datei kann allein als ihre Signaturen zurückkommen, ohne Rümpfe, sodass ein Agent die Form einer Datei sieht, die er nicht gelesen hat
- Die Projektkarte trägt Sprache, Zeilenzahl und Symbolzahl jeder Datei und fällt auf die oberste Ebene zusammen, wenn ein Baum zu groß wird, um zu nützen
Drei Blickweisen, zu einer Rangfolge verschmolzen
Stichwortsuche, wörtlicher Namensabgleich und semantische Ähnlichkeit beantworten jeweils eine andere Art von Frage. Die Engine lässt alle drei über einen Index laufen und verschmilzt sie, statt sich zu entscheiden.
- Volltextsuche, Namensabgleich über Teilzeichenfolgen und Vektorähnlichkeit laufen bei jeder Anfrage gemeinsam
- Die drei Rangfolgen werden per reziproker Rangfusion verbunden, die keine handgesetzten Gewichte braucht, weil sie Positionen vergleicht und nicht Werte, die sich nicht vergleichen lassen
- Wie breit ein Symbol im Projekt referenziert wird, verschiebt die Rangfolge leicht, sodass tragender Code vor Code steht, den niemand aufruft
Was davon abhängt, nicht nur wo es steht
Neben den Definitionen hält die Engine fest, wo Namen verwendet werden, sowohl Aufrufe als auch Typverweise, und welche Datei welche hereinzieht. Aus einem Nachschlagen wird so eine Frage nach den Folgen.
- Ein Nutzungsgraph beantwortet, was davon abhängt, neben der Frage, wo es definiert ist
- Importe laufen in beide Richtungen: was eine Datei hereinzieht und, näherungsweise, welche Dateien im Projekt sie hereinziehen
- Neben der Karte steht ein Fenster in die jüngste Historie, sodass zuletzt Geändertes Teil der Antwort ist und keine eigene Abfrage
Begrenzte Antworten, auf der Maschine, auf der der Code schon liegt
Zwei Regeln haben die Ausgabeseite geprägt. Eine Antwort muss in den Platz passen, den der Aufrufer für sie hat, und kein Code sollte die Maschine verlassen müssen, um verstanden zu werden.
- Jede Antwort wird auf ein festes Budget gekürzt und bleibt dabei gültige strukturierte Ausgabe, sodass eine breite Anfrage den Kontext des Aufrufers nicht überschwemmen kann
- Der gesamte Index ist eine einzige Datenbankdatei auf der Maschine der Entwicklerin oder des Entwicklers, die Vektorsuche läuft im selben Prozess, und kein Code wird irgendwohin hochgeladen
- Ein Speichern wird von einer Dateiüberwachung erkannt und binnen einer halben Sekunde neu indexiert, während eine inhaltlich unveränderte Datei am Hashwert erkannt und übersprungen wird
Was sich in unserer Arbeit geändert hat
Das ist ein internes Werkzeug, ehrlich berichten lässt sich also nur, was es an unserer Arbeitsweise verändert hat. Es gibt keine Messreihe dahinter, und wir veröffentlichen auch keine.
Ganzes Repository
Womit eine Prüfung beginnt
Eine Prüfung oder ein Umbau beginnt mit der Struktur des Projekts: was die Änderung berührt, was es nutzt und wer es hereinzieht. Die geöffnete Datei ist nicht mehr die Grenze dessen, worüber nachgedacht werden kann.
Budget in die Arbeit
Wohin das Denken geht
Signaturen statt Rümpfe und auf Passform gekürzte Antworten heißen: weniger vom verfügbaren Kontext geht für Dateien drauf, die sich als unwichtig erweisen. Der Gewinn liegt in dem, was gar nicht gelesen werden muss.
Bleibt auf der Maschine
Warum wir es auf Kundencode richten können
Eine Indexdatei auf der eigenen Maschine, die Suche läuft im selben Prozess. Zugangsdaten, private Schlüssel und Zertifikatsmaterial bleiben von der Indexierung ausgenommen, und den Index kann nur lesen, wem er gehört.
Sehen Ihre Werkzeuge Ihre Codebasis oder nur die geöffnete Datei?
Erzählen Sie uns, wie Ihr Team heute mit einem großen Repository arbeitet und wo der Kontext ausgeht. Wir sagen Ihnen, was sich zu bauen lohnt und was nicht.
Projekt besprechen