Der Moment, in dem sich etwas verschiebt
Stell dir vor, du öffnest deinen Mac.
Zwei Aufgaben laufen parallel. Eine VM wird konfiguriert. Gleichzeitig wählt jemand Musik auf Spotify aus und trägt einen Termin in die Erinnerungen ein.
Dieser jemand bist nicht du.
Du arbeitest weiter. Dein Cursor liegt ruhig auf deinem Bildschirm. Ein zweiter Cursor, animiert, erkennbar, bewusst anders, erledigt die Klickarbeit. Fünf Apps. Mehrere Stunden Aufwand. Im Hintergrund.
Das ist kein Automatisierungs-Skript. Das ist kein Macro-Recorder.
Das ist Computer Use.
Was bisher kaum jemand versteht
Die meisten Implementierungen von KI-gestützter GUI-Steuerung funktionieren nach demselben Prinzip: Screenshot machen, analysieren, klicken, warten, nächster Screenshot.
Das Problem dabei ist nicht die Idee.
Das Problem ist die Architektur.
Screenshots sind Bilder. Bilder sind langsam zu verarbeiten. Bilder erfassen nicht, was off-screen gescrollt ist. Und Bilder brauchen multimodale Modelle, die für pure Klick-Präzision zu schwerfällig sind.
macOS liefert seit Jahren etwas viel Besseres: das Accessibility-Framework. Strukturierte, textuelle UI-Daten. Jedes Element, sein Typ, seine Position, sein Zustand, als strukturierte Information, nicht als Pixelwolke.
Wer dieses Framework anzapft, braucht keinen Screenshot-Kreislauf mehr.
Ergebnis: Ein schnelles, nicht-multimodales Modell kann die Benutzeroberfläche schneller bedienen als ein Mensch.
Nicht geringfügig schneller.
Deutlich schneller.
Die Entscheidung, die alles ändert
Es gibt eine Design-Entscheidung in dieser Architektur, die auf den ersten Blick klein wirkt.
Kein geteilter Desktop.
Bisherige Implementierungen haben den gesamten Bildschirm übernommen, das bedeutet: entweder du arbeitest, oder die KI arbeitet. Nicht beides gleichzeitig.
Die Lösung: ein separater Cursor. Vollständig unabhängig. Sichtbar, aber nicht im Weg. Der Nutzer bedient seinen Mac. Der zweite Cursor bedient, was ihm erlaubt wurde.
Und genau dort steckt der zweite entscheidende Punkt: das Berechtigungsmodell.
App für App. Beim ersten Zugriff auf eine Anwendung fragt das System explizit nach. Wer nicht freigegeben ist, bleibt vollständig isoliert. Keine Desktop-Übertragung. Kein Dateizugriff im Hintergrund. Nur das, was du bewusst öffnest.
Sicherheit durch Granularität, nicht durch Verbote.
Wer das falsch liest, verliert Zeit
Der häufige Fehler beim Einordnen solcher Tools: man denkt in Einzelaufgaben.
"Ich könnte damit eine VM aufsetzen lassen."
Das stimmt. Aber das ist die kleine Version der Erkenntnis.
Die größere: Jede Aufgabe, die aus mehreren Apps, mehreren manuellen Schritten und keiner echten Denkarbeit besteht, gehört ab jetzt in eine andere Kategorie. Nicht mehr "muss ich irgendwann machen". Sondern "kann ich delegieren".
Datenpflege in Spreadsheets. Software-Konfiguration. Formular-Workflows. Setup-Prozesse mit zehn Klicks, die sich alle zwei Monate wiederholen.
Das ist die Zielgruppe dieser Technologie. Nicht der Einzelfall. Die strukturelle Redundanz in jedem Arbeitstag.
Was das für eigene Builds bedeutet
Wer selbst Produkte baut oder Automatisierungen architektiert, sollte sich eine Frage merken:
Warum Screenshots, wenn Accessibility-Daten existieren?
Das Architektur-Muster, textuelle UI-Metadaten statt Bildverarbeitung, ist übertragbar. Für eigene Agent-Builds, für Tool-Integrationen, für jede Umgebung, die strukturierte Interface-Informationen nach außen gibt.
Schnellere Modelle. Zuverlässigere Erkenntnis. Weniger Fehler bei unerwarteten UI-Zuständen.
Die Technologie ist noch nicht perfekt. Offene Fragen bleiben: wie verhält sich das Berechtigungsmodell im Browser, wenn mehrere Tabs offen sind? Was passiert, wenn die UI in einem unerwarteten Zustand ist? Wann fragt das System aktiv nach, statt autonom weiterzumachen?
Diese Fragen sind real. Und sie sind der Grund, warum der sinnvollste erste Schritt nicht der komplexeste ist.
Wo du anfängst
Nicht mit dem ambitioniertesten Use-Case.
Mit dem nervigsten.
Der Aufgabe, die du seit Monaten vor dir herschiebst, weil sie fünf Apps braucht, drei Stunden dauert und kein einziges Mal echtes Denken erfordert.
Die, für die du immer wieder Zeit blockierst, und die dann doch im Rückstand bleibt.
Dort fängst du an.
Nicht weil du die Grenzen des Tools testen willst. Sondern weil du spüren willst, was passiert, wenn ein Cursor arbeitet und du gleichzeitig schon beim nächsten bist.
Das Ziel ist nicht Automatisierung um der Automatisierung willen.
Das Ziel ist: mehr von dir in der Arbeit, die nur du kannst.
Der Rest?
Läuft im Hintergrund.