Warum tokeneffiziente Code-Suche für KI-Agenten wichtig ist

Farah Rahman hatte in Doha ein vertrautes Problem: einen Kunden-Bug-Report, einen Slack-Thread um Mitternacht und eine Codebasis mit 1,8 Millionen Zeilen, verteilt auf 43 Repositories. Sie bat einen Agenten, einen Zahlungsfehler zu verfolgen. Beim ersten Durchlauf fraß er so viele Tokens, dass das Modell den Faden verlor. Dann kam eine halbwegs richtige Antwort zurück, verpackt in selbstsicherem Auftreten.

Genau so ein Chaos versucht Semble zu beheben. Sein Versprechen – Code-Suche für Agenten, die 98 % weniger Tokens als grep verbraucht – klingt fast frech. Aber hinter der Schlagzeile steckt ein ernsthafter Wandel: Code-Suche geht nicht mehr nur darum, Text schnell zu finden. Es geht darum, Maschinen nur den winzigen Ausschnitt des Quelltexts zu geben, den sie brauchen. In einer Form, über die sie nachdenken können, ohne Budget oder Kontext zu verbrennen.

Ganz ehrlich: Das ist wichtig, weil der alte Workflow für Menschen gebaut wurde, die Terminals überfliegen. Agenten überfliegen nicht. Sie nehmen auf. Und wenn sie schlecht aufnehmen, wird jede nachgelagerte Aktion wackeliger: Patch-Erstellung, Root-Cause-Analyse, Testauswahl, Dokumentationskorrekturen, sogar Sicherheitsprüfungen.

Warum das jetzt wichtig ist

Zwei Dinge haben sich fast gleichzeitig verändert. Erstens begannen Teams, LLMs direkt in Engineering-Workflows einzubauen, von IDE-Assistenten bis zu autonomen Triage-Bots. Zweitens wurde die Kostenfrage des Kontexts schmerzhaft sichtbar. Klingt plausibel? Große Prompts sind nicht nur teuer; sie sind auch fragil. Wenn ein Agent ein Monorepo prüfen muss, können ein paar schlechte Retrieval-Schritte einen ganzen Durchlauf vergeuden.

Gleichzeitig haben sich die Erwartungen an die Suche verschoben. Entwickler wollen weiterhin die Präzision von grep, aber Agenten brauchen mehr als exaktes String-Matching. Sie brauchen semantische Eingrenzung, symbolbewusste Gruppierung und genug Struktur, um nicht aus irrelevanten Schnipseln zu halluzinieren. Semble sitzt genau in dieser Lücke.

Die Kernidee: Suche für das Modell, nicht nur für den Entwickler

Traditionelles grep ist in einer Sache brillant: Es findet Text. Es ist aber auch brutal wörtlich. Wenn sich Ihr Bug durch eine umbenannte Funktion, eine generierte Datei oder ein Symbol zeigt, das in fünf Wrappern lebt, kann grep blind sein – außer der Mensch kennt genau die richtige Nadel, nach der er stoßen muss.

Code-Suche für Agenten sollte sich anders verhalten. Sie sollte ein riesiges Repository in kompaktes, signalstarkes Beweismaterial verwandeln. Das heißt: nach wahrscheinlicher Relevanz sortieren, umliegende Struktur mitliefern und wiederholtes Boilerplate kürzen, das ein menschliches Auge vielleicht ignoriert, ein Modell aber fröhlich mit Tokens bezahlt.

Der tiefere Punkt ist, dass Tokens inzwischen eine knappe technische Ressource sind. Nicht abstrakt. Wörtlich. Jeder zusätzliche Dateiausschnitt, den Sie einem Agenten geben, kann Latenz, Kosten und Antwortqualität verändern. Deshalb ist ein Tool, das 98 % weniger Tokens als grep verspricht, interessant: nicht weil grep schlecht ist, sondern weil grep nie als Diätplan für LLMs gedacht war.

In der Praxis macht ein besseres System für agentische Code-Suche meist ein paar Dinge gut:

• Indexiert Symbole, nicht nur Zeilen. Funktionen, Klassen, Imports und Verweise sind für Agenten leichter zusammenzufassen als rohe Textblöcke.
• Rangiert nach Kontext, nicht nur nach Trefferanzahl. Ein einzelner hochwertiger Treffer nahe an einem fehlgeschlagenen Test kann wichtiger sein als 27 Vorkommen in generierter Dokumentation.
• Komprimiert aggressiv. Wiederholte Lizenzköpfe, eingebundener Code und doppelte Konstanten sollten den Prompt nicht dominieren.
• Gibt strukturierte Ausschnitte zurück. Dateipfad, Symbolname, Bereich und Abhängigkeits-Hinweise helfen dem Modell, ohne das ganze Verzeichnis erneut zu lesen.
• Bewahrt Nachvollziehbarkeit. Gute Agenten-Suche ist prüfbar. Sie sollten sehen können, warum ein Ausschnitt gewählt wurde.
• Spielt gut mit Tools zusammen. Die beste Suchschicht fügt sich in CI, IDEs und Terminal-Workflows ein, statt ein separates Ritual zu verlangen.

