Agentic AI
Mai 7, 2026
Felix Braun 
Mein erster Versuch, einen KI-Agenten in meinen Editor zu integrieren, endete mit einer gelöschten Konfigurationsdatei, drei offenen Terminal-Fenstern und dem leisen Verdacht, dass die KI eigentlich nur mein Chaos effizienter verwaltet. Aber genau da fängt die interessante Geschichte an – denn Obsidian, VS Code und Zed entwickeln sich 2026 zu echten Kommandozentralen für entwicklerorientierte KI-Workflows. Und das ist weder Marketing noch Science-Fiction.
Nerd-Alarm: Wer noch glaubt, KI im Editor bedeute lediglich Tab-Completion und hübsche Syntaxvorschläge, hat die letzten zwölf Monate verschlafen. KI-Agenten übernehmen 2026 echte Aufgaben: Dateien lesen, Terminals bedienen, Tests ausführen, Commits vorbereiten. Der Editor ist dabei nicht mehr nur Textfeld – er wird zur Schnittstelle zwischen Mensch, Modell und Maschine.
Die Frage ist nicht mehr, ob KI-Agenten in den täglichen Entwickler-Workflow einziehen, sondern welche Editoren das am cleversten umsetzen. Und hier teilen sich die Wege: VS Code bleibt der Platzhirsch mit riesigem Extension-Ökosystem, Zed baut AI nativ in den Kern, und Obsidian – ja, eigentlich ein Notiz-Tool – entwickelt sich zum stillen Star für wissensintensive Entwickler-Workflows.
Im Ernst: Das ist keine Marketing-Erzählung, das ist tatsächlich das, was gerade passiert. Drei sehr unterschiedliche Werkzeuge, drei sehr unterschiedliche Philosophien – aber alle zeigen dieselbe Richtung. Und diese Richtung lässt sich auf einen gemeinsamen Nenner bringen: Der Editor hört auf, ein passives Textverarbeitungsprogramm zu sein, und wird zu einem aktiv handelnden Teilnehmer im Entwicklungsprozess. Das klingt nach einer Kleinigkeit, ist aber in der täglichen Praxis ein fundamentaler Unterschied – vergleichbar mit dem Sprung vom einfachen Kalkulationsblatt zur relationalen Datenbank. Gleiches Ziel, völlig andere Mächtigkeit.
Konkret bedeutet das: Ein Agent, der heute in VS Code, Zed oder Obsidian läuft, kann eine Fehlermeldung lesen, im Codebase nach dem betroffenen Modul suchen, einen Fix vorschlagen, einen Test schreiben, den Test ausführen und das Ergebnis zurückmelden – alles innerhalb weniger Sekunden, alles ohne manuelles Hin- und Herkopieren zwischen Fenstern. Das ist kein Demo-Szenario, das passiert gerade in echten Produktionsumgebungen. Wer das noch nicht erlebt hat, wird beim ersten Mal unweigerlich innehalten und neu kalibrieren, was Entwicklerproduktivität bedeutet.
Obsidian war lange das Lieblingswerkzeug von Zettelkasten-Fans und produktivitätsbesessenen Studierenden. Was dabei oft übersehen wird: Die App speichert alles als lokale Markdown-Dateien in einem sogenannten Vault-Ordner. Kein Cloud-Sync, keine Serververbindung, keine versteckten API-Calls. Und genau das macht Obsidian 2026 zu einem ernstzunehmenden Werkzeug für KI-Agenten.
KI-Agenten wie Claude Code oder Codex CLI können direkt auf diesen Vault-Ordner zugreifen – lesend und schreibend. Sie durchsuchen Notizen, extrahieren Kontext, fügen strukturierte Zusammenfassungen ein, alles vollständig offline. Wer das .claude/skills/-Verzeichnis innerhalb des Vaults korrekt konfiguriert, bekommt vault-kompatible Ausgaben, die direkt in die bestehende Notizstruktur passen. Kein API-Schlüssel notwendig, kein Cloud-Dienst zwischengeschaltet.
Spoiler: Für datenschutzsensible Projekte – Stichwort DSGVO – ist das ein echter Vorteil. Unternehmensinternes Wissen, Kundenanforderungen, interne Architekturdokumente: All das bleibt lokal, während KI-Agenten trotzdem kontextreich darauf zugreifen können. Das ist kein Trick, das ist Systemdesign. Lokale Modelle über Ollama, zum Beispiel mit dem deepseek-coder, lassen sich ebenfalls direkt an den Vault koppeln – dann läuft die gesamte Kette ohne externe Verbindung.
Wichtig zu verstehen: Obsidian selbst hat keine eingebaute KI. Es ist kein proprietäres AI-Produkt, sondern ein offenes Ökosystem, das durch seine Dateistruktur und Plugin-Architektur zum idealen Andockpunkt für externe Agenten wird. Wer das als Bastelprojekt betrachtet, liegt zunächst gar nicht falsch – aber es ist ein Bastelprojekt mit ernsthafter Produktionsreife.
Ein konkretes Beispiel aus der Praxis: Ein kleines Entwicklungsteam dokumentiert seine Architekturentscheidungen, Meeting-Protokolle und API-Spezifikationen vollständig in einem gemeinsamen Obsidian-Vault, der per Git versioniert wird. Ein Claude-Code-Agent, der auf diesen Vault Zugriff hat, kann beim Schreiben neuer Features sofort den relevanten Architekturkontext abrufen, ohne dass jemand manuell suchen muss. Die KI „kennt“ das Projekt – weil sie tatsächlich in den Notizen nachschlägt, nicht weil sie halluziniert. Das ist ein fundamentaler Unterschied zu einem generischen Chat-Assistenten ohne Kontext.
Gleichzeitig gibt es ein Gegenargument, das nicht verschwiegen werden sollte: Obsidian ist primär für Einzelpersonen oder kleine Teams ausgelegt. Wer kollaborative Echtzeit-Bearbeitung braucht, wie sie etwa Notion oder Confluence bieten, stößt hier an Grenzen. Die Git-basierte Zusammenarbeit funktioniert, erfordert aber technisches Grundverständnis im Team. Für Enterprise-Umgebungen mit hundert Entwicklerinnen und Entwicklern ist Obsidian als zentrale Wissensbasis daher nur bedingt geeignet – als persönliches Werkzeug oder Team-Tool für kleine Gruppen hingegen kaum zu schlagen.
VS Code ist der meistgenutzte Editor weltweit, und das aus gutem Grund: Das Extension-Ökosystem ist riesig, die Community enorm, die Integration mit Git, Terminals und Debuggern ausgereift. Aber bei KI-Agenten zeigt sich eine strukturelle Schwäche: Alles läuft über Extensions.
Wer KI-Features in VS Code nutzen möchte, braucht in der Regel Erweiterungen wie GitHub Copilot – und damit externe Abhängigkeiten, Authentifizierungsebenen und Subscription-Modelle. Das ist kein unlösbares Problem, aber es schafft Reibung. Agenten-Workflows, die tief in Terminal, Dateisystem und Editor-Kontext eingreifen, müssen sich durch diese Extension-Schicht hangeln.
Im Ernst: VS Code bleibt für viele Teams die sichere Wahl, und das zu Recht. Aber wer konsequent mit KI-Agenten arbeiten will, stößt früher oder später an Grenzen, die durch das Extension-Modell entstehen. Die Kontrolle darüber, was ein Agent darf und sieht, ist weniger granular als in nativ integrierten Lösungen. Für Teams, die bereits tief in VS Code-Workflows investiert sind, ist der Umstieg trotzdem keine zwingende Entscheidung – es ist eine Abwägung.
Und hier wird es strategisch interessant: Zed hat eine eigene Migrations-Dokumentation veröffentlicht, die VS Code-Nutzende Schritt für Schritt durch das Wechseln führt – inklusive Keyboard-Shortcuts, Einstellungen und, natürlich, AI-Features. Das ist kein Zufall.
Was bei der Diskussion über VS Code häufig untergeht: Microsoft investiert massiv in die Weiterentwicklung der KI-Integration. GitHub Copilot hat sich vom simplen Autocomplete-Werkzeug zu einem ernsthaften Agenten-Framework entwickelt. Mit dem sogenannten „Copilot Workspace“-Ansatz können Entwicklerinnen und Entwickler Issues beschreiben, und der Agent plant und implementiert Lösungsschritte – mit menschlicher Überprüfung an definierten Checkpoints. Das ist keine Extension im klassischen Sinne mehr, das ist eine tiefere Systemintegration, die das Extension-Argument zumindest teilweise entkräftet.
Das Risiko bleibt trotzdem real: Wer als Einzelentwickler oder kleines Team auf eine Microsoft-Subscription angewiesen ist, gibt Kontrolle und Flexibilität ab. Bei einem Preisanstieg oder einer Änderung der Nutzungsbedingungen ist der Ausweichpfad mit erheblichem Umstellungsaufwand verbunden. Das ist kein hypothetisches Szenario – das kennt jeder, der schon einmal einen Tooling-Wechsel in einem laufenden Projekt durchgeführt hat. Vendor-Lock-in ist real, auch bei Open-Source-Editoren mit proprietären KI-Schichten.
Zed ist der Herausforderer. Entwickelt von einem Team, das teils von Atom und Tree-sitter kommt, baut Zed konsequent auf native Performance und native KI-Integration. Kein Extension-Umweg, kein Plugin-Layer – das AI-Assistent-Panel, Inline-Edits, Slash-Commands und eine Prompt-Bibliothek sind direkt im Editor verankert.
Die Edit-Prediction-Funktion von Zed unterstützt mehrere Modelle: das hauseigene Zeta-Modell, aber auch Codestral, GitHub Copilot oder lokale Modelle wie deepseek-coder-6.7b, das sich über eine lokale API-URL (http://localhost:8080/v1/completions) einbinden lässt. Output-Tokens sind auf 64 begrenzt, was für präzise Code-Vervollständigungen reicht und gleichzeitig die Latenz niedrig hält. Zed bewirbt das als „AI at native speed“ – und das ist mehr als ein Slogan, es ist eine architektonische Entscheidung.
Das Zed-Team publiziert eigene Erfahrungsberichte über das tägliche Arbeiten mit KI-Agenten. Im offiziellen Blog beschreiben Entwicklerinnen und Entwickler, wie Agenten das „Typing“ übernehmen, während sich Menschen auf Design, Architektur und Qualitätskontrolle konzentrieren können. Drei Prinzipien tauchen dabei immer wieder auf: Kontrolle behalten, die LLM-Natur des Werkzeugs verstehen, und Invarianten – also unveränderliche Systemannahmen – schützen. Das klingt abstrakt, ist aber in der Praxis entscheidend.
Was bedeutet „Invarianten schützen“ konkret? Ein Beispiel: Ein Team hat die Konvention, dass alle öffentlichen API-Endpunkte durch einen bestimmten Middleware-Layer laufen müssen. Das ist eine Invariante – eine Regel, die nie gebrochen werden darf, egal welchen Code der Agent generiert. Wer diese Invariante nicht explizit im System-Prompt oder in der Agent-Konfiguration verankert, riskiert, dass der Agent funktionstüchtigen Code produziert, der die Architektur untergräbt. Zed’s Ansatz, Agenten-Workflows direkt im Editor zu verankern, macht es einfacher, solche Constraints sichtbar und durchsetzbar zu machen.
Spoiler: Auch Zed ist kein Allheilmittel. Für hosted Modelle braucht man eine Pro-Subscription; wer eigene API-Keys mitbringt („bring your own keys“), zahlt nichts, hat aber Rate-Limits. Die Community diskutiert aktiv erweiterte Agenten-Funktionen – Feature-Requests wie erweitertes Agenten-Editing tauchen regelmäßig in den GitHub-Discussions auf. Zed ist schnell, aber noch nicht fertig.
Ein weiteres Gegenargument, das ernstzunehmen ist: Zed hat im Vergleich zu VS Code ein deutlich kleineres Extension-Ökosystem. Wer auf bestimmte Sprach-Plugins, Framework-Integrationen oder spezialisierte Debugging-Werkzeuge angewiesen ist, wird möglicherweise feststellen, dass die gewünschte Erweiterung in Zed schlicht nicht existiert. Das ist kein dauerhafter Zustand – das Ökosystem wächst schnell –, aber es ist ein realer Einschränkungsfaktor für Teams mit spezialisierten Anforderungen. Wer produktiv in Zed arbeiten möchte, sollte vorab prüfen, ob die benötigten Integrationen verfügbar sind, bevor er den Workflow umstellt.
Hier wird es heikel, und ich sage das als jemand, der schon eine Konfigurationsdatei an einen schlecht konfigurierten Agenten verloren hat. KI-Agenten, die wirklich nützlich sind, brauchen Zugriff: auf das Dateisystem, auf das Terminal, auf Build-Prozesse. Das ist der Kern ihrer Stärke – und gleichzeitig die größte Gefahrenquelle.
Ein Agent, der unkontrolliert Terminal-Befehle ausführen darf, kann Dateien überschreiben, Pakete installieren, Branches mergen oder im schlimmsten Fall sensible Konfigurationen an eine externe API schicken. Das ist kein theoretisches Risiko. Es ist ein praktisches Problem, das jeden trifft, der Agenten mit weitreichenden Berechtigungen ausstattet, ohne klare Grenzen zu definieren.
Die Antwort liegt in der Konfiguration. Obsidian-basierte Workflows lassen sich vollständig offline betreiben – kein Agent schickt Daten nach außen, wenn es kein Netz gibt. Zed bietet granulare Kontrolle über Agent-Aktionen im Editor-Kontext. VS Code-Extensions haben unterschiedliche Berechtigungsmodelle, je nach Konfiguration. In jedem Fall gilt: Wer KI-Agenten im Editor einsetzt, muss vorher entscheiden, welche Rechte das Modell bekommt – und dokumentieren, was es darf.
Nerd-Alarm: Ein Sandbox-Ansatz – Agent läuft in einem isolierten Verzeichnis, Terminal-Zugriff nur auf explizit freigegebene Befehle – ist keine Paranoia, sondern gutes Engineering. Wer das überspringt, lebt gefährlich.
Ein konkretes Risikoszenario, das in Entwicklerforen zunehmend diskutiert wird: sogenannte Prompt-Injection-Angriffe. Dabei wird schadhafter Text in Dateien eingeschleust – etwa in einen Kommentar in einer Codedatei oder in eine Dependency-Beschreibung –, den der Agent liest und als Instruktion interpretiert. Das Ergebnis kann eine unerwünschte Aktion sein, die der Entwickler nie autorisiert hat. Dieses Angriffsszenario ist besonders heimtückisch, weil es schwer zu erkennen ist. Wer Agenten mit breiten Lesezugriffen auf fremde oder externe Repositories ausstattet, sollte dieses Risiko aktiv einkalkulieren und Gegenmaßnahmen planen, zum Beispiel durch strenge Whitelists für erlaubte Aktionen.
Darüber hinaus gilt ein Grundprinzip, das unabhängig vom gewählten Editor gilt: Versionskontrolle ist der Sicherheitsgurt des KI-Agenten-Workflows. Wer alle Änderungen in Git trackt, kann jeden Agenten-Eingriff rückgängig machen. Wer ohne Commit-Disziplin arbeitet und dem Agenten Schreibzugriff gibt, verliert im Fehlerfall unter Umständen Arbeit, die sich nicht wiederherstellen lässt. Das klingt selbstverständlich – und ist es trotzdem nicht für jeden, der zum ersten Mal mit agentischen Werkzeugen arbeitet.
Ein Trend, der 2026 deutlich an Fahrt gewinnt: lokale Modelle direkt im Editor. Sowohl Zed als auch Obsidian-basierte Workflows unterstützen die Integration über Ollama oder kompatible lokale APIs. Das bedeutet: Kein Cloud-Request, keine Latenz durch externe Server, keine Nutzungsdaten, die irgendwo in einem Rechenzentrum landen.
Für den Alltag heißt das konkret: Ein Entwickler konfiguriert Zed so, dass Edit-Predictions vom lokalen deepseek-coder-Modell kommen. Obsidian-Agenten greifen auf denselben lokalen Endpunkt zu. Die KI-Kette läuft vollständig auf dem eigenen Rechner. Das erfordert Hardware – ein leistungsfähiger Laptop oder ein Mini-PC mit genug RAM –, aber die Kontrolle, die man dafür bekommt, ist es wert.
Meine persönliche Einschätzung: Lokale Modelle sind noch nicht bei der Qualität von GPT-4-Klasse-APIs, aber für kontextspezifische Entwickleraufgaben – Code-Vervollständigung, Refactoring-Vorschläge, Dokumentationsstrukturierung – reichen sie in vielen Fällen aus. Und der Datenschutz-Gewinn ist erheblich, gerade für Teams, die mit proprietärem Code oder Kundendaten arbeiten.
Der Schlüssel ist die richtige Aufgabentrennung: Lokale Modelle für sensible, repetitive Aufgaben; Cloud-Modelle für komplexe Architekturentscheidungen, bei denen die Qualität den Datenschutz-Trade-off rechtfertigt. Das ist kein Entweder-oder, sondern ein Hybrid-Workflow.
Die Hardware-Frage ist dabei weniger ein Hindernis als oft angenommen. Ein modernes MacBook Pro mit M3-Chip oder ein Mini-PC mit 32 GB RAM kann Modelle wie deepseek-coder-6.7b oder Codellama-13b flüssig betreiben. Die Inferenzgeschwindigkeit ist für interaktive Anwendungsfälle wie Inline-Vorschläge oder kurze Agenten-Antworten mehr als ausreichend. Wer größere Kontextfenster oder komplexere Reasoning-Aufgaben braucht, stößt bei lokalen Modellen schneller an Grenzen – aber für die Masse der täglichen Entwickleraufgaben ist die lokale Option längst praxistauglich.
Eine oft übersehene praktische Konsequenz: Lokale Modelle funktionieren auch ohne Internetverbindung. Für Entwicklerinnen und Entwickler, die regelmäßig im Zug, auf Reisen oder in Umgebungen mit schlechter Konnektivität arbeiten, ist das kein Luxus, sondern ein echter Produktivitätsvorteil. Der Workflow bricht nicht zusammen, wenn das WLAN ausfällt – er läuft einfach weiter.
Wer jetzt anfangen möchte, bekommt hier drei konkrete Einstiegspunkte – ohne die Details zu verschweigen, die in Tutorials gerne fehlen.
Weg 1 – Obsidian + Claude Code offline: Vault-Ordner anlegen, Claude Code installieren, .claude/skills/-Verzeichnis im Vault erstellen. Agent greift direkt auf Markdown-Dateien zu, schreibt strukturierte Ausgaben zurück. Ideal für Wissensmanagement und Dokumentations-Workflows. Keine Cloud notwendig, DSGVO-konform by design. Der Einstiegsleitfaden von NeverCodeAlone erklärt die Vault-Konfiguration für KI-Agenten detailliert. Mehr Kontext liefert Claude Code: Der vollständige Guide für AI-Poweruser.
Weg 2 – Zed mit eigenem API-Key: Zed installieren, im Settings-Panel den eigenen Anthropic- oder OpenAI-Key eintragen („bring your own keys“), Edit Prediction aktivieren. Sofortige AI-Integration ohne Extension-Schicht, volle Kontrolle über Modellwahl. Pro-Subscription nötig, wenn man hosted Zed-Modelle nutzen möchte; mit eigenem Key ist es kostenlos, aber rate-limitiert.
Weg 3 – VS Code mit lokalem Modell: Ollama installieren, gewünschtes Modell laden (z. B. deepseek-coder-6.7b), kompatible VS Code-Extension konfigurieren, lokalen Endpunkt verbinden. Mehr Einrichtungsaufwand als bei Zed, aber das Extension-Ökosystem bleibt verfügbar. Für Teams, die nicht wechseln wollen, aber trotzdem lokale KI-Kontrolle möchten.
Alle drei Wege haben gemeinsam: Sie beginnen mit der Entscheidung, welche Daten der Agent sehen darf. Wer das zuerst klärt, spart sich später Probleme.
Was in den meisten Schritt-für-Schritt-Anleitungen fehlt, ist der Hinweis auf die Einarbeitungszeit. Keiner der drei Wege ist mit einer Stunde Setup erledigt und dann sofort produktiv. Die eigentliche Lernkurve liegt nicht in der technischen Einrichtung, sondern im Verständnis dafür, wie man einem Agenten gute Instruktionen gibt. Ein schlecht formulierter Prompt produziert schlechten Code – egal wie leistungsfähig das Modell ist. Die Investition in das Schreiben klarer, kontextreicher System-Prompts und Agent-Konfigurationen zahlt sich langfristig deutlich mehr aus als die Wahl des vermeintlich besten Modells. Das ist eine Kompetenz, die trainiert werden muss, und sie ist unabhängig vom Editor.
Darüber hinaus empfiehlt es sich, den gewählten Workflow zunächst an einem nicht-kritischen Nebenprojekt zu erproben, bevor man ihn auf ein laufendes Produktionsprojekt anwendet. Die überraschenden Momente – der Agent, der eine Datei umbenennt, die man nicht umbenennen wollte; der Commit, der mehr Dateien enthält als erwartet – sollten in einer Umgebung passieren, wo der Schaden begrenzt ist. Das ist kein Misstrauen gegenüber der Technologie, das ist pragmatisches Lernen.
KI-Agenten im Editor sind kein futuristisches Konzept mehr. Obsidian, VS Code und Zed zeigen drei unterschiedliche Wege, wie sich dieser Wandel konkret anfühlt: als offenes Ökosystem, als Extension-getriebene Plattform, als nativ integriertes Werkzeug. Keiner davon ist per se der richtige – es kommt auf den Workflow, das Team und die Datenschutzanforderungen an.
Die eigentlich entscheidende Frage bleibt aber unbeantwortet: Wie viel Kontrolle sind Entwicklerinnen und Entwickler bereit abzugeben, damit KI-Agenten wirklich produktiv werden? Wer die Terminal-Berechtigungen sorgfältig konfiguriert, offline-first denkt und lokale Modelle nicht als Kompromiss, sondern als bewusste Entscheidung versteht, hat gute Chancen, aus diesem Bastelprojekt ein ernsthaftes Produktionswerkzeug zu machen.
Was sich abzeichnet: Die Grenzen zwischen den drei vorgestellten Werkzeugen werden mittelfristig durchlässiger. Obsidian-Vaults werden als Wissenskontext in Code-Editoren eingebunden. Zed-Workflows werden mit externen Dokumentationsquellen verknüpft. VS Code-Agenten lernen, lokale Modell-Endpunkte flexibler zu nutzen. Die Werkzeuge konvergieren nicht zu einem einzigen Produkt – aber sie lernen voneinander. Das ist eine gesunde Entwicklung, die dem Nutzer letztlich mehr Wahlfreiheit gibt.
Ein letzter Gedanke, der über die rein technische Einordnung hinausgeht: KI-Agenten im Editor verändern nicht nur, wie Code geschrieben wird – sie verändern auch, welche Kompetenzen in einem Entwicklungsteam am wertvollsten sind. Die Fähigkeit, einem Agenten die richtigen Fragen zu stellen, seine Ausgaben kritisch zu bewerten und die Architektur so zu gestalten, dass sie agenten-gerecht ist, wird wichtiger als das schnelle Tippen von Boilerplate-Code. Das ist keine Bedrohung für Entwicklerinnen und Entwickler, das ist eine Einladung, sich auf die Aspekte der Arbeit zu konzentrieren, die tatsächlich menschliches Urteilsvermögen erfordern.
Probieren Sie einen der drei Wege aus – und berichten Sie, welcher Aspekt Sie am meisten überrascht hat. Die Community-Diskussionen auf GitHub und in Entwicklerforen zeigen: Die besten Lösungen entstehen gerade erst.
