Ich habe gerade mein Jahresabonnement bei JetBrains gekündigt.
Das wäre für mich vor einigen Jahren fast undenkbar gewesen. IntelliJ und der Rest der JetBrains-Suite waren genau die Art von Software, für die ich gern bezahlte: leistungsfähige, ausgereifte Entwicklerwerkzeuge voller Funktionen, die das Schreiben, Durchsuchen, Refaktorieren und Debuggen großer Codebasen erheblich erleichterten. Lange Zeit war die IDE für mich der Ort, an dem Softwareentwicklung stattfand.
Das Problem ist, dass ich kaum noch eine öffne.
Nicht, weil ich keine Software mehr entwickle. Wahrscheinlich entwickle ich sogar mehr als je zuvor. Der Unterschied ist, dass ich immer seltener über eine IDE mit der Codebasis interagiere. Ich arbeite mit Orgabot und anderen Agentenumgebungen, beschreibe mein Ziel und lasse Agenten das Repository untersuchen, den relevanten Code verfolgen, Dateien ändern, Tests ausführen, Fehler beheben, die Implementierung prüfen, Pull Requests öffnen, Konflikte lösen und weitermachen.
Meine wichtigste Programmierschnittstelle hat sich allmählich von einem Texteditor voller Quellcode zu einem Gespräch über Absichten verschoben. Natürliche Sprache ist zu meiner Programmiersprache geworden.
Die IDE war eine Schnittstelle zur Komplexität
Jahrzehntelang war die IDE das Cockpit der Softwareentwicklung. Als Codebasen größer und Sprachen anspruchsvoller wurden, reichten einfache Texteditoren nicht mehr aus. Entwickler brauchten Symbolnavigation, intelligente Autovervollständigung, statische Analyse, Refactoring-Werkzeuge, Debugging, Testausführung, Datenbankexplorer, Versionskontrollintegration, Abhängigkeitsverwaltung und Dutzende weiterer Hilfen.
Produkte wie IntelliJ wurden außergewöhnlich gut darin, dieses Problem zu lösen. Als ich den ganzen Tag selbst an einer Codebasis arbeitete, waren diese Funktionen jeden Cent wert. Aus einer übergeordneten Perspektive ist eine IDE aber vor allem ein Werkzeug, das einem Menschen hilft, eine große Sammlung von Quelldateien zu verstehen und zu bearbeiten.
Agentenbasierte Entwicklung verändert, wer diese Bearbeitung übernimmt.
Die Codebasis ist noch da. Der Compiler auch. Git, Tests, Linter, Typsysteme, Debugger, Paketmanager und Build-Systeme sind nicht verschwunden. Verändert hat sich, dass immer seltener ich diese Werkzeuge direkt bediene. Das macht der Agent.
Muss man den Code noch lesen?
Ich muss mir den Code selten ansehen. Diese Erkenntnis hat mich letztlich dazu gebracht, JetBrains zu kündigen. Ich öffne kaum noch eine IDE, um zu „coden“. Manchmal sehe ich mir eine Datei an, weil mich eine Implementierung interessiert. Gelegentlich mache ich eine winzige manuelle Änderung. Vielleicht schaue ich mir einen Diff an oder gehe etwas besonders Merkwürdigem nach.
Aber diese Situationen sind inzwischen Ausnahmen statt meines hauptsächlichen Arbeitsablaufs. Wenn ich nur etwas Text ansehen möchte, reicht ein einfacher Editor völlig aus. Für die wenigen Male, in denen ich eine Quelldatei von Hand öffne, brauche ich keine mehrere Gigabyte große IDE und kein Jahresabonnement.
Der überwiegende Teil der Funktionen, auf die ich mich früher in IntelliJ verlassen habe, ist weiterhin wichtig. Ich möchte nach wie vor intelligente Codenavigation, Refactoring, Tests, statische Analyse und Code-Reviews. Ich möchte nur zunehmend, dass der Agent das erledigt, statt jedes Werkzeug selbst zu bedienen.
Die Werkzeuge sind nicht verschwunden. Sie liegen jetzt unterhalb der Abstraktionsebene, auf der ich meine Zeit verbringe.
Der Vollständigkeit halber: Die hier beschriebene Schnittstelle ist dokumentiert. Claude Code ist um agentisches Programmieren im Terminal herum gebaut und nicht um ein Editorfenster.
Natürliche Sprache wird zur Programmierschnittstelle
Programmiersprachen haben schon immer in unterschiedlichem Maße versucht, Maschinen für Menschen verständlicher zu machen. Mit dem Abstand zu Maschinencode und Assembler wurden die Sprachen zunehmend semantischer. Wir bekamen Variablen mit aussagekräftigen Namen, Funktionen, die sich wie Handlungen lesen, objektorientierte Strukturen zur Modellierung realer Konzepte und deklarative Sprachen, in denen wir zunehmend das gewünschte Ergebnis statt jeder dafür nötigen Anweisung beschreiben konnten.
Aber es waren weiterhin Programmiersprachen.
Hätte mir vor 30 Jahren jemand gesagt, dass ich eines Tages einen großen Teil meines Arbeitstags damit verbringe, durch gewöhnliches gesprochenes oder geschriebenes Englisch zu programmieren, hätte ich das für Science-Fiction-Unsinn gehalten. Doch genau das mache ich heute im Wesentlichen.
Natürlich ersetzt Englisch nicht buchstäblich TypeScript, Python, Go, Java oder die Sprache, in der das System schließlich implementiert wird. Meine CPU führt keinen Absatz aus, den ich einem Agenten geschrieben habe. Aber aus Sicht des Menschen an der Spitze des technischen Aufbaus wird dieser Unterschied weniger wichtig.
Programmieren bedeutete schon immer, menschliche Absichten in etwas zu übersetzen, das eine Maschine ausführen kann. Dabei haben wir die menschliche Seite dieser Übersetzung immer wieder auf eine höhere Abstraktionsebene gehoben. Früher bearbeiteten Menschen Maschinenanweisungen direkt. Assembler gab ihnen Namen. Höhere Sprachen erlaubten uns, Algorithmen ohne Gedanken an Register zu beschreiben. Frameworks ermöglichten Anwendungen, ohne jedes Grundelement selbst zu implementieren. Infrastructure as Code ließ uns ganze Umgebungen beschreiben, statt Server manuell zu konfigurieren.
Agenten ergänzen eine weitere Ebene. Statt jedes Implementierungsdetail selbst auszudrücken, können wir zunehmend das gewünschte Ergebnis formulieren:
- Ergänze OAuth-Unterstützung für diesen Anbieter.
- Finde heraus, warum dieser API-Endpunkt gelegentlich veraltete Daten liefert, und behebe das.
- Refaktoriere diese Dienste so, dass sie dieselbe Autorisierungsschicht verwenden.
- Implementiere dieses GitHub-Epic und alle zugehörigen Unteraufgaben.
- Prüfe die daraus entstandenen Pull Requests auf Sicherheitsprobleme und merge sie, wenn sie bereit sind.
Das sind Programmieranweisungen. Das Ergebnis kann aus Tausenden Zeilen herkömmlichen Quellcodes bestehen, doch die meisten davon habe ich nicht selbst geschrieben. Ich habe das gewünschte System beschrieben, Rahmenbedingungen festgelegt, das Ergebnis bewertet und Maschinen meine Absicht in die benötigten Sprachen übersetzen lassen.
Vor dreißig Jahren klang die Vorstellung, gewöhnliches Englisch an die Spitze eines Softwareentwicklungsstacks zu setzen, nach Science-Fiction. Heute ist das mein normaler Arbeitsablauf. Natürliche Sprache ersetzt nicht die Programmiersprachen unterhalb des Systems; sie wird zu der Programmiersprache, die ich verwende.
Die wertvolle Fähigkeit war nie wirklich die Sprache
Erfahrung mit vielen Programmiersprachen ist nach wie vor enorm wertvoll. Zu wissen, wie verschiedene Sprachen Typen, Nebenläufigkeit, Speicher, Zustand, Schnittstellen, Fehler und Abstraktion modellieren, schafft ein viel besseres mentales Modell zur Bewertung dessen, was ein Agent produziert. Diese Erfahrung hilft, schlechte Architektur, unnötige Komplexität, fragile Schnittstellen und später problematische Implementierungsentscheidungen zu erkennen.
Aber ich halte Erfahrung im Bau komplexer Systeme für die wichtigere Fähigkeit. Sprachen sind letztlich Mittel zum Zweck.
Die schwierigen Teile der Softwareentwicklung waren nie bloß das Erinnern an Syntax oder die Auswahl eines Bibliotheksaufrufs. Schwierig sind das Ziehen von Grenzen, das Verständnis des Zusammenspiels von Komponenten, das Vorhersehen von Ausfällen, Zustandsverwaltung, die Vorbereitung auf Veränderungen, Abwägungen, das Debuggen emergenten Verhaltens und das Erkennen von Implementierungen, die vernünftig aussehen, aber an realer Komplexität scheitern werden.
Diese Fähigkeiten überleben den Übergang zur agentenbasierten Entwicklung und könnten sogar wichtiger werden. Wenn ein Agent auf Abruf kompetenten TypeScript-, Python-, Go-, Rust- oder Java-Code liefern kann, wird die Beherrschung einer bestimmten Syntax weniger selten. Wertvoller wird das Wissen darüber, was gebaut werden sollte, wie alles zusammenpasst, welche Bedingungen wichtig sind und ob das Ergebnis wirklich gut ist.
Deshalb glaube ich auch nicht, dass die Zukunft nur denjenigen gehört, die gut prompten können. Ein cleverer Prompt ersetzt kein technisches Urteilsvermögen. Wer seit Jahrzehnten Systeme baut, kann den Plan eines Agenten ansehen und erkennen, dass die Grenzen falsch liegen, das Datenmodell nicht skalieren wird, die Sicherheitsannahmen schwach sind oder die vorgeschlagene Architektur das völlig falsche Problem löst.
Der Agent kann zunehmend die Übersetzung von Absicht in Implementierung übernehmen. Der Mensch muss das System weiterhin verstehen.
Für mich liegt darin die eigentliche Verschiebung: Die Programmiersprache wandert im Stack nach unten, während Architektur, Urteilsvermögen, Orchestrierung und Systemdenken nach oben rücken.
Lösen Cursor und Windsurf das?
Cursor und Windsurf lösen das ebenfalls nicht. Die naheliegende Antwort lautet, dass traditionelle IDEs vielleicht an Bedeutung verlieren, KI-native IDEs wie Cursor und Windsurf aber die Zukunft sind. Ich glaube das nicht.
Cursor und Windsurf sind im Kern weiterhin IDEs. Sie gehen davon aus, dass im Zentrum der Softwareentwicklung ein Mensch sitzt, der Quelldateien betrachtet, durch ein Repository navigiert, Code auswählt, Diffs prüft und innerhalb eines Editors mit KI interagiert. Das fühlt sich bereits wie eine Zwischenstufe an.
Beide haben inzwischen Terminal-Agenten und Automatisierungsschnittstellen ergänzt, was tatsächlich in diese Richtung geht. Aber der Editor ist weiterhin das Produkt: Dort landen die Funktionen, dorthin geht die Aufmerksamkeit, und dafür bezahlt man.
Wenn ich mit Orgabot oder einer anderen Agentenumgebung arbeite, brauche ich einen KI-erweiterten Editor nicht mehr als einen herkömmlichen. Ich sitze nicht da und warte auf Autovervollständigung, markiere eine Funktion zum Umschreiben durch KI oder springe manuell zwischen Dateien, während ein Assistent mir über die Schulter schaut.
Ich gebe dem Agenten den Auftrag.
Der Agent kann Dateien öffnen, die Codebasis durchsuchen, Abhängigkeiten prüfen, Befehle ausführen, Testfehler lesen, zwanzig Dateien ändern, Unteragenten starten, die Änderungen prüfen und weiter iterieren, bis die Aufgabe abgeschlossen ist. An diesem Punkt wirkt es beinahe verkehrt herum, KI in eine IDE einzubauen.
Das Ziel ist nicht, Menschen beim Bearbeiten von Code dramatisch schneller zu machen. Das Ziel ist, dass Menschen dramatisch weniger Code bearbeiten müssen.
Dieser Unterschied ist wichtig. Cursor und Windsurf mögen bessere Cockpits für KI-unterstütztes Programmieren sein, aber meine Richtung erfordert zunehmend gar kein Cockpit. Die Hauptschnittstelle wird zur Mission, zum Issue, zur Spezifikation oder zum Gespräch. Quellcode bleibt entscheidend, wird aber zu einem Artefakt, das unter dieser Schnittstelle erzeugt und bearbeitet wird, statt der Ort zu sein, an dem ich meinen Tag verbringe.
Als ich JetBrains kündigte, ersetzte ich es deshalb nicht durch Cursor oder Windsurf. Ich ersetzte die IDE durch den Agenten.
Ich möchte nicht mehr der Programmierer sein
Orgabot hat mich noch einen Schritt weitergebracht. Wenn ich mit Orgabot eine Anwendung oder Organisation aufbaue, gehe ich nicht als Softwareentwickler mit besseren Coding-Werkzeugen an die Arbeit. Ich gehe aus der Perspektive des CEO daran.
Ein CEO öffnet keine Quelldatei, um eine Funktion zu reparieren. Er definiert das Ziel, verteilt Verantwortung, stellt sicher, dass die richtigen Menschen oder Agenten daran arbeiten, überprüft, ob das Ergebnis zum Ziel passt, und verändert die Organisation, wenn der Prozess versagt.
Auch die Orchestrierung selbst kann delegiert werden. Ein CEO kann einem CTO die Lieferung eines Produkts auftragen. Der CTO koordiniert darunter Entwicklung, Sicherheit, Infrastruktur, Design und Prüfung. Der CEO muss nicht wissen, in welcher Datei die Authentifizierungs-Middleware liegt.
So entwickle ich zunehmend Software. Ich könnte sagen:
- Baue dieses Produkt.
- Löse dieses Epic und alle zugehörigen Unteraufgaben.
- Untersuche, warum dieses System ausfällt, und behebe die Ursache.
- Lass die Sicherheitsabteilung die Implementierung vor der Veröffentlichung prüfen.
- Reduziere die Kosten dieses Arbeitsablaufs, ohne die Qualität zu verschlechtern.
Diese Anweisungen erzeugen Arbeit, die irgendwann zu Code führt. Aber der Code liegt mehrere Ebenen unter der Schnittstelle, auf der ich tätig bin.
Daraus ergibt sich eine nützliche Regel: Wenn der CEO Quellcode prüft oder bearbeitet, ist wahrscheinlich irgendwo unter ihm ein Arbeitsablauf defekt.
Vielleicht hat der Entwicklungsagent versagt. Vielleicht ist der Prüfprozess schwach. Vielleicht fehlen der Organisation die richtige Rolle oder Fähigkeit. Vielleicht sind die Eskalationsgrenzen falsch gesetzt. Was auch immer die Ursache ist: Die Antwort sollte nicht sein, den CEO dauerhaft in die Implementierungsebene zu ziehen. Sie sollte darin bestehen, das System so zu reparieren, dass die Organisation diese Arbeit beim nächsten Mal richtig erledigen kann.
Deshalb habe ich auch wenig Interesse daran, IntelliJ durch Cursor, Windsurf oder eine andere KI-IDE zu ersetzen. Diese Werkzeuge machen einen Programmierer innerhalb der Coding-Ebene effektiver. Orgabot versucht, diese Ebene zu einem Ort zu machen, den ich kaum noch betreten muss.
Die IDE könnte zu einem Implementierungsdetail werden
Deshalb glaube ich, dass wir in eine Post-IDE-Ära eintreten.
Das bedeutet nicht, dass IDEs morgen verschwinden, und nicht einmal, dass grafische Codeeditoren verschwinden. Es wird immer Situationen geben, in denen der direkte Blick in den Quellcode der beste Weg ist, ein Problem zu verstehen. Aber ich glaube, dass die IDE ihre Position als wichtigste Schnittstelle zwischen Programmierer und Software verliert.
Die Agentenumgebung wird zu dieser Schnittstelle. Das schafft ein unangenehmes strategisches Problem für Hersteller traditioneller IDEs ebenso wie für Hersteller von KI-IDEs. Die naheliegende Reaktion war, KI in die IDE zu integrieren: ein Chatfenster, Autovervollständigung und einen Agentenmodus ergänzen und die KI mehrere Dateien gleichzeitig ändern lassen.
Das sind nützliche Verbesserungen, aber ich frage mich, ob die Architektur dabei nicht auf dem Kopf steht.
Vielleicht ist die Zukunft keine IDE mit einem Agenten darin. Vielleicht ist sie ein Agent mit einem Editor darin.
Der Agent wird zur Umgebung. Repository, Terminal, Browser, Debugger, Editor, Tests, CI-System, Issue-Tracker und Bereitstellungsinfrastruktur stehen dieser Umgebung bei Bedarf als Werkzeuge zur Verfügung. Meist bleibt der Mensch eine Ebene darüber.
Ich habe JetBrains nicht gekündigt, weil JetBrains schlechter wurde
Dieser Unterschied ist wichtig. JetBrains hat mich nicht verloren, weil IntelliJ schlechte Software geworden wäre. Ganz im Gegenteil: IntelliJ bleibt eine erstaunlich leistungsfähige Ingenieursleistung.
Ich habe gekündigt, weil sich mein Arbeitsablauf so grundlegend verändert hat, dass ich 99 Prozent seiner Funktionen nicht mehr brauche. Das ist eine viel größere Bedrohung. Das schwierigste Wettbewerbsproblem entsteht nicht, wenn jemand eine bessere Version deines Produkts baut. Es entsteht, wenn sich das Nutzerverhalten so stark verändert, dass die ganze Produktkategorie weniger wichtig wird.
Jahrelang wollte ich die bestmögliche Umgebung zum Bearbeiten von Quellcode. Dann wollte ich die bestmögliche Umgebung zum Anweisen von Agenten, die Quellcode bearbeiten. Zunehmend beschreibt selbst das die Entwicklung nicht weitgehend genug.
Ich möchte die bestmögliche Umgebung zum Aufbau von Agentenorganisationen, die Verantwortung übernehmen, Arbeit delegieren, sich gegenseitig prüfen, bei Bedarf eskalieren und Software produzieren können, ohne mich in die Implementierungsebene hinabzuzwingen.
Die IDE ist nicht das Zentrum dieser Welt. Sie ist ein Werkzeug, das einer der Agenten möglicherweise verwendet.
Nach Jahren des Lebens in IDEs glaube ich, dass ich sie vielleicht endlich hinter mir gelassen habe.