Wenn ein Modell nicht erklären kann, warum es eine Datei ausgewählt hat, vertrauen Sie ihm wahrscheinlich nicht genug, um diese Datei zu bearbeiten.

Es gibt auch einen subtilen Gewinn bei der Bedienbarkeit. Menschen nutzen Suche, um sich zu orientieren. Agenten nutzen Suche, um Handlungen auszulösen. Das ist nicht dieselbe Aufgabe. Ein Entwickler kann 12 noisy Treffer überfliegen und trotzdem wissen, wohin er gehen muss. Ein Agent hingegen kann mit falscher Zuversicht eine ganze Änderung auf einer falschen Annahme aufbauen, wenn die Retrieval-Schicht schlampig ist.

Semble’s Behauptung zur Token-Reduktion sollte daher als Platzhalter für etwas Größeres gelesen werden: bessere Retrieval-Hygiene. Weniger Rauschen bedeutet weniger Halluzinationsfläche. Weniger Rauschen bedeutet auch mehr Raum für das Modell, die tatsächlichen Invarianten im Code zu sehen. Und daraus entstehen nützliche Änderungen.

Wie das in der Praxis aussieht

Kenji Silva, ein Datenanalyst in Krakau, Polen, half seinem Team, eine Pricing-Pipeline zu debuggen, die 14 Services und 9 SQL-Modelle berührte. Eine herkömmliche Suche lieferte 311 Treffer für einen Fehlerstring. Ein tokenbewusster Such-Workflow reduzierte den Arbeitsbestand auf 18 Snippets und senkte die Prompt-Größe des Agenten um 91 %. Er sagte, die erste nützliche Diagnose sei nach 4 Minuten statt nach 29 angekommen.

Rina Popescu, Operations-Leiterin in Tallinn, Estland, nutzte einen Agenten, um Incident-Playbooks über 6 interne Repos hinweg zu prüfen. Der Agent war wiederholt durch vorlagenhaftes Markdown und doppelte Runbooks verwirrt. Sobald ihr Team auf eine Code-Suchschicht umstieg, die Boilerplate deduplizierte, sank die Zahl der falschen Eskalationen des Bots von 17 pro Woche auf 3, und das On-Call-Team begann, nicht mehr die Hälfte seiner Alarme zu ignorieren.

Farah Rahman in Doha führte einen Pilotlauf auf einem Zahlungsdienst mit 248 Testfehlern über einen Monat durch. Ihr Team bat einen Agenten, Fehler nach Root Cause zu clustern. Mit einer besseren Suchschicht gruppierte der Agent 193 davon in 5 Muster und zeigte die exakten Dateipfade an, die sich geändert hatten. Das ersetzte kein menschliches Urteil. Aber es nahm viel blindes Herumstochern heraus.

Häufige Fehler, die man vermeiden sollte

• Token-Ersparnis als den eigentlichen Zweck behandeln. Weniger Tokens sind großartig, aber nicht das Produkt. Wenn die Suche weniger Kontext und schlechtere Belege zurückgibt, haben Sie den Fehler nur komprimiert. Das Ziel sind nicht kleinere Prompts, sondern verlässlichere Entscheidungen.

• Exact-Match-Denken für semantische Aufgaben verwenden. grep ist hervorragend, wenn man den String, das Symbol oder den Importpfad kennt. Agenten tun das oft nicht. Wenn Ihre Retrieval-Strategie nur grep mit einer dünneren Hülle kopiert, verpassen Sie umbenannten Code, implizite Abhängigkeiten und generierte Artefakte.

• Die Repository-Struktur ignorieren. Eine Funktionsdefinition in einem Test-Helper und derselbe Name im Produktivcode sind nicht gleich. Agenten brauchen Hinweise zu Verantwortlichkeiten, Modulgrenzen und Aufrufrichtung. Ohne das können sie mit ernster Miene die falsche Ebene patchen.

• Zu viel Boilerplate einspeisen. Lizenzblöcke, Vendor-Bundles, minifiziertes JS und wiederholte Config-Fragmente können Kontext schnell verbrauchen. Teams übersehen das oft, weil Menschen Unordnung gedanklich überspringen. Modelle überspringen nicht; sie absorbieren.

