Coding-Agenten haben bisher vor allem Code geschrieben und dann den Menschen gebeten, nachzusehen, ob es funktioniert. Am 23. Oktober hat Cursor die Lücke geschlossen: Mit „Computer Use“ dürfen Agenten in Desktop-Anwendungen klicken und tippen — einschließlich des iOS-Simulators, in dem sie die Funktion testen, die sie gerade gebaut haben.
Der Ablauf ist genau der, den Entwickler bisher von Hand gingen: Feature implementieren, App starten, durch den Ablauf klicken, Fehler finden, Code korrigieren, denselben Ablauf wiederholen. Ein Beispiel: Ein Agent baut eine Notiz-App, öffnet sie, gibt „Buy coffee“ ein, drückt Speichern und prüft, ob genau ein Eintrag erscheint. Dann speichert er ein leeres Feld und ein Feld mit reinen Leerzeichen — beides darf keinen Eintrag erzeugen. Schließlich schließt er die App, öffnet sie erneut und prüft, ob die Notiz persistiert wurde.
Der letzte Schritt ist der interessante. Ein Screenshot nach dem Drücken von Speichern beweist nur, was in diesem Moment zu sehen war. Erst das erneute Öffnen zeigt, ob der Speichervorgang tatsächlich funktioniert — und genau diese Art von Fehler entgeht Unit-Tests, weil der Code kompiliert, während der Button einen leeren String schreibt, den Eintrag doppelt anlegt oder gar nichts tut.
Cursors eigener Hinweis dazu ist nüchtern: Der Agent kann Computer Use selbst wählen, wenn eine Aufgabe es verlangt, oder explizit per Erwähnung im Prompt aufgerufen werden. Voraussetzung ist ein aktualisierter Cursor-Client. Unter macOS braucht der Agent zwei Berechtigungen: Bedienungshilfen (Accessibility), um mit Anwendungen zu interagieren, und Bildschirmaufnahme (Screen Recording), um die Oberfläche zu erfassen. Beide werden an einen eigenen Helper namens „Cursor Computer Use“ vergeben — nicht an das Terminal, nicht an Cursor selbst.
Das ist der Punkt, an dem die Geschichte über Produktivität hinausgeht. Accessibility ist unter macOS keine eingeschränkte Schnittstelle: Eine App mit dieser Berechtigung kann steuern, was auf dem Bildschirm passiert — in jedem Fenster, nicht nur im Simulator. Wer sie einem Agenten gibt, gibt sie einem Prozess, der Anweisungen aus einem Sprachmodell ausführt. Die naheliegenden Gegenmaßnahmen sind organisatorisch, nicht technisch: mit einer Wegwerf-Kopie der App und Testdaten arbeiten, Aufgaben klein und prüfbar halten, den Agenten nicht gleichzeitig in Mail, Passwortmanager und Browser laufen lassen und für Abläufe, die Neustarts oder Zustandsänderungen am Desktop brauchen, eine separate Maschine oder VM verwenden.
Cursor trennt die Ausführungsumgebungen bereits. Der eingebaute Browser bleibt die richtige Wahl für Web-Formulare, weil er Konsolen- und Netzwerkfehler mitliest. Cloud-Agenten haben ihren eigenen Desktop in einer entfernten VM, getrennt von den Apps auf dem Laptop. Self-hosted Worker unterstützen Computer Use unter macOS und Linux und werden mit --computer-use aktiviert.
Und die Grenze des Verfahrens: Für eine reine Funktion oder eine API-Antwort ist der Umweg über die Oberfläche Verschwendung. Nützlich wird Computer Use genau dort, wo der Fehler nur im laufenden Interface sichtbar wird — ein Formular, das die Eingabe verwirft, eine Einstellung, die nach dem Schließen des Fensters verschwindet, ein Button, der auf dem Gerät nicht reagiert, obwohl der Code stimmt.
Agenten, die ihre eigene Arbeit sehen können, sind ein echter Sprung für alle, die UI-Änderungen bisher selbst nachklicken mussten. Sie sind auch ein weiteres Stück Berechtigung, das ein Modell mit zweifelhaften Anweisungen potenziell erben kann. Beides gehört in dieselbe Entscheidung.
