Frank Brunner hatte sich gleich zu Beginn mit einem Beitrag gemeldet – allerdings mit einer Einschränkung: erst nach 21 Uhr, denn dann habe er wieder Tokens. Die Münchner kannten Teile seines Berichts bereits, doch Frank hatte ihn inzwischen weiter ausgebaut und brachte ein Experiment mit, das er erst am selben Morgen gestartet hatte.

Ergebnisse aus der Praxis

Zum Einstieg zeigte Frank, was in den letzten Monaten in der Lösung seines Hauptkunden entstanden ist, einem Anbieter von Dekonetzen, für den er Dokumentation und Planung abbildet. Alle neuen Funktionen laufen im Web Viewer und sind gemeinsam mit Claude entstanden.

  • Fotoabnahme: Dokumentationsfotos kommen strukturiert per E-Mail herein und werden über einen Code im Betreff zugeordnet. Eine Oberfläche gruppiert sie, und die Abnahme erfolgt flott per Pfeiltasten und Tastaturkürzeln. Freigegebene Fotos werden für den Kunden sichtbar.
  • Tourenplanung: Eine Kartendarstellung mit Leaflet und OpenStreetMap zeigt Depots und Touren. Die Fahrreihenfolge lässt sich per JavaScript nach Luftlinie optimieren, die Kilometer werden pauschal mit dem Faktor 1,3 hochgerechnet. Das ist der erste Bereich, in dem Frank auch Daten aus dem Web Viewer zurückschreibt.

“Das sind alles Sachen, die ich vor einem Jahr noch nicht mal hätte andenken können”, so Frank.

Das Setup: Entscheider, Coach und Worker

Herzstück des Berichts war Franks Arbeitsumgebung, die er sich über Monate aufgebaut hat:

  • Entscheider ist Frank selbst.
  • Mit dem Coach bespricht er alle Ideen, Aufgaben und Anforderungen. Der Coach entscheidet, was zu tun ist, und verteilt die Arbeit.
  • Die Worker erledigen die eigentliche Arbeit, jeweils auf Basis eines eigenen Repositorys: der Lab Analyst mit FM-Lab von Marcel Moré, der FM Producer auf Basis des Repositorys von Matt Petrowsky und ein Web-Viewer-Worker auf Basis des Repositorys von Adam Augustin. Die Repositorys werden gespiegelt und regelmäßig aktualisiert.
  • Kommuniziert wird ausschließlich über einen Hub, eine Art Schleuse. Jeder Worker darf nur in seinem eigenen Bereich und im Hub schreiben – dort landen Aufträge, Rückmeldungen und Ergebnisse.

Der Coach beurteilt die Ergebnisse, schickt sie gegebenenfalls zurück und meldet sich erst bei Frank, wenn eine Aufgabe gelöst ist oder eine Grenze erreicht wurde. Die wichtigste Regel: Der Coach selbst darf nichts produzieren. Manchmal ist er trotzdem “so schlau”, eine kleine XML-Änderung eben selbst zu erledigen – und dann funktioniert es nicht, weil nur der FM Producer weiß, wie das XML aussehen muss, damit es per Copy & Paste wieder in FileMaker landet. Jörg hat für solche Fälle Hooks gebaut, die bei bestimmten Befehlen ein Shell-Skript auslösen und den Agenten zur Ordnung rufen.

Frank arbeitet nicht im Terminal, sondern in der Claude-App. Der FM Producer legt Skripte als Dateien ab, deren erste Zeile jeweils den Skriptnamen enthält. Frank bekommt eine Liste, in welcher Reihenfolge er was neu anlegen oder ersetzen soll, und überträgt alles per Klick und Copy & Paste – oft in zehn Minuten erledigt und meist auf Anhieb korrekt. Ein paar eigene Konventionen haben sich eingespielt: Auf ein “Klar?” fasst der Agent sein Verständnis der Aufgabe zusammen, und Frank gibt ein Go oder eben nicht. Offene Ideen, Notizen und Aufgaben führt der Agent als “Fäden”, die er zu Beginn jeder Session prüft.

Experiment: Claude bedient FileMaker

Trotz allem bleibt viel Handarbeit – und so probierte Frank am Morgen des Stammtischs erstmals Computer Use mit Claude Code aus. Unter macOS kann Claude damit FileMaker direkt bedienen, entweder im Hintergrund oder mit Übernahme des Bildschirms. Manche Schritte gelingen im Hintergrund, für andere muss FileMaker in den Vordergrund.

Die Aufgabe: Eine am Vortag vorbereitete Logik sollte über die Oberfläche umgesetzt werden – Tabelle und Felder anlegen, Skripte einfügen, ein einfaches Web-Layout bauen. Frank ließ Claude jeden Schritt per Screenshot und Kommentar dokumentieren. Das Ergebnis: überraschend gut, aber mit typischen Anfängerfehlern.

  • Beim Anlegen mehrerer Felder übernahm Claude bei neun Feldern den Kommentar des zuvor markierten Feldes – und meldete trotzdem Erfolg.
  • Ein versehentlicher Zeilenumbruch beim Bestätigen landete im Skriptnamen, weshalb das Skript später nicht gefunden wurde. Die Ursache fand Claude allerdings schnell selbst.
  • Wie man in FileMaker Felder oder Tabellen markiert, kopiert und überträgt, musste Frank teilweise erklären – Claude suchte zunächst nach einem Knopf, wo ein Mensch einfach markiert und kopiert.