• Evaluation auslassen. Eine Suchschicht, die in einer Demo clever wirkt, kann bei realen Workloads mit Long-Tail-Namen, polyglotten Repos oder chaotischen Tests scheitern. Messen Sie die Retrieval-Qualität an konkreten Aufgaben: Bug-Lokalisierung, Dateiranking und Antwortkorrektheit, nicht nur Query-Latenz.

• Annehmen, dass der Agent sich selbst korrigiert. Das tut er oft nicht. Wenn der Retrieval-Schritt auf den falschen Dateicluster zeigt, baut das Modell darauf vielleicht eine saubere, aber falsche Geschichte. Gute Suche ist die erste Leitplanke, kein optionales Extra.

Eine praktische Checkliste

1. Beginnen Sie mit einem einzigen schmerzhaften Workflow. Wählen Sie eine Aufgabe wie Bug-Triage, Testfehleranalyse oder Abhängigkeitsverfolgung. Kochen Sie nicht den Ozean, bevor Sie wissen, welcher Suchschmerz am wichtigsten ist.

2. Messen Sie die Prompt-Größe vor und nachher. Verfolgen Sie Eingabe-Tokens, Ausgabequalität und Zeit bis zur ersten nutzbaren Antwort. Wenn Sie die Basislinie nicht benennen können, können Sie die Verbesserung nicht belegen.

3. Protokollieren Sie, warum jedes Snippet zurückgegeben wurde. Bewahren Sie Dateipfad, Symbol und Relevanzsignal auf. Debuggability ist wichtig, wenn ein Modell einen seltsamen Sprung macht.

4. Entfernen Sie Ballast frühzeitig. Schließen Sie eingebundene Verzeichnisse, Build-Artefakte und doppelte generierte Dateien aus. Das ist günstig und zahlt sich oft sofort aus.

5. Bevorzugen Sie strukturierte Retrievals statt roher Text-Dumps. Geben Sie dem Agenten ein kompaktes Paket: Symbolname, umliegende Zeilen und Abhängigkeits-Hinweise. Das ist meist besser, als ganze Dateien einzufügen.

6. Testen Sie mit hässlichen Queries. Probieren Sie umbenannte Funktionen, unvollständige Fehlermeldungen und vage Beschreibungen wie „das Checkout-Ding bricht nach Retry“. Echte Agenten sehen Chaos, keine perfekten Schlüsselwörter.

7. Vergleichen Sie ehrlich mit grep. grep gewinnt für viele menschliche Aufgaben weiterhin. Sehen Sie, wo die neue Suche einem Agenten hilft und wo das alte Tool schneller und einfacher bleibt.

8. Achten Sie auf falsches Selbstvertrauen. Wenn der Agent flüssiger, aber weniger genau wird, verschärfen Sie das Retrieval und verlangen Sie Zitate zurück zu den Quellbereichen.

Wann man das NICHT tun sollte

Nicht jedes Team braucht eine agentenorientierte Suchschicht. Wenn Ihr Repo klein ist, Ihr Stack aufgeräumt ist und Ihre Aufgaben überwiegend von Menschen gesteuert werden, können grep plus eine ordentliche IDE-Suche ausreichen. Aufwendiges Retrieval kann zur Inszenierung werden, wenn der eigentliche Engpass das Verstehen des Produkts ist, nicht das Finden der Datei.

Es ist auch der falsche Schritt, wenn Sie nicht genug operative Disziplin haben, um Ergebnisse zu evaluieren. Eine token-effiziente Suchmaschine kann Experimente günstiger machen, was nett ist, aber sie kann auch schlechtes Agentenverhalten billiger machen. Wenn niemand die Retrieval-Qualität überprüft, automatisieren Sie Verwirrung vielleicht einfach zu geringeren Kosten.

Wo Sie mehr erfahren können

• https://owasp.org/www-project-top-ten/ - für die Sicherheitsgrundlagen, die weiterhin wichtig sind, wenn Agenten Code berühren
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions - eine gute Erinnerung daran, was grep-ähnliche Suche unter der Haube eigentlich tut
• https://en.wikipedia.org/wiki/Information_retrieval - das breitere Fachgebiet hinter Ranking, Relevanz und Suchbewertung

Fwiw, der interessante Teil an Semble ist nicht die Marketingzahl, auch wenn 98 % weniger Tokens eine schöne Schlagzeile sind. Es ist der Hinweis, dass Code-Suche zuerst für maschinelle Leser und erst danach für menschliche Leser neu aufgebaut wird, und dass dieser Wandel prägen wird, wie Teams ihre Software debuggen, patchen und automatisieren. Die Frage ist nicht mehr, ob Agenten Code durchsuchen können - sondern ob Ihre Suchschicht ihnen hilft, klar zu denken, oder sie nur mit noch mehr Rauschen füttert.