Semantic Search schlägt den Deep Agent: Was ein neues Paper über Code-Suche wirklich zeigt

Ein Coding-Agent schreibt nicht die ganze Zeit Code. Einen erheblichen Teil seiner Arbeit verbringt er damit, überhaupt erst herauszufinden, wo im Repository die relevante Logik steckt.

Dafür haben sich zwei grundverschiedene Ansätze etabliert. Der klassische Weg baut vorab einen semantischen Index über das Repository und lädt zu einer Frage passende Codeabschnitte in den Kontext. Der neuere Weg lässt einen Agenten mit grep, glob, Verzeichnislisten und Dateizugriff durch das aktuelle Working Tree laufen. In der inzwischen verbreiteten Deep-Agent-Variante delegiert der Hauptagent diese Suche an einen Subagenten, damit dessen zahlreiche Suchresultate nicht den eigenen Kontext verschmutzen.

Das klingt zunächst nach einem Fortschritt. Der Agent liest den echten Code in seiner natürlichen Struktur, arbeitet immer auf dem aktuellen Stand und hält den Hauptkontext sauber. Genau diese Architektur steckt hinter vielen modernen CLI-Agenten und gilt inzwischen fast als Best Practice für Context Engineering.

Das am 2. August 2026 veröffentlichte Paper „Deep Agentic Search for Repository-Level Code Question Answering: An Empirical Study“ stellt diese Annahme erstmals in einem direkten Vergleich auf den Prüfstand.¹ Das Ergebnis fällt überraschend deutlich aus: Der einfachere Agent mit semantischem Index beantwortete 65,2 Prozent der Fragen korrekt. Der Deep Agent kam nur auf 46,2 Prozent und kostete pro richtiger Antwort mehr als doppelt so viel.

Das ist keine allgemeine Widerlegung agentischer Code-Suche. Es ist aber ein ziemlich gutes Beispiel dafür, dass mehr Orchestrierung nicht automatisch mehr Intelligenz bedeutet. Manchmal baut man mit einem Subagenten vor allem eine zusätzliche Stelle ein, an der Information verloren gehen kann.

Zwei Antworten auf dasselbe Kontextproblem

Ein grosses Repository passt nicht vollständig in das Kontextfenster eines Sprachmodells. Selbst wenn es theoretisch hineinpasst, wäre es meistens keine gute Idee, alles hineinzuschieben. Relevanter Code geht zwischen Tests, generierten Dateien, Hilfsklassen und ähnlich benannten Implementierungen unter. Mehr Kontext ist nicht automatisch besserer Kontext.

Die beiden untersuchten Architekturen lösen dieses Problem unterschiedlich.

Beim Semantic Search wird das Repository in Chunks zerlegt. Ein Embedding-Modell erzeugt daraus Vektoren, die in einer Datenbank landen. Der Agent formuliert Suchanfragen, bekommt die semantisch ähnlichsten Codeabschnitte zurück und kann bei Bedarf die zugehörigen Dateien lesen. Das ist im Kern ein RAG-System für Quellcode.

Beim Deep Agentic Search gibt es keinen vorbereiteten Vektorindex. Ein Hauptagent plant die Aufgabe und delegiert die Repository-Erkundung an einen Subagenten. Dieser arbeitet in einem eigenen Kontext, verwendet Werkzeuge wie grep, glob, ls und Datei-Lesezugriffe und liefert am Ende eine verdichtete Antwort zurück. Der Hauptagent sieht nicht die gesamte Suchhistorie, sondern nur das Ergebnis der Übergabe.

Beide Ansätze haben offensichtliche Stärken und Schwächen:

Ansatz	Stärke	Typische Schwäche
Semantischer Index	Findet Konzepte auch ohne exakte Bezeichner und liefert kompakten Kontext	Chunk-Grenzen können Struktur zerstören, der Index kann veraltet sein und Retrieval kann am richtigen Code vorbeigehen
Direkte Grep-Suche	Arbeitet auf dem aktuellen Dateisystem und folgt exakten Symbolen und Abhängigkeiten	Produziert viel Rohtext, braucht viele Tool-Aufrufe und kann sich in Suchschleifen verlieren
Delegierter Subagent	Hält den Hauptkontext von der Suchhistorie frei	Der Planner muss eine gute Aufgabe formulieren und dem Ergebnis des Subagenten vertrauen

Der interessante Punkt des Papers ist deshalb nicht bloss, welcher Ansatz mehr Treffer liefert. Die Autoren zeichnen sämtliche Tool-Aufrufe und Agententrajektorien auf und untersuchen, warum die Systeme scheitern.

Ein vergleichsweise sauberer Versuchsaufbau

Die Studie verwendet den Benchmark SWE-QA mit 720 offenen Fragen zu 15 verbreiteten Python-Repositories. Jedes Repository liefert 48 Fragen aus den Kategorien What, Why, Where und How. Die Projekte reichen von ungefähr 13.000 bis über 800.000 Python-Zeilen.

Vier Modelle beantworten jede Frage einmal mit Semantic Search und einmal mit Deep Agentic Search:

• Gemini 2.5 Flash
• Gemini 2.5 Pro
• Gemini 3 Flash
• Qwen3-235B

Damit entstehen acht Bedingungen mit insgesamt knapp 5.760 Läufen. Jede Frage startet in einem frischen Kontext und sieht nur das betroffene Repository. Das verhindert, dass frühere Fragen den Agenten beeinflussen.

Beide Varianten basieren auf LangChain. Der Semantic-Agent ist ein ReAct-Agent mit drei Werkzeugen: Repository-Struktur anzeigen, den Vektorindex durchsuchen und Dateien lesen. Der Deep Agent verwendet das Standard-Harness von LangChain Deep Agents mit Aufgabenplanung, Subagenten, Grep, Glob, Verzeichnislisten und Dateizugriff.

Der semantische Index ist dabei keine aufwendig optimierte Speziallösung. Die Autoren verwenden Chroma, text-embedding-3-small, Chunks von 500 Tokens mit 50 Tokens Überlappung und zehn Treffern pro Suche. Der Deep Agent verwendet für Planner und Subagent dasselbe Modell. Jeder Lauf endet nach maximal 900 Sekunden oder 80 Agentenschritten.

Bewertet werden die Antworten durch Claude Sonnet 4.6 anhand von Korrektheit, Vollständigkeit, Relevanz, Klarheit und Begründung. Ein Ergebnis ab 70 von 100 Punkten zählt als bestanden. Das ist zunächst eine Schwachstelle, weil ein LLM ein anderes LLM beurteilt. Die Autoren haben den Judge deshalb an 800 Antworten von drei unabhängigen Softwareentwicklern prüfen lassen. Die Übereinstimmung zwischen menschlicher Mehrheitsentscheidung und Judge lag bei 84 Prozent, Cohen’s Kappa bei 0,74. Das ist nicht perfekt, aber ausreichend hoch, um das Hauptergebnis nicht als reines Judge-Artefakt abzutun.

Das Ergebnis ist nicht knapp

Über alle Modelle hinweg bestand Semantic Search 65,2 Prozent der Fragen. Deep Agentic Search erreichte 46,2 Prozent. Die Fehlerquote lag bei 21,9 gegenüber 34,4 Prozent.

Entscheidend ist, dass die Richtung bei jedem einzelnen Modell gleich war:

Modell	Semantic Search	Deep Agentic Search
Gemini 2.5 Flash	48,4 %	42,8 %
Gemini 2.5 Pro	54,2 %	44,2 %
Gemini 3 Flash	89,3 %	39,7 %
Qwen3-235B	68,8 %	58,2 %

Der extreme Unterschied bei Gemini 3 Flash fällt auf. Selbst wenn man diesen Ausreisser gedanklich abschwächt, bleibt Semantic Search bei allen vier Modellen vorne. Die statistischen Tests der Studie zeigen für jede Modellpaarung einen signifikanten Vorteil.

Auch auf Repository-Ebene ist das Muster stabil. Deep Agentic Search liegt nur bei Django knapp vorne, dort um drei Punkte. Auf den übrigen 14 Repositories gewinnt Semantic Search. Selbst SymPy mit ungefähr 861.000 Python-Zeilen liegt noch 13,7 Punkte auf der Seite des Index. Der Abstand wird mit wachsender Repository-Grösse zwar kleiner, kehrt sich im untersuchten Bereich aber nicht um.

Das spricht gegen die einfache Vermutung, ein Vektorindex funktioniere nur bei kleinen Projekten und direkte Exploration werde ab einer bestimmten Grösse automatisch besser.

Mehr Arbeit, weniger richtige Antworten

Deep Agentic Search war nicht nur ungenauer, sondern auch teurer.

Im Mittel kostete eine korrekte Antwort mit Semantic Search 0,32 US-Dollar, mit dem Deep Agent 0,74 US-Dollar. Damit war die delegierte Suche pro richtiger Antwort etwa 2,3-mal so teuer.

Bei Qwen3-235B ist der Unterschied besonders drastisch. Der Semantic-Agent verbrauchte im Mittel ungefähr 34.000 Input-Tokens pro Frage. Der Deep Agent kam auf etwa 761.000. Die Kosten pro bestandener Frage lagen bei 0,012 gegenüber 0,291 US-Dollar.

Auch zusätzliche Tool-Aufrufe kauften keine höhere Genauigkeit. In beiden Architekturen sank die Erfolgsrate mit längeren Trajektorien. Das bedeutet nicht zwingend, dass Tool-Aufrufe die Antwort verschlechtern. Schwierige Fragen erzeugen wahrscheinlich längere Suchen und bleiben gleichzeitig schwer. Die Daten liefern aber keinen Hinweis darauf, dass der höhere Aufwand die schwierigen Fälle am Ende rettet.

Von allen Tool-Aufrufen des Deep Agents fanden 68,8 Prozent innerhalb eines Subagenten statt. Der Hauptagent sah also mehr als zwei Drittel der eigentlichen Recherche nie direkt. Genau an dieser Grenze entstand der häufigste neue Fehler.

Der Subagent löst Kontextverschmutzung und erzeugt Übergabeverlust

Die Autoren klassifizieren alle 1.621 fehlgeschlagenen Läufe nach Fehlerursache. Dabei zeigen die beiden Architekturen deutlich unterschiedliche Signaturen.

Beim Semantic-Agent waren 53,6 Prozent der Fehler klassische Retrieval- oder Lokalisierungsfehler. Der relevante Code wurde nicht gefunden oder der Agent landete in der falschen Datei. Weitere Fehler entstanden durch zu wenig Evidenz oder dadurch, dass vorhandener Code falsch interpretiert wurde.

Das ist erwartbar. Ein Retrieval-System ist nur so gut wie seine Treffer. Wenn der richtige Chunk nicht im Kontext landet, kann das Modell die korrekte Antwort kaum rekonstruieren.

Beim Deep Agent war dagegen die grösste Fehlerklasse ein Coordination Breakdown zwischen Planner und Subagent. Sie machte 41,8 Prozent aller Deep-Fehler aus. Weitere 13,5 Prozent waren nicht terminierende Schleifen.

Besonders unangenehm ist, dass die Übergabefehler meistens nicht sichtbar waren. In 91 Prozent dieser Fälle lieferte das System trotzdem eine flüssige und selbstbewusste Antwort. Der Subagent hatte relevante Zusammenhänge übersehen, die Aufgabe falsch eingegrenzt oder seine Evidenz unvollständig verdichtet. Der Hauptagent behandelte das Resultat anschliessend wie eine verlässliche Grundlage.

Der Deep Agent entfernt also nicht einfach Kontextverschmutzung. Er tauscht sie gegen ein Kompressions- und Vertrauensproblem:

1. Der Planner muss die Suchaufgabe vollständig genug formulieren.
2. Der Subagent muss die richtigen Dateien finden.
3. Er muss die entscheidenden Details erkennen.
4. Er muss sie ohne relevanten Verlust zusammenfassen.
5. Der Planner muss bemerken, falls die Übergabe unvollständig ist.

Bei einer einzigen Repository-Frage ist diese Kette offenbar häufiger schädlich als nützlich. Der Hauptagent hätte den kompakten Retrieval-Kontext direkt lesen können. Stattdessen bekommt er eine zweite Modellantwort über den Code und muss darauf weiterdenken.

Andere Papers kommen zu anderen Ergebnissen

Wer nur das Hauptergebnis liest, könnte daraus ableiten, dass Agenten mit Grep grundsätzlich schlechter sind als RAG. Die Forschungslage gibt das nicht her. Mehrere aktuelle Arbeiten kommen zu Ergebnissen, die auf den ersten Blick in die entgegengesetzte Richtung zeigen.

SWE-Explore: Agentische Explorer lokalisieren Code besser

SWE-Explore isoliert Repository-Erkundung als eigene Fähigkeit.² Ein System bekommt ein Issue und soll unter einem festen Zeilenbudget die relevanten Codebereiche ranken. Der Benchmark umfasst 848 Issues aus 203 Repositories und zehn Programmiersprachen.

Dort bilden agentische Explorer eine klare Spitzengruppe vor klassischem Retrieval. Das widerspricht dem neuen Paper aber nur scheinbar. SWE-Explore misst, ob ein Explorer die Codezeilen findet, die später für einen Patch benötigt werden. Es misst nicht, ob ein Planner nach einer verdichteten Subagenten-Antwort eine offene Architekturfrage korrekt beantwortet.

Der Unterschied ist wichtig. Für einen Patch kann eine breite Liste relevanter Dateien bereits sehr wertvoll sein. Für eine präzise Warum-Frage muss die Übergabe zusätzlich den richtigen Mechanismus erklären.

FastContext: Spezialisierte Subagenten können funktionieren

Microsofts FastContext trainiert kleine spezialisierte Modelle gezielt als Repository-Explorer.³ Sie suchen parallel, liefern konkrete Dateipfade und Zeilenbereiche und werden anhand erfolgreicher Coding-Trajektorien optimiert. In Kombination mit Mini-SWE-Agent steigt die Lösungsrate auf mehreren SWE-bench-Varianten um bis zu 5,5 Prozent, während der Tokenverbrauch des eigentlichen Coding-Agenten um bis zu 60 Prozent sinkt.

Das ist ein starkes Argument für getrennte Exploration, aber nicht für jeden beliebigen Subagenten. Im neuen Vergleich verwendet der Deep Agent dasselbe allgemeine Modell für Planner und Explorer und übernimmt das Standard-Harness. FastContext dagegen trainiert die Übergabe selbst: Der Explorer soll keine schöne Zusammenfassung schreiben, sondern überprüfbare Dateipfade und Zeilenbereiche liefern.

Der Unterschied liegt weniger in „ein Agent oder zwei Agenten“ als im Vertrag zwischen ihnen.

Is Grep All You Need?: Das Harness entscheidet mit

Das Paper „Is Grep All You Need?“ vergleicht Grep und Vektorsuche in mehreren Agent-Harnesses und findet häufig Vorteile für Grep.⁴ Der Test betrifft allerdings LongMemEval, also die Suche in langen Gesprächsverläufen statt in Code-Repositories. Zudem zeigt die Studie, dass Resultate stark davon abhängen, wie ein Harness Tool-Ausgaben präsentiert und wie viel irrelevanter Kontext bereits vorhanden ist.

Genau das ist für die Einordnung des neuen Papers relevant. Es vergleicht nicht zwei mathematisch isolierte Suchalgorithmen. Es vergleicht zwei vollständige Systempakete mit unterschiedlichen Werkzeugen, Prompts und Kontrollflüssen. Ein anderes Deep-Agent-Harness kann besser abschneiden. Die Studie belegt vor allem, dass die untersuchte Standardarchitektur keinen kostenlosen Vorteil liefert.

CodeRepoQA: Mittlerer Kontext ist oft besser als maximaler Kontext

Schon CodeRepoQA kam bei einem deutlich grösseren, mehrsprachigen Repository-QA-Datensatz zu dem Ergebnis, dass mittlere Kontextlängen günstiger sind als möglichst viel Kontext.⁵ Das passt zur Beobachtung hinter beiden Suchstrategien: Die eigentliche Kunst ist nicht, dem Modell mehr Repository zu zeigen, sondern die richtige Teilmenge.

Der Streit zwischen Semantic Search und Agentic Search ist deshalb ein Streit um Selektion und Verdichtung, nicht um die maximale Grösse des Kontextfensters.

Was Produktanbieter in der Praxis machen

Produktionssysteme entscheiden sich selten ausschliesslich für eine der beiden Seiten.

Cursor veröffentlichte im November 2025 eigene Offline-Evaluationen und A/B-Tests zur semantischen Code-Suche.⁶ Mit Semantic Search stieg die Genauigkeit bei Repository-Fragen im Mittel um 12,5 Prozent. In grossen Codebasen mit mindestens 1.000 Dateien erhöhte sich auch der Anteil des vom Nutzer behaltenen Agenten-Codes. Cursor betont gleichzeitig, dass der Agent sowohl Grep als auch semantische Suche verwendet und die Kombination die besten Resultate liefert.

GitHub verfolgt mit Copilot einen ähnlichen Ansatz. Repositories werden für semantische Suche indexiert, und der Cloud-Agent kann diesen Index automatisch nutzen, wenn exakte Namen oder Suchmuster fehlen.⁷ Die Dokumentation stellt Semantic Search nicht als Ersatz für Grep dar, sondern als zusätzliche Möglichkeit, konzeptionell passenden Code schneller zu finden.

Anthropic argumentiert aus einer anderen Richtung. In den Best Practices für Claude Code werden Subagenten gerade bei komplexer Exploration empfohlen, um den Hauptkontext frei zu halten.⁸ Das ist plausibel für lange Sessions, Refactorings, Tests und Aufgaben mit vielen Zwischenschritten. Genau diese Situationen bildet das neue Paper jedoch nicht ab. Jede Frage beginnt dort in einem frischen Kontext und endet mit einer reinen Textantwort.

Damit passen Forschung und Praxis besser zusammen, als es zunächst aussieht:

• Für eine einzelne read-only Frage über einen stabilen, indexierbaren Codebestand ist Retrieval sehr stark.
• Für exakte Symbole, aktuelle Working Trees und unbekannte Dateistrukturen bleibt Grep unverzichtbar.
• Für lange Coding-Sessions kann ein Subagent Kontext sparen, muss seine Evidenz aber überprüfbar übergeben.
• Für reale Coding-Aufgaben ist meistens ein Hybrid sinnvoller als eine dogmatische Entscheidung.

Was das Paper ausdrücklich nicht beweist

Die Arbeit ist umfangreich, aber ihr Geltungsbereich ist eng.

Erstens untersucht sie Question Answering, nicht Softwareentwicklung. Der Agent ändert keinen Code, startet keine Anwendung und führt keine Tests aus. Bei einer echten Fehlerbehebung kann direkte Exploration Vorteile liefern, die in einer Textantwort nicht sichtbar werden. Ein Agent kann beispielsweise durch einen Testlauf einen falschen Suchpfad erkennen und korrigieren.

Zweitens stammen alle Repositories aus dem Python-Ökosystem. Ob die Resultate auf grosse Java-Monorepos, TypeScript-Frontends oder polyglotte Unternehmenslandschaften übertragbar sind, bleibt offen.

Drittens verwendet jede Seite genau ein LangChain-Harness. Systemprompt, Tool-Beschreibungen, Ergebnisformat des Subagenten und Abbruchbedingungen beeinflussen Agenten stark. Die Autoren weisen selbst darauf hin, dass ihre Zahlen für diese konkrete Paarung gelten und nicht für jede denkbare Implementierung.

Viertens sind die Repository-Snapshots statisch. Das ist die ideale Umgebung für einen Index. In einem aktiven Branch kann der Index nach wenigen Commits veraltet sein. Das Re-Embedding selbst ist billig, aber Änderungsdetektion, Invalidierung und Betrieb der Pipeline sind trotzdem Infrastruktur.

Fünftens testet die Studie keine langen Sitzungen. Der Deep Agent soll den Hauptkontext über viele Schritte sauber halten. Wenn jede Frage einen neuen Kontext bekommt, kann dieser Vorteil kaum auftreten.

Und schliesslich befindet sich das Paper noch im Review. Es ist eine arXiv-Vorabveröffentlichung, keine bereits begutachtete endgültige Version.

Die sinnvollere Architektur ist ein Router

Aus den Ergebnissen folgt für mich weder „RAG ist zurück“ noch „Subagenten sind überschätzt“. Die sinnvollere Konsequenz ist eine Architektur, die Suchwerkzeuge nach Aufgabe auswählt.

Ein praktikabler Repository-Agent könnte so arbeiten:

1. Exakte Suche zuerst, wenn die Frage Symbolnamen, Fehlermeldungen, Endpunkte oder Konfigurationsschlüssel enthält. Dafür sind Grep, Symbolsuche und Code Navigation präziser als Embeddings.
2. Semantische Suche als günstiger Standard, wenn der Nutzer nach einem Konzept fragt und die Bezeichner nicht kennt, etwa „Wo wird die Autorisierung für externe Requests geprüft?“
3. Direkte Dateizugriffe zur Verifikation, sobald ein Treffer vorliegt. Ein Embedding-Chunk sollte ein Einstiegspunkt sein, nicht die endgültige Evidenz.
4. Delegierte Exploration nur bei Bedarf, etwa wenn die ersten Treffer widersprüchlich sind, mehrere Subsysteme betroffen sind oder kein aktueller Index existiert.
5. Strukturierte Übergaben statt Prosa, mit Dateipfad, Zeilenbereich, Symbol, kurzer Aussage und Unsicherheit. Der Planner sollte die Quelle selbst nachlesen können.
6. Tests und Laufzeitbeobachtung als eigene Evidenz, sobald die Aufgabe über reines Verstehen hinausgeht.

Der Subagent sollte dem Hauptagenten also nicht bloss sagen: „Die Authentifizierung passiert im Middleware-Layer.“ Eine bessere Übergabe sähe eher so aus:

Behauptung: Requests an externe APIs erhalten ihr Token im WebClient-Filter.
Quelle: src/main/java/.../AuthFilter.java, Zeilen 42-71
Aufrufer: ExternalClientConfig.java, Zeilen 28-39
Offen: Der Refresh-Pfad wurde nicht geprüft.

Damit wird der Handoff überprüfbar. Der Planner kann die relevanten Stellen selbst lesen, statt eine weitere Modellantwort als Wahrheit zu übernehmen.

Ein Router kann zusätzlich aus seinen Fehlern lernen. Wenn semantische Treffer häufig am falschen Modul landen, braucht der Index bessere Chunk-Grenzen, Metadaten oder ein Reranking. Wenn Subagenten regelmässig entscheidende Details verlieren, braucht die Übergabe einen strengeren Output-Vertrag. „Mehr Reasoning“ ist in beiden Fällen keine ausreichende Diagnose.

Die eigentliche Lehre betrifft nicht nur Code-Suche

Das Paper zeigt ein allgemeines Problem agentischer Systeme: Jede Aufteilung in Planner, Worker, Reviewer und Spezialagenten schafft neue Schnittstellen. Diese Schnittstellen sind keine neutralen Rohre. Sie komprimieren Information, verändern Prioritäten und verbergen Unsicherheit.

Ein einzelner Agent kann an zu viel Kontext scheitern. Ein Multi-Agent-System kann daran scheitern, dass der richtige Kontext nie beim entscheidenden Agenten ankommt.

Die Lösung ist deshalb nicht zwangsläufig weniger Agentik, sondern bessere Verträge zwischen den Komponenten. Quellen müssen erhalten bleiben. Unsicherheit darf nicht aus der Zusammenfassung verschwinden. Ein Planner muss erkennen können, ob ein Worker tatsächlich recherchiert oder nur eine plausible Antwort erzeugt hat.

Für Repository-Fragen liefert das neue Paper eine klare Ausgangsregel: Wenn ein aktueller Index vorhanden ist und nur eine präzise read-only Antwort benötigt wird, ist Semantic Search der stärkere und günstigere Default. Direkte Exploration und Subagenten gehören dorthin, wo sie einen messbaren Zusatznutzen haben.

Die Zukunft der Code-Suche ist damit wahrscheinlich weder ein Vektorindex noch ein Heer von Grep-Agenten. Sie ist ein hybrides System, das weiss, wann welcher Aufwand gerechtfertigt ist und das seine Evidenz nicht an der nächsten Agentengrenze verliert.

Footnotes#

1. Amirkia Rafiei Oskooei et al.: Deep Agentic Search for Repository-Level Code Question Answering: An Empirical Study, arXiv v1, 2. August 2026. ↩

2. Shaoqiu Zhang et al.: SWE-Explore: Benchmarking How Coding Agents Explore Repositories, 2026. ↩

3. Shaoqiu Zhang et al.: FastContext: Training Efficient Repository Explorer for Coding Agents, 2026. ↩

4. Sahil Sen et al.: Is Grep All You Need? How Agent Harnesses Reshape Agentic Search, 2026. ↩

5. Ruida Hu et al.: CodeRepoQA: A Large-scale Benchmark for Software Engineering Question Answering, 2024. ↩

6. Cursor Research: Improving agent with semantic search, 6. November 2025. ↩

7. GitHub Docs: Indexing repositories for GitHub Copilot. ↩

8. Anthropic: Claude Code: Best practices for agentic coding. ↩