Copilot Data Sources / Context Extention

Table of Contents

Copilot Data Sources / Context Extension

Ich nutze schon seit einiger Zeit Copilot in meinen Entwicklungsumgebungen wie VSCode, IntelliJ und manchmal auch Visual Studio. Dabei habe ich mich oft gefragt, wie man die oft nicht sehr nützlichen Code-Vervollständigungen verbessern könnte.

Dazu habe ich zunächst die online verfügbare Dokumentation von Copilot durchgelesen. Mein Ziel war es herauszufinden, wie ich den „Kontext“ manipulieren oder anreichern kann.

Kontext? Also quasi das Kurzzeitgedächtnis der KI, alles was die KI nur über mein Projekt auf dem Rechner weiß und das nicht Teil des Models ist.

Copilot hat verschiedene Modi, die unterschiedliche Datenquellen nutzen, um den Kontext anzureichern/befüllen.

(Nein, die Tabelle ist noch nicht der Grund, diesen Artikel zu lesen, und ja, die Tabelle wurde garantiert von einer KI erstellt.)

Feature	Data Source / Context Used	Description
Code Completion	Current code, open files, project context	Provides real-time code suggestions as you type, using your code and open files as context[1][2].
Copilot Chat	Current code, selected text, project context, documentation	Interactive chat to ask questions or get explanations, using code and documentation as context[2].
Next Edit Suggestions	Current editing context, recent changes, cursor position	Predicts your next likely edit and suggests code based on your editing context (VS Code only)[2].
Copilot Coding Agent	Selected files, prompt, or GitHub issue	Autonomous agent makes code changes or creates pull requests based on your prompt or issue[2].
Spaces/Knowledge Bases	Organized code, documentation, or specs in a Space/knowledge base	Uses collections you provide for context when answering or generating code (Enterprise/preview).

Also jetzt, da ich wusste, dass ich den Autocomplete verbessern kann, indem ich einfach eine Datei offen habe (so einfach), brauchte ich jetzt nur noch sinnvolle Inhalte.

Ein Inhalt, der gut wäre, wäre z.b. wenn die Vervollständigungen auch existierende Methoden an den korrekten Objekten verwenden würden.

Im Default ist, das momentan eher so, als würde man im Traum sich die tollsten und immer passenden Methoden ausdenken (die es aber 99 % der Fälle nicht gibt) und die dann direkt vorschlagen. Das führt zu Verwirrung, wenn man sowieso schon an schwierigem Code arbeitet.

Warum ist Copilot jetzt also so „blöd“ und erfindet einfach nur Funktions-Namen?

Copilot kennt out-of-the-box nur die aktuelle oberste Ebene der Objekte, und damit auch nur die obersten Methoden der Objekte. (Siehe die Tabelle oben.)

Ausnahme von dieser Regel sind alle Funktionen, die so oft im Internet vorkommen, sodass diese Informationen teil der AI sind, also in dessen Brains vorliegen. Diese also sozusagen auswendig kennt.

Mein Lösungsansatz

Von den Hauptobjekten im Programm habe ich iterativ und mit per Reflection alle Public Methoden ausgeben lassen.

Das Programm durchläuft zuerst das Hauptobjekt und anschließend alle zugehörigen Sub-Objekte. Dabei werden alle verfügbaren öffentlichen Methoden strukturiert aufgelistet und den jeweiligen Sub-Objekten zugeordnet. Diese Zuordnung wird mit Textpfeilen visualisiert, da wir ein Sprachmodell (LLM) verwenden.

Je nach Größe dieses Objekts kann man Zusatzinformationen wie Eingabe und Ausgabe Typen mit in die Liste (Listen Baum) aufnehmen.

Am Ende kommt eine Textdatei dabei herauskommen, die einen strukturierten Methodenbaum zeigt, der sich anhand des Objekts und dessen Unterobjekte aufbaut.

Das ganze setzt natürlich voraus, dass eine Objekt-Orientierte-Sprache verwendet wird.

Eine Sprache wie Java mit ihrer JVM ist quasi dafür gemacht, aber, um einen Überblick zu geben, hier wieder etwas AI generiertes:

Wie gut lässt sich das, was ich beschrieben, habe nun auf welche Sprache anwenden:

Python – Built-in inspect module, dynamic typing, easy object traversal – Excellent

Java – Comprehensive Reflection API, method signatures, type information – Excellent

C#/.NET – Powerful Type system, attributes, generics support – Excellent

JavaScript – Dynamic object inspection, prototype chain traversal – Very Good

…

C++ – RTTI very basic, requires external libraries – Limited

C – No built-in reflection capabilities – Not Supported

Meine Lösung / This Does The Trick

Ich habe das ganze mit Java und mit Python sowie JS praktisch umgesetzt, mit Java habe ich die meisten Erfahrungen gemacht.