Aus dem Kommentar-Fehler entstand eine neue Regel: “Was nicht exportiert und verglichen wurde, gilt als ungeprüft.” Claude liest das Ergebnis nun über die XML-Zwischenablage des MBS Plugins zurück und vergleicht es mit dem Soll. Das kostet Aufwand, sorgt aber für Sicherheit. Das einfache Web-Layout dagegen klickte sich Claude erstaunlich schnell zusammen.

Frank sieht darin seinen neuen “Auszubildenden”, dem man die Spielregeln von FileMaker einmal beibringen muss. Was er gelernt hat, hält er in Dateien auf Franks Rechner fest – die sich bei Bedarf auch weitergeben lassen. Im besten Fall definiert Frank in ein paar Monaten nur noch den Auftrag, der Agent baut über Nacht, und am nächsten Morgen wird geprüft. Armin malte das Szenario weiter: Azubi duplizieren, und schon hat man eine Firma mit 70 Mitarbeitern – und ist selbst nur noch mit Entscheidungen beschäftigt. Ob das Leben dadurch leichter wird, ist für Frank tatsächlich eine offene Frage: Mehr als zwei Fenster mit parallel arbeitenden Agenten sind ihm zu anstrengend.

Ein Kalender im Web Viewer

Ein weiteres Beispiel stammte vom Vortag. Bei einem Endkunden hatte sich vor Ort herausgestellt, dass der Kalender das wichtigste Arbeitsmittel ist – was vorher niemand kommuniziert hatte. Statt auf Plugins setzt Frank, auch auf Anraten von Bernhard Schulz, auf AI und Web Viewer. Er ließ ein Konzept schreiben und dieses dann umsetzen – während er einkaufen war. Claude baute einen Prototyp mit Dummy-Daten, legte dafür die nötigen Tabellenauftreten und Beziehungen im Beziehungsdiagramm an und suchte selbstständig Fehler.

Grundlage ist die JavaScript-Bibliothek FullCalendar, wo alle Besonderheiten eines Kalenders bereits umgesetzt sind – die AI muss nur noch die Funktionen nutzen.

Live-Demo mit Hindernissen

Zum Abschluss ließ Frank Claude live im Meeting arbeiten. Dazu musste er zunächst die Bedienung von FileMaker freigeben und die Übernahme des Bildschirms bestätigen. Ben Brix gefiel besonders, wie Claude seinen “Kampf” mit der Oberfläche kommentierte: Das Feld wehre sich, also versuche er es anders. Ganz rund lief es nicht – laut Claude blockierte die Zoom-Bildschirmfreigabe die Bedienung.

Für die Skriptlogik würde Frank weiterhin den bewährten Weg bevorzugen – Skripte vorbereiten lassen und per Copy & Paste übertragen –, weil Computer Use deutlich mehr Tokens verbraucht.

Was bedeutet das für andere Werkzeuge?

Armin fragte, was Computer Use für Werkzeuge wie ai2fm und andere Neuentwicklungen bedeutet. Jörg sah darin eine Herausforderung für Claris. Robert Hermann berichtete allerdings aus den Claris Partner Office Hours am selben Nachmittag, dass Claris AI-Funktionen über den Web Viewer direkt einbauen will – ausdrücklich auch für das Programmieren. Marcel ergänzte, dass auch andere Anbieter in diese Richtung arbeiten, innerhalb wie außerhalb von FileMaker.

Entscheidend sei die Rückkopplungsschleife: Der Agent muss nicht nur Felder und Skripte anlegen, sondern anschließend auch auslesen können, ob alles so angekommen ist wie geplant. Erst dann ist die agentische Schleife vollständig, und der Agent kann sich selbst kontrollieren. Mit den verfügbaren Schnittstellen ist das noch nicht möglich – Franks Weg über Computer Use schließt genau diese Lücke. Spannend werde es mit GPT-6 Astra, das in Benchmarks bei Computer Use angeblich weit vor Claude liegt, auch wenn das noch nicht unabhängig bestätigt ist.

Jörg berichtete abschließend von einem verwandten Ansatz: Er hat sämtliche Layouts seiner Lösung analysieren lassen und daraus eine Beschreibung der Oberfläche als JSON erzeugt. Damit beantwortet der Agent Supportanfragen inzwischen mit genauen Klickanleitungen, findet Workarounds und weist sogar darauf hin, wenn mehrere Kunden an derselben Stelle stolpern. Die Erstellung hätte umgerechnet rund 300 Euro an Tokens gekostet. Steht die Beschreibung aber einmal, genügt eine monatliche Aktualisierung, bei der der Agent nur noch die Änderungen in XML oder DuckDB nachzieht.

Marcel lobte vor allem die Struktur mit mehreren Workern und klaren Entscheidungswegen. Frank hat sie sich nach und nach erarbeitet, angeregt unter anderem durch Artikel in c’t und iX, die er dem Agenten zur Bewertung gibt. Es gehe viel um Gegenkontrolle – und um die lückenlose Dokumentation, mit der sich auch Monate später noch nachvollziehen lässt, warum etwas so entschieden wurde.