Von Claude Code zu REA: KI-Agenten gehen vom „Schreiben von Code“ zum „Bedienen von Software“ über

Ein überprüfbarer Ausgangspunkt: Für das Projekt REA gibt es neben der Projektseite eine eigene Installationsanleitung (REA-Projektbeschreibung, Installationsdokumentation). Das belegt zunächst ein konkretes Softwareprojekt, aber nicht, dass „REA“ eine allgemein festgelegte Agentenkategorie bezeichnet.

Symptom: Ihr Agent kann Code ändern, aber nicht ohne Weiteres einen vollständigen Ablauf in einer anderen Anwendung erledigen.
Schnellste Einordnung: Claude Code steht für Arbeit am Code; REA ist anhand seiner eigenen Projektdokumentation zu beurteilen. Der Übergang erweitert die möglichen Aufgaben von KI-Agenten, ersetzt Coding-Agenten aber nicht.

Dieser Beitrag richtet sich an Entwicklerinnen und Entwickler, die Claude Code nutzen, an Teams mit Automatisierungsplänen für Geschäftsanwendungen und an technische Verantwortliche, die Laufzeitumgebung, Rechte und Prüfbarkeit bewerten müssen.

Was ändert sich bei KI-Agenten vom Code-Schreiben zum Bedienen von Software?

Ein Coding-Agent und ein Agent, der Software bedient, unterscheiden sich nicht nur durch die Art der Ausgabe. Entscheidend ist, worauf sie einwirken und wie sich der Erfolg feststellen lässt.

Ein Coding-Agent erhält typischerweise Zugriff auf einen Codebestand und soll darin etwas nachvollziehbar ändern: eine Funktion ergänzen, einen Fehler beheben oder Tests anpassen. Er kann die Änderung mit Befehlen und Tests prüfen. Die offizielle Dokumentation zur Claude-Code-CLI beschreibt die Arbeit über eine Kommandozeile. Daraus folgt jedoch nicht, dass jedes Coding-System dieselben Fähigkeiten oder denselben Zugriff besitzt.

Beim Bedienen von Software wird die Anwendung selbst zum Arbeitsgegenstand. Der Agent muss ihren Zustand erfassen, eine passende Aktion auswählen und anschließend prüfen, ob die Anwendung den erwarteten Zustand erreicht hat. Je nach System kann diese Interaktion über eine grafische Oberfläche, verfügbare Werkzeuge oder eine Schnittstelle erfolgen. Der Unterschied ist praktisch: Ein Agent, der Code für einen Rechnungsimport schreibt, führt nicht automatisch auch den Import in einer Buchhaltungsanwendung aus.

Das ist eine Erweiterung des Aufgabenbereichs, keine Ablösung. Wenn Sie eine neue Funktion in einer Codebasis implementieren, ist ein Coding-Agent oft der passendere Ansatz. Wenn ein Team wiederkehrend Datensätze in einer Anwendung eintragen und den Abschlussstatus kontrollieren muss, kann ein Software-bedienender Agent interessanter sein. Für manche Abläufe werden beide Ansätze kombiniert: Der eine bereitet Änderungen vor, der andere arbeitet in der Anwendung.

Dieselbe Aufgabe, zwei Ausführungsketten

Nehmen wir einen wiederkehrenden Vorgang: Ein Team soll eine Änderung an einem internen Verwaltungsprozess einführen und anschließend sicherstellen, dass sie auch im Fachsystem angekommen ist.

Die Tabelle beschreibt eine funktionale Unterscheidung, keine Garantie für bestimmte Produkte. Ob REA eine konkrete Aktion ausführen kann, müssen Sie an der Projektdokumentation und an einem reproduzierbaren Test prüfen. Eine Demo oder eine Projektbeschreibung allein belegt keine Stabilität im produktiven Betrieb.

Was bezeichnet REA, und was heißt hier „Software bedienen“?

REA ist in diesem Zusammenhang zunächst der Name eines konkreten Projekts. Die Bezeichnung allein erklärt weder eine standardisierte Agentenklasse noch eine allgemein gültige Langform des Kürzels. Deshalb sollte man keine ausgeschriebene Bedeutung aus den Buchstaben ableiten, wenn sie nicht in einer verlässlichen Projektquelle eindeutig ausgewiesen ist. Maßgeblich sind die REA-Projektbeschreibung und die dazugehörigen Installationshinweise.

„Software bedienen“ meint hier einen Ausführungsablauf, der über das Erstellen oder Bearbeiten von Quellcode hinausgeht. In der Praxis umfasst er mindestens vier miteinander verbundene Fragen:

1. Zustand erfassen: Welche Ansicht, Auswahl oder Rückmeldung zeigt die Anwendung gerade?
2. Aktion auswählen: Welche verfügbare Bedienhandlung passt zum gewünschten Arbeitsschritt?
3. Aktion ausführen: Kann der Agent die Handlung mit den vorgesehenen Werkzeugen oder über die Oberfläche anstoßen?
4. Ergebnis prüfen: Ist der Zielzustand tatsächlich eingetreten, oder muss der Agent abbrechen beziehungsweise nachfragen?

Das ist ein Prüfmodell, keine Behauptung, dass jedes System diese Schritte zuverlässig beherrscht. Die Projektseite und Installationsdokumentation können Hinweise zur konkreten Einrichtung geben; die für Ihr Team entscheidende Frage bleibt aber, welche Anwendungen, Zustände und Fehlerfälle tatsächlich unterstützt werden. Ein Agent, der eine Schaltfläche anklicken kann, hat damit noch nicht bewiesen, dass er einen Geschäftsvorgang fachlich korrekt abschließt.

Auch Werkzeugbeschreibungen sind keine Sicherheitsgarantie. Die Erläuterungen zu Tool-Anmerkungen im Model Context Protocol sind für die Einordnung nützlich: Beschreibende Angaben zu Werkzeugen sollten nicht mit einer wirksamen Berechtigungskontrolle verwechselt werden. Wenn eine Aktion sensible Daten verändert oder nach außen übermittelt, müssen Sie die erlaubten Handlungen zusätzlich in der tatsächlichen Laufzeitumgebung begrenzen.

Wo liegen Einsatzgrenzen, und wann bleibt Claude Code geeigneter?

Softwarebedienung ist vor allem bei wiederholbaren, regelgebundenen Abläufen interessant, deren Ergebnis sich unabhängig kontrollieren lässt. Beispiele sind das Übertragen definierter Informationen zwischen Anwendungen, das Ausfüllen gleichbleibender Formulare oder das Erstellen eines Entwurfs in einem klar abgegrenzten Prozess. Diese Beispiele sind mögliche Einsatzfelder, keine Zusage, dass eine bestimmte REA-Version sie unterstützt.

Ein typischer Teamfall: Ein Supportteam erhält regelmäßig Anfragen mit denselben Pflichtangaben. Ein Agent könnte die Informationen sortieren und einen Vorgang in einer internen Anwendung vorbereiten. Sinnvoll ist das nur, wenn Mitarbeitende die Eingaben und den fertigen Vorgang kontrollieren können. Ändert sich die Maske, fehlt ein Pflichtfeld oder ist ein Datensatz mehrdeutig, muss der Agent den Vorgang anhalten, statt eine plausible, aber falsche Eingabe zu erzeugen.

Mögliche Vorteile eines Software-bedienenden Agenten:

• Er kann wiederkehrende Arbeit direkt dort unterstützen, wo der Prozess stattfindet.
• Er kann Schritte verbinden, für die sonst zwischen Anwendungen und Eingabemasken gewechselt wird.
• Er kann auch Aufgaben adressieren, die sich nicht sinnvoll als Codeänderung ausdrücken lassen.

Nachteile und Grenzen:

• Oberflächen, Beschriftungen und Abläufe können sich ändern; die gleiche Bedienfolge ist dann nicht zwingend weiterhin korrekt.
• Fehler sind schwerer zu erkennen, wenn Erfolg nur an einer sichtbaren Rückmeldung statt an einem verlässlichen Systemstatus gemessen wird.
• Schreib-, Lösch- oder Freigaberechte können aus einem Bedienfehler einen fachlichen oder datenschutzrechtlichen Vorfall machen.
• Eine robuste Wiederaufnahme nach Unterbrechung oder Teilfehler muss geplant und getestet werden.

Claude Code bleibt oft die bessere Wahl, wenn die Aufgabe in einer Codebasis liegt: etwa beim Ändern einer Funktion, beim Anpassen von Tests oder beim Prüfen einer konkreten Implementierung. Die offizielle Berechtigungsdokumentation für den Claude-Agent-SDK ist dabei relevant, weil sie die Berechtigungsfrage ausdrücklich als Teil der Agentenausführung behandelt. Übertragen Sie daraus aber keine pauschale Aussage auf andere Agenten oder Werkzeuge: Rechte und Schutzmechanismen sind für das tatsächlich eingesetzte System separat zu verifizieren.

Entscheidung nach Risiko und Prüfbarkeit

Wählen Sie einen Software-bedienenden Agenten eher dann, wenn der Prozess klar begrenzt ist, die notwendigen Rechte minimal gehalten werden können und der Zielzustand zuverlässig kontrollierbar ist. Bleibt eine Aktion schwer rückgängig zu machen oder ist ihr Ergebnis nicht unabhängig prüfbar, sollte der Agent zunächst nur einen Entwurf erstellen oder eine Person um Bestätigung bitten.

Prüfung der Eignung für Ihren Ablauf

Bevor Sie einen Agenten an eine reale Anwendung lassen, testen Sie nicht nur, ob er eine gewünschte Aktion einmal erfolgreich ausführt. Entscheidend ist, ob er den Ablauf unter den Bedingungen Ihres Teams sicher beginnt, prüft und bei Abweichungen stoppt.

1. Aufgabe konkret abgrenzen. Beschreiben Sie einen einzelnen Geschäftsvorgang mit Auslöser, Eingaben und erwartetem Endzustand. „Bearbeitet Anfragen“ ist zu ungenau; „übernimmt diese festgelegten Felder in einen Entwurf und meldet fehlende Angaben“ ist prüfbar.
2. Das richtige Arbeitsmodell wählen. Liegt die Änderung im Code, prüfen Sie einen Coding-Agenten. Findet die eigentliche Arbeit in einer Anwendung statt, testen Sie einen Software-bedienenden Ansatz. Wenn der Prozess beide Ebenen umfasst, trennen Sie Vorbereitung und Ausführung.
3. Berechtigungen begrenzen. Starten Sie mit den geringsten notwendigen Rechten. Für irreversible Änderungen, externe Übermittlungen oder Zugriffe auf sensible Informationen sollte eine explizite Freigabe vorgesehen sein. Die Regeln des Claude-Agent-SDK zu Berechtigungen sind hierfür eine produktspezifische Referenz, aber kein Ersatz für Ihre eigene Richtlinie.
4. Abweichungen absichtlich testen. Prüfen Sie nicht nur den Normalfall. Testen Sie fehlende Eingaben, unerwartete Rückmeldungen, geänderte Ansichten und Unterbrechungen. Legen Sie fest, wann der Agent stoppt und welche Informationen er dann meldet.
5. Ergebnis unabhängig verifizieren. Kontrollieren Sie den Zielzustand über einen verlässlichen Status, einen nachvollziehbaren Datensatz oder eine menschliche Prüfung. Eine erfolgreiche Aktion in der Oberfläche ist nicht automatisch ein fachlich korrektes Ergebnis.
6. Protokollierung und Datenschutz bewerten. Klären Sie, welche Anwendungsdaten verarbeitet und gespeichert werden, wer auf Protokolle zugreifen kann und wie lange sie verfügbar bleiben. Für den Umgang mit personenbezogenen Daten sind Ihre internen Vorgaben und die jeweils geltenden Datenschutzanforderungen maßgeblich; Informationen zur Datenschutzerklärung von Kvmzen können Sie getrennt davon prüfen.

Diese Schritte helfen, eine Demo von einem belastbaren Arbeitsablauf zu unterscheiden. Testen Sie zudem mit einer repräsentativen Anwendung und einem begrenzten Datensatz, bevor Sie Zugriff auf produktive Vorgänge erwägen. Dabei sollten Sie festhalten, welche Fälle der Agent selbst abschließt, bei welchen er nachfragt und welche er konsequent ablehnt.

Welche Laufzeitumgebung braucht ein Agent für die Arbeit mit Software?

Die passende Umgebung ergibt sich aus dem tatsächlichen Arbeitsablauf: Welche Betriebssystemfunktionen werden benötigt? Muss eine Desktop-Anwendung geöffnet bleiben? Welche Schnittstellen und Anmeldedaten sind zulässig? Wie werden Unterbrechungen erkannt? Ohne überprüfbare Angaben zu einem konkreten REA-Einsatz lassen sich daraus keine pauschalen Hardware-, Leistungs- oder Verfügbarkeitswerte ableiten.

Bei einer lokalen Umgebung behalten Sie die Kontrolle über Gerät und Anwendungen, müssen aber selbst für Verfügbarkeit, Updates und Zugriffsschutz sorgen. Eine entfernte Mac-Umgebung kann sinnvoll sein, wenn der Agent oder der begleitende Entwicklungs- und Build-Prozess eine Mac-Laufzeit benötigt und Ihr Team den Zugriff kontrolliert bereitstellen kann. Sie ist nicht automatisch für jeden Agenten erforderlich und behebt weder instabile Bedienlogik noch fehlende Berechtigungsgrenzen.

Wenn Sie einen Mac für Entwicklung, Builds oder einen zeitlich begrenzten Test bereitstellen müssen, prüfen Sie die verfügbaren Mac-Mietoptionen von Kvmzen anhand der dort veröffentlichten Angaben. Daraus sollten Sie keine nicht aufgeführten Leistungs-, Standort- oder Verfügbarkeitsmerkmale ableiten. Für Teams mit dauerhaftem, planbarem Betrieb kann ein eigener Mac wirtschaftlicher und einfacher zu kontrollieren sein; für einzelne Tests kann eine gemietete Umgebung dagegen vermeiden, dass Sie vorab eigene Hardware beschaffen.

Nutzen Sie zum Abschluss diese Entscheidungszweige:

• Wenn Ihre Aufgabe Code ändert, sich durch Tests oder Befehle prüfen lässt und keine direkte Bedienung einer Fachanwendung verlangt, wählen Sie zunächst einen Coding-Agenten wie Claude Code.
• Wenn Ihre Aufgabe aus wiederkehrenden Anwendungsschritten besteht, der Zielzustand kontrollierbar ist und die Rechte begrenzt bleiben, testen Sie einen Software-bedienenden Agenten in einer abgegrenzten Umgebung.
• Wenn der Ablauf sensible Daten verändert, Freigaben auslöst oder schwer rückgängig zu machen ist, lassen Sie den Agenten zunächst nur vorbereiten und verlangen Sie eine menschliche Bestätigung.
• Wenn die benötigte Anwendung in einer entfernten Mac-Umgebung laufen muss, prüfen Sie zuerst Laufzeit, Zugriff, Datenschutz und Ergebnisprüfung; entscheiden Sie erst danach zwischen lokaler Hardware und einer gemieteten Umgebung.

Der Schritt von Claude Code zu REA ist damit weniger eine Rangfolge als eine Frage des passenden Ausführungsmodells. Bevor Sie einen Agenten auswählen, klären Sie, ob Ihr Engpass im Code oder in der Bedienung einer Anwendung liegt, welche Berechtigungen der Ablauf wirklich braucht und wie Sie Fehler erkennen. Eine entfernte Mac-Umgebung kann für Entwicklung, Builds oder abgegrenzte Agententests passend sein; sie ersetzt aber weder eine belastbare Prüfung noch die Entscheidung, ob der konkrete Prozess überhaupt automatisiert werden sollte.