Das ganze funktioniert, ziemlich gut, solang die Datei offen ist, schlägt Copilot nach einiger Zeit wirklich fast nur noch Methoden und Unterobjekte vor, die auch Sinn machen.

Hier ist ein Beispiel wie so eine Kontextdatei aussieht, wenn diese generiert wurde:

–> Als Text

–> Als Json

Diese Dateien enthalten noch einen gewissen Overhead, die eine AI aus meiner sich nicht braucht, dieser Overhead (mehr an Zeichen und Text) erleichtert es aber dem Leser dieses Artikels das ganze schnell zu erfassen.

Dadurch ist Copilot auch in der Lade komplexere Dinge vorzuschlagen, die vorher durch den fehlenden Kontext der AI schlicht und einfach nicht bekannt waren.

–> Hier ist meine Umsetzung in Python.

Weitere Gedanken

Die Frage, die ich mir stelle, bei der ganzen Angelegenheit ist, ob eine mehr auf AI ausgelegte Lösung wie die Currser IDE solche Mechanismen bereits im Hintergrund nutzt, und wann ein solcher Ansatz in Copilot eingebaut wird. Immerhin kann man so durch Extraktion komprimiert und somit speicher schonenden relevante Informationen dem Kontext bereitstellen.

Vielleicht gibt es ja irgendwann in naher Zukunft Rechner zu kaufen, mit AI Beschleunigern (wir wollen ja nur ausführen und nicht die AI trainieren), die über 128 RAM und mehr verfügen, die es dann letztendlich möglich machen sich von den sehr begrenzten Individual-Ressourcen (viel speicher für das Model, wenig speicher für den jeweiligen Kontext) der Rechenzentren freizumachen. Oder bis dahin scannen diese Dienste vom Rechenzentrum aus einfach alles auf dem Entwicklerrechner.

Es wird sich zeigen, oder auch nicht.

Auf jeden Fall kann man bis dahin tricksen per Reflecion.

Chat GPTs kommentar zu dem Artikel

Interessante Informationen zum Thema arbeiten mit AI

(echt Hand-Verlesen)

Salesforces-New-Developers-YoutubeVideo

Prompt-Engineering-Best-Practices-For-Chatgpt

Copilot-Comparring-Diffrent-AI-Models-For-Diffrent-Tasks

AI-VS-MachineLerning???

How-To-Promt-„Historic“-Information-From-2023-(Gives-You-A-Nice-Context)

Git things nice to know about

UPDATE 31.05.2026

I would say parts of the article are still useful, but its core assumption is becoming outdated for modern coding agents.

The author is describing a real limitation that many AI coding tools had (and some still have):

„The AI only sees the currently open file(s) and therefore invents methods.“

That was often true for early autocomplete-focused systems.

However, there is an important distinction between:

Token prediction models (classic Copilot-style completion)
Agentic IDE integrations (modern coding assistants)

Where the article is still right

If a model only receives:

Customer customer = service.getCustomer();
customer.

and no additional type information, it may invent:

customer.getFullAddress()
customer.save()
customer.update()

because statistically those names look plausible.

The author’s reflection-generated context file helps because it explicitly tells the model:

Customer
 ├─ getName()
 ├─ getAddress()
 ├─ getOrders()

Now the model no longer has to guess.

That idea is sound.

Where the article is no longer fully accurate

The statement:

„Copilot only knows the top level of the objects“

is not generally true anymore for the most advanced IDE assistants.

Modern systems often have access to:

Symbol indexes
Language server data
Go-to-definition results
Project-wide search
Dependency metadata
ASTs (Abstract Syntax Trees)
Type information

For example, if an agent can ask:

What is the type of customer?

and receives:

com.company.Customer

then it can ask:

List members of Customer.

and obtain the actual methods.

No reflection dump file is needed.

What the author’s trick is actually doing

The reflection file is functioning as a manual knowledge index.

It converts:

Customer

into:

Customer
 ├─ getName()
 ├─ getAddress()
 ├─ getOrders()

and places that into the prompt context.

This is basically a simplified form of what modern AI coding systems do automatically:

Scan code
Build indexes
Extract symbols
Retrieve relevant information
Feed it into the model

In AI terminology this is a kind of RAG (Retrieval-Augmented Generation) system.

The really interesting question

The article asks:

Does Cursor already do this?

The answer is essentially yes, although not necessarily via runtime reflection.

Tools such as:

typically build a project representation and retrieve relevant code on demand.

Instead of:

LLM memory only

they use something closer to:

Codebase
   ↓
Index
   ↓
Retriever
   ↓
LLM

which is much more powerful.

My assessment of the article would be:

Reflection-based context generation: still a clever idea.
For plain LLM prompting: still useful.
For state-of-the-art IDE agents in 2026: largely superseded by automatic code indexing, language-server integration, and retrieval systems.

In other words, the author’s workaround solves a real problem, but modern coding agents increasingly solve that same problem automatically rather than requiring a generated reflection file.