Technik · 27.10.2026

Der Eclipse-Agent: Ein LLM-Agent, der wirklich in eurer IDE arbeitet

Die meisten KI-Helfer fürs Programmieren sitzen neben der Arbeit: im Browser, im Terminal, in der Cloud. Wir haben das Gegenteil gebaut — einen Agenten, der direkt im Eclipse-Prozess lebt, den richtigen Workspace sieht, Programme baut, Tests ausführt und sogar die Oberfläche bedienen kann. Ohne Shell, ohne Pixel-Roboter, mit einem Schreibschutz, der standardmäßig an ist. Und weil er gegen jeden OpenAI-kompatiblen Endpunkt spricht, kann er komplett auf eurer eigenen Hardware laufen.

Ein KI-Assistent, der Code schreibt, ist heute keine Sensation mehr. Der Unterschied liegt darin, wie er an die Arbeit kommt. Die verbreiteten Coding-Agenten arbeiten außerhalb der Entwicklungsumgebung: Sie bekommen Ausschnitte, Pfade und Zusammenfassungen gereicht, müssen sich den Kontext selbst zusammensuchen und schicken ihre Antworten wieder zurück. Dazu fließen die Daten meist an einen fremden Dienst. Wer im Mittelstand oder im Gesundheitswesen mit sensiblem Quellcode arbeitet, steht damit vor zwei Problemen: Der Assistent sieht nie den ganzen Zusammenhang, und der Code verlässt das Haus.

Die Idee: Der Agent wohnt im selben Prozess

Unser Ansatz ist radikal anders. Das Plugin bettet den Agenten direkt in den Eclipse-Prozess ein. Damit arbeitet er nicht mit einer Kopie oder einer Projektion der Welt, sondern mit der Welt selbst: dem echten Workspace mit seinen Projekten, Dateien und Build-Konfigurationen. Statt über eine Shell oder Bildschirm-Pixel zu wirken — beides fehleranfällig und schwer kontrollierbar —, läuft jede Aktion über eine schmale, ausdrücklich erlaubte Werkzeug-Schicht auf der Eclipse-API. Kein Terminal, kein Dateisystem-Rundumschlag: Der Agent kann nur das, was die Werkzeuge hergeben, und das lässt sich überprüfen.

Was der Agent kann

Die Werkzeuge teilen sich in zwei Gruppen. Die Workspace-Werkzeuge arbeiten mit dem Projekt: workspace_list zeigt Projekte und Dateien, file_read liest mit Zeilennummern, file_apply_patch ändert Dateien diff-basiert oder legt neue an, build_workspace stößt einen echten JDT-Build an und zählt Fehler und Warnungen, run_junit führt die JUnit-Tests aus. Das ist kein Ratespiel: Der Agent sieht die tatsächlichen Build-Ergebnisse und die echten Testverdicts — rot ist rot, grün ist grün.

Die IDE-Werkzeuge bedienen die Oberfläche, logisch und deterministisch statt per Maus-Simulation: Befehle ausführen (mit Katalog und Menü-Label-Auflösung, damit der Agent nie Command-IDs raten muss), Views und Perspektiven öffnen, Einstellungen lesen und setzen, den Editor öffnen und seinen Zustand abfragen, Dialoge schließen. Kein Bildschirm-Pixel wird angefasst. Auf diese Weise kann der Agent zum Beispiel das Theme der IDE wechseln, eine Preference-Seite öffnen oder einen störenden Dialog wegklicken — alles über die sauberen Schnittstellen der Workbench.

Der Schreibschutz: Diff statt Aktion

Das wichtigste Sicherheitsmerkmal ist ein Tor in zwei Richtungen: Solange das Schreib-Gate zu ist, darf der Agent schreiben gar nichts. file_apply_patch liefert dann nur die Diff-Vorschau — man sieht exakt, was passieren würde, aber auf der Platte ändert sich nichts. Erst wer das Gate in den Einstellungen ausdrücklich öffnet, gibt dem Agenten die Schreibrechte. Im Fernsteuerungs-Betrieb kommt ein Token dazu, den jede Anfrage mitbringen muss. Dazu kommen Schutzmechanismen im Werkzeug selbst: Ein nicht eindeutiger Suchtext lehnt einen Patch ab, eine neue Datei wird nur angelegt, wenn sie wirklich nicht existiert.

Drei Betriebsarten, eine Werkzeug-Registry

Der gleiche Werkzeugkasten ist auf drei Wegen erreichbar. Im normalen Gebrauch läuft der Agent als Chat-Ansicht in der IDE: Aufgabe tippen (Strg+Shift+Alt+A), Enter, und der Agent arbeitet in einem Hintergrund-Job — Live-Tool-Fortschritt und gestreamte Antworten erscheinen im Verlauf, jede Unterhaltung bleibt als Kontext erhalten. Zweitens gibt es eine Headless-Bridge: eine kleine HTTP-Schnittstelle, über die sich derselbe Agent aus Skripten oder anderen Werkzeugen fernsteuern lässt, ohne dass überhaupt eine Oberfläche läuft. Drittens kann genau diese Brücke auch in der laufenden Oberfläche aktiviert werden, damit die UI-Werkzeuge ebenfalls fernsteuerbar sind. Pro Lauf entsteht außerdem ein Transkript als Textdatei — jede Aktion ist nachvollziehbar und protokollierbar.

Offen in beide Richtungen

Das Plugin bringt keinen eigenen Modell-Server mit. Es spricht jeden OpenAI-kompatiblen Endpunkt an: die eigene vLLM-Rig, eine Ollama-Installation, einen öffentlichen Anbieter. Bei uns läuft der Agent standardmäßig gegen eine hauseigene Inferenz-Rig mit einem frei lizenzierbaren Modell — die gesamte Kette, vom Prompt bis zur fertigen Datei-Änderung, verlässt die eigenen Server nicht. Wer mag, schließt stattdessen einen Cloud-Anbieter an, aber der Punkt ist: Es gibt keinen Zwang. Genau das passt zu dem, was wir unter Datensouveränität verstehen.

Warum wir es gebaut haben

Weil wir jeden Tag mit Eclipse arbeiten. Unsere Umgebung ist nicht der Browser und nicht das Terminal — es ist die IDE, in der der Code tatsächlich entsteht. Genau dort soll der Assistent arbeiten, und deshalb haben wir das Plugin nicht als Experiment gebaut, sondern als Werkzeug für den täglichen Einsatz: einen Agenten, der im selben Prozess sitzt wie die Arbeit selbst.

Der Einsatz in unserem Alltag hat gezeigt, dass der Ansatz weiter trägt, als wir anfangs gedacht haben. Ein Agent, der den echten Build und die echten Tests kennt, statt sie zu erraten, liefert nicht nur schnellere, sondern auch verlässlichere Ergebnisse. Die technischen Hürden auf dem Weg (etwa die berüchtigten Java-Split-Packages in Eclipse oder Deadlocks zwischen Fernsteuerung und Oberfläche) sind gelöst und dokumentiert — wer sich selbst eine IDE-basierte Automatisierung baut, spart mit diesen Erfahrungen Wochen. Und weil das Ganze vollständig lokal laufen kann, lassen sich mit demselben Muster auch streng geregelte Umgebungen automatisieren, in denen Code die Firma nicht verlassen darf.