Stell dir vor, du bekommst einen neuen Kollegen. Er ist hochmotiviert, lernt schnell und arbeitet rund um die Uhr. Aber er kommt aus einer anderen Welt: Er hat noch nie auf deinem Rechner gearbeitet, kennt deine Skripte nicht und scheitert an den stillschweigenden Absprachen, die in deinem Team einfach jeder zu wissen scheint. So ähnlich erging es dem Unternehmen Cursor, als es seinen Cloud-Agenten eigene Computer gab. Die Entwicklerinnen und Entwickler merkten schnell: Wer Cloud-Agenten produktiv einsetzen will, muss deren Entwicklungsumgebung genauso ernst nehmen wie ein Produkt. Dieser Blogpost erklärt, wie Cursor das angegangen ist und warum die Umgebung zum entscheidenden Faktor wurde.
Vom lokalen Rechner zur Cloud-VM
Der erste Schritt war ernüchternd simpel und gleichzeitig verdammt aufwendig: Die Cloud-Agenten sollten Codeänderungen testen können. Dafür musste das Monorepo von Cursor in einer Cloud-VM lauffähig sein. Wer schon einmal eine Remote-Entwicklungsumgebung eingerichtet hat, kennt das Problem: Was lokal funktioniert, ist in der Cloud nicht automatisch vorhanden. Die meisten Entwicklerinnen und Entwickler bei Cursor arbeiten auf Macs, die Cloud-VMs laufen aber auf Linux. Also mussten Utilities und Setup-Skripte so angepasst werden, dass sie auf Ubuntu funktionieren. Dazu kam ein Dockerfile, das als Startpunkt für jeden Cloud-Agenten dient und die kritischen Entwicklungsabhängigkeiten enthält.
Doch damit war es nicht getan. Denn Agenten brauchen Zugriff auf Secrets, um Tests auszuführen. Das Sicherheitsteam von Cursor hat deshalb Funktionen eingebaut, die den Zugriff kontrollieren: Netzwerk-Egress-Restriktionen, gescopte und proxierte Git-Zugriffe, Secret-Scanning in Commits und Commit-Messages sowie Redaktion von Secrets in Tool-Ergebnissen. Letzteres ist besonders elegant: Selbst wenn der Agent versucht, einen Secret-Wert auszulesen, bekommt er nur maskierten Text zu sehen. Das sind Sicherheitsmaßnahmen, die nicht den Menschen schützen sollen, sondern die Infrastruktur vor ungewolltem Datenabfluss bewahren.
Der Agent als Nutzer einer vereinfachten Oberfläche
Nachdem die Entwicklungsumgebung technisch auf Linux lief, zeigte sich das nächste Problem: Die Agenten waren trotzdem schlecht darin, den Code auszuführen. Das lag nicht an mangelnder Intelligenz, sondern an der Komplexität der Entwicklererfahrung. Bei Cursor gab es zahlreiche Build-Kommandos, Build-Flags und Utility-Skripte, die man erst lernen musste. Ein Mensch merkt sich solche Abläufe nach ein paar Wochen. Ein Agent, der jedes Mal frisch startet, steht vor einem Berg aus undokumentiertem Zusammenhangswissen.
Die naheliegende Lösung waren Skills, also dokumentierte Anleitungen für den Agenten. Sie halfen am Rand, lösten das Grundproblem aber nicht: Die Kommandos selbst waren verschachtelt und voller Stolperfallen. Deshalb entstand bei Cursor ein Werkzeug namens anydev. Diese CLI erlaubt es Agenten, alle Dienste mit einem einzigen Befehl zu starten. Utility-Skripte werden durch anydev geroutet, und jeder Unterbefehl hat ausführliche --help-Menüs. Dazu kommt ein Supervisor-Prozess, der langlaufende Build-Kommandos überwacht und bei Abstürzen neu startet. Der Agent muss sich also nicht mehr darum kümmern, ob ein Prozess noch läuft.
Dieser Schritt war der Wendepunkt. Vorher mussten Agenten mehrere Befehle kennen, versteckte Fußangeln vermeiden und Prozesse im Auge behalten. Nachher war die Komplexität in einem Tool gebündelt, das selbst erklärend war. Skills dokumentierten dann nur noch, wie man anydev benutzt – und nicht mehr, welche kryptischen Flags man für welchen Dienst braucht. Laut dem Cursor-Team war das der Moment, in dem Cloud-Agenten echten Mehrwert gegenüber lokalen Agenten boten. Mit eigenem Rechner, Bildschirmaufnahme und funktionierender Entwicklungsumgebung konnten sie Änderungen end-to-end testen und die Korrektheit ihrer Arbeit nachweisen. Sie zeichneten Demos auf, teilten sie in Slack oder hängten sie an Pull Requests. Ingenieure konnten Merges und Deployments durchführen, ohne den Branch lokal auszuchecken.
Eine selbstheilende Umgebung
Eine Entwicklungsumgebung ist aber kein statisches Gebilde. Sie ändert sich mit jedem Commit, mit jeder neuen Abhängigkeit, mit jeder Verschärfung der Sicherheitsrichtlinien. Ein Cloud-Agent, der heute fehlerfrei arbeitet, kann morgen scheitern, weil sich ein Pfad geändert hat oder ein Secret nicht mehr gültig ist. Cursor hat deshalb eine Diagnose- und Reparatur-Ebene gebaut: den Cursor Cloud MCP. MCP steht für Model Context Protocol, ein offener Standard, der es ermöglicht, Werkzeuge dynamisch bereitzustellen. Der Vorteil: Die Schnittstellen lassen sich ändern, ohne den Agenten-Loop neu bauen zu müssen.
Cloud-Agenten nutzen diese MCP-Schnittstelle, um ihre eigene Umgebung zu inspizieren. Sie prüfen, ob Setup-Fehler vorliegen, ob die Egress-Policy noch stimmt, ob sich Secrets geändert haben. So können sie Probleme erkennen, noch bevor sie zu Fehlern führen. Darauf aufbauend entstand der Cloud Doctor: eine Automatisierung, die regelmäßig nach Fehlern sucht, zwischen transienten und dauerhaften Fehlern unterscheidet, eine Ursachenanalyse durchführt und bei hoher Konfidenz selbst Pull Requests öffnet, um die Umgebung zu reparieren.
Das klingt nach einem versierten DevOps-Team, nur eben als Software realisiert. Der Cloud Doctor ist nicht einfach ein Watchdog, der einen Dienst neu startet. Er versteht den Kontext: Dieser Fehler kam letzten Freitag schon einmal und war harmlos, jener ist neu und deutet auf ein echtes Problem hin. Er erinnert sich, welche Fehler transiente Ausreißer sind und welche auf systematische Schwächen hinweisen. Und er kann nicht nur reparieren, sondern auch die Ursache beheben – indem er einen Pull Request erstellt, der die Umgebung an die neue Realität anpasst.
Die Umgebung als lernendes System
Interessant wird es, wenn der Cloud Doctor nicht nur Fehler behebt, sondern die Umgebung für zukünftige Agenten verbessert. Das passiert laut Cursor über die Analyse von Trace-Daten. Wenn ein Agent einen Fehler gemacht hat, einen umständlichen Weg gegangen ist oder ein Skill ihn in die Irre geführt hat, dann sieht man das in den Logs. Der Cloud Doctor schaut sich diese Stellen an und fragt: Welcher Skill war irreführend? Welches Kommando war nicht eindeutig? Welcher Workflow dauert systematisch zu lange?
Aus diesen Erkenntnissen entstehen dann konkrete Verbesserungen: Ein Skill wird neu formuliert, ein Befehl vereinfacht, die Umgebung wird so verändert, dass der nächste Agent einen kürzeren und sichereren Weg hat. Diesen Kreislauf könnte man als Selbstheilung bezeichnen, aber eigentlich ist es mehr: Es ist eine kontinuierliche Optimierung der Entwicklererfahrung für Maschinen. Cursor behandelt die Agenten wie Nutzer, deren Produktivität davon abhängt, wie gut die Umgebung zu ihrer Art zu arbeiten passt. Und diese Nutzer sind gnadenlos ehrlich: Wenn etwas nicht funktioniert, scheitern sie sichtbar. Das ist ein Vorteil gegenüber menschlichen Nutzern, die oft einfach stillschweigend einen Workaround finden.
Die Zahlen, die das Cursor-Team nennt, sind beeindruckend. Im Dezember verfassten Cloud-Agenten etwa eines von zehn Pull Requests, die in das Monorepo gemergt wurden. Heute, nur wenige Monate später, sind es mehr als die Hälfte. Das ist kein Beweis für überirdische KI-Fähigkeiten, sondern für die Qualität der Umgebung. In einer Umgebung, die regelmäßig repariert, vereinfacht und an die aktuelle Codebasis angepasst wird, können Agenten ihre Stärke ausspielen: Sie arbeiten schnell, parallel und ohne Angst vor Fehlern – solange die Fehler schnell sichtbar und behebbar sind.
Drei Fragen an die eigene Codebasis
Was bedeutet das für Teams, die Cloud-Agenten einführen wollen? Das Cursor-Team schlägt vor, sich drei Fragen zu stellen. Erstens: Haben Agenten Zugriff auf dieselben Werkzeuge und Daten wie ein Entwickler? Zweitens: Können Agenten Skills finden, die dokumentieren, wie die Entwickler wirklich arbeiten? Drittens: Können Agenten die zentralen Workflows testen und verifizieren? Wer diese drei Fragen ehrlich beantwortet, erkennt schnell, wo die eigene Umgebung Lücken hat.
Die erste Frage zielt auf technische Gleichberechtigung. Ein Agent, der nicht dieselben Bibliotheken, Datenbanken oder Secrets nutzen kann wie ein Mensch, wird immer ein Bürger zweiter Klasse bleiben. Die zweite Frage ist eine Frage der Kultur: Viele Teams dokumentieren nicht, wie sie tatsächlich arbeiten. Sie haben Skripte auf dem Rechner eines Kollegen, Notizen in einem Ticket oder gar kein Wissen, weil es nur als Bauchgefühl existiert. Agenten können damit nichts anfangen – sie brauchen explizite, auffindbare Beschreibungen. Die dritte Frage ist der Härtetest: Kann ein Agent eine Änderung machen und dann beweisen, dass sie funktioniert? Wenn dafür zehn manuelle Schritte nötig sind, wird es schwierig.
Auf den ersten Blick mag das wie eine Checkliste für KI-Projekte wirken. Tatsächlich ist es eine Checkliste für gute Softwareentwicklung. Dass Cursor das Monorepo auf Ubuntu lauffähig gemacht hat, ist keine KI-Magie, sondern solides Engineering. Dass anydev die Build-Kommandos vereinfacht hat, ist eine klassische Verbesserung der Entwicklererfahrung – nur eben für einen anderen Nutzer. Und dass der Cloud Doctor Fehler behebt, bevor sie zum Problem werden, ist nichts anderes als Site Reliability Engineering, angewendet auf Agenten.
Was bleibt, ist eine erwachsene Erkenntnis: Cloud-Agenten sind keine Wunderwaffe, sondern Werkzeuge, die nur so gut sind wie ihre Umgebung. Eine chaotische Codebasis mit undokumentierten Skripten wird auch durch die besten Modelle nicht produktiv. Wer jedoch bereit ist, die Entwicklungsumgebung wie ein Produkt zu behandeln – mit Nutzerforschung, Bugfixes und kontinuierlicher Verbesserung – der bekommt Agenten, die nicht nur Code produzieren, sondern auch Verantwortung übernehmen können. Das ist der eigentliche Umbruch: Nicht die KI schreibt die Mehrheit der Pull Requests, sondern die Umgebung macht es möglich.
Quelle: cursor.com
