Adam Augustin knüpfte nahtlos an die Web-Viewer-Diskussion aus der EngageU-Nachlese an – allerdings nicht mit dem Anspruch, FileMaker-Layouts vollständig zu ersetzen. Sein Ansatz sind gezielte Widgets im Web Viewer genau dort, wo die Möglichkeiten der nativen Oberfläche nicht ausreichen. Den Vortrag hatte er zuvor auf der “FM meets Mozart” Konferenz in Salzburg gehalten; am Stammtisch zeigte er das Vorgehen nicht anhand der Folien, sondern live.

Vom Fachwissen zum Widget

Wer Adams Vorträge auf der FMK in den vergangenen Jahren verfolgt hat, kennt seinen Workflow: ein auf Vite basierendes Starterprojekt mit Template, das den Einstieg in die Web-Viewer-Entwicklung vereinfacht. Weil die Möglichkeiten der AI so enorm gewachsen sind, hat er das Projekt vor einigen Monaten so überarbeitet, dass es sich gut mit einem AI-Agenten nutzen lässt. Daraus entstand FM Starter AI, das auf GitHub verfügbar ist.

Das Motto: Starten statt Einrichten. “Ich möchte mich nicht mehr darum kümmern, wie ich ein Projekt starte, sondern nur noch darum, was ich als Ergebnis haben will.” Der Fahrplan ist immer derselbe: Der Entwickler hat eine Idee, unterhält sich mit der AI darüber, was er haben möchte, die AI entwickelt einen Plan und setzt ihn um – und am Ende wird das Ergebnis in FileMaker getestet. Ein interaktives Diagramm, das Adam natürlich ebenfalls per AI erstellen ließ, veranschaulicht diesen Ablauf.

In Salzburg hatte Adam zudem einen zweiten Vortrag zu Git gehalten. Gerade weil die AI immer mehr Code beisteuert, sei es umso wichtiger, die Entwicklungsschritte unter Kontrolle zu behalten. Für textbasierte Web-Viewer-Projekte – anders als für die binäre FileMaker-Datei – bietet sich die Versionierung mit Git geradezu an.

Skills als Leitplanken

Herzstück des Projekts ist ein Set von Skills, die den Agenten durch den gesamten Prozess führen: Die AI weiß dadurch, was sie wann zu tun hat und wie sie mit dem Entwickler interagieren soll. Skills sind schlichte Markdown-Dateien, die man jederzeit einsehen kann. Die beiden wichtigsten Angaben stehen am Anfang: Name und Description. Nur diese Kurzfassung lädt die AI zunächst in den Kontext; erst wenn sich herausstellt, dass ein Skill zur aktuellen Aufgabe passt, liest sie den Rest nach. So bleibt der Kontext möglichst lange frei – und deshalb sollten Skills auch nicht zu lang sein.

Installiert wird der Einstiegs-Skill über das Kommandozeilen-Tool von skills.sh, einer von Vercel initiierten Plattform, die als Suchmaschine für die inzwischen zigtausend verfügbaren Skills dient. Das Tool fragt zunächst, für welche Agenten installiert werden soll – Claude Code, Pi und rund 50 weitere stehen zur Auswahl, jeweils mit ihrem eigenen Skill-Verzeichnis. Empfohlen ist die Installation an einer zentralen Stelle, die per Symlink mit den einzelnen Agenten verknüpft wird. Danach genügt im Agenten der Wahl ein einziger Prompt, um den Skill aufzurufen und ein FileMaker-Web-Viewer-Widget zu erstellen.

Neben dem global installierten Skill bringt das Projekt selbst weitere Skills mit, sowohl im Verzeichnis für Claude als auch in einem allgemeinen Agents-Verzeichnis. Projektbezogene Skills haben dabei Vorrang vor globalen gleichen Namens.

Live-Demo: ein Auftragsmonitor

Adam hatte im Vorfeld bereits vier Beispiele durchgespielt – eine Liste offener Rechnungen, einen Projektzeitstrahl, ein Beziehungsnetz der Projektorganisation und eine Auftragskarte. Für den Stammtisch wagte er ein fünftes Beispiel live: einen Auftragsmonitor, ausgehend von einem leeren Verzeichnis in VS Code mit Claude Code (Opus 5 auf mittlerer Stufe, im Auto-Modus).

Statt der Einzeilen-Variante setzte er einen ausführlicheren, vorbereiteten Start-Prompt ab. Die AI erkannte den Skill und begann das Interview: Soll das Template in diesem Verzeichnis angelegt werden? Woher kommen die Auswahlwerte für Status, Priorität, Techniker und Stadtteil? Gibt es ein repräsentatives, anonymisiertes JSON-Beispiel? Die Antworten diktierte Adam, statt sie zu tippen.

Sein JSON-Beispiel folgt einer klaren Struktur: Ein Teil sind Metadaten – Sprache, Datumsformat, Theme für hell und dunkel –, der andere die eigentlichen Nutzdaten aus den Datensätzen. Erst nachdem alle Informationen vorlagen, erstellte die AI einen Plan mit Namen, Datenfluss, Annahmen und offenen Punkten – und wartete auf die Freigabe. Erst danach entstanden die Plan-Dateien und der Code. Das Projekt wird dabei von Anfang an mit Git versioniert, sodass jeder Entwicklungsschritt nachvollziehbar bleibt.

Mock-Modus und visuelle Kontrolle

Eine Hürde jeder Web-Viewer-Entwicklung: Die Web-Welt ist von der FileMaker-Welt entkoppelt, und bis ein sichtbares Ergebnis mit den FileMaker-Skripten verheiratet ist, vergeht viel Zeit. Adams Lösung ist ein Mock-Modus. Der lokale Entwicklungsserver zeigt das Widget mit dem URL-Parameter data=test im Browser so an, als liefe es bereits in FileMaker. Aufrufe von FileMaker-Skripten werden dabei in der Konsole protokolliert.

Während der Umsetzung kontrolliert die AI ihr Ergebnis selbst im Browser – entweder über Playwright oder die Chrome DevTools. Adam bevorzugt die Kommandozeilen-Variante, weil sie deutlich weniger Tokens verbraucht als ein MCP-Server.

Deployment nach FileMaker

Das Projekt bringt eine FileMaker-Datei mit, die die AI passend umbenannt hatte. Darin lässt sich auf den Entwicklungsserver umschalten, um das Widget direkt mit Live-Daten in FileMaker zu sehen. Für den produktiven Einsatz bündelt Vite den gesamten HTML-, CSS- und JavaScript-Code in eine einzige index.html; das Skript npm run deployToFM überträgt sie in die FileMaker-Datei. Der erste Versuch scheiterte zunächst an einem noch hängenden Skript – FileMaker kann eben nur ein Skript nach dem anderen ausführen –, danach lief das Widget unabhängig vom Entwicklungsserver.

Auch der Rückweg ist abgedeckt: Der Button “Auftrag in FileMaker öffnen” ruft ein generisches FileMaker-Skript auf, dessen Rückmeldung über Erfolg oder Fehlschlag das Widget wieder anzeigt.

Feinschliff per Prompt

Danach beginnt die übliche Detailarbeit, die man von jedem Prototyp kennt. Das Datumsformat im Filter war noch amerikanisch – ein weiterer Prompt genügte, und die AI baute ein deutsches Textfeld ohne Kalender-Picker ein. Einen Mechanismus, der alle nicht ASCII-konformen Sonderzeichen umwandelt, bringt das Projekt bereits mit, damit Umlaute auch in WebDirect korrekt dargestellt werden.

Suchen und Filtern sind im Web Viewer “unschlagbar schnell”, weil es sich nur um JavaScript-Funktionen auf Arrays handelt. Jörg bestätigte das aus eigener Praxis: Seine Aufgabenliste lädt zunächst nur die letzten 400 Datensätze und auf Wunsch weitere Pakete nach. Seine Kunden aus dem Bereich vertikaler Lösungen, die browserbasierte Apps gewohnt sind, jubeln – während Individualkunden, die Meister der nativen FileMaker-Suche sind, mit den üblichen Filtern nicht immer zufrieden wären. Bei sehr großen Datenmengen empfahl Adam ebenfalls, zunächst nur einen Teil zu übergeben und beim Scrollen oder Suchen nachzuladen.

Konventionen und Corporate Design

Holger Pfeiff fragte, wie es sich anfühle, wenn man nach Jahren mit eigenem Stil plötzlich Code von der AI vorgesetzt bekommt. Adams Antwort: Es kommt darauf an, wie man die AI für sich konfektioniert. Udo pflegt dafür eigene Skills mit seinen FileMaker-Standards und Namenskonventionen, Jörg sogar Konventionen pro Kundendatei – und die AI hält sich in aller Regel daran.

Dasselbe gilt für das Design. Weil jeder Web Viewer anders aussah, ließ Jörg sich ein Corporate Design für seine Lösung erstellen, an das sich die AI nun hält – inklusive einheitlicher Platzierung von Such- und Filterelementen. Für Icons empfahl Adam, der AI eine Open-Source-Icon-Bibliothek vorzugeben, statt sie eigene SVGs zeichnen zu lassen, die schnell “wie Kraut und Rüben” aussehen. Wer wie Ben Brix eigene Icons hat, kann der AI per Screenshot die Vorgaben für ein passendes SVG-Set liefern. Armin Egginger ergänzte, dass die Icons einer FileMaker-Datei in deren Library Catalog liegen und die Datei nie wieder verlassen – auch nicht, wenn sie defekt oder ungenutzt sind.

Fallstricke im Web Viewer

Dirk Schittko berichtete von Windows-Anwendern, bei denen der Web Viewer nach einigen Minuten leer wird. Nach Adams Erfahrung liegt das nicht am Web Viewer selbst, sondern an einer Aktualisierung, die etwa über einen Server-Trigger kommt und auf einem Datensatz-Layout den Inhalt des Web Viewers neu lädt.

Als wichtigsten Fallstrick nannte Adam den Dirty State: Schließt ein Anwender das Fenster, sind ungespeicherte Änderungen im Web Viewer verloren – anders als in FileMaker, wo Daten beim Schließen ohnehin gespeichert werden. Ein OnLayoutExit-Trigger fragt deshalb beim Widget nach, ob es ungespeicherte Änderungen gibt, und lässt den Anwender entscheiden, ob er speichern oder verwerfen möchte.

Daran schließt sich die Frage des Record Lockings an. Adam prüft vor dem Speichern den Modification Count: Hat er sich seit dem Laden erhöht, hat ein anderer Benutzer den Datensatz zwischenzeitlich geändert. Jörg wandte ein, dass das nach fünf Minuten mühsamer Eingabe “tödlich” sei; er öffnet deshalb beim Wechsel in den Bearbeitungsmodus per Open Record und sperrt den Datensatz. Udo verwaltet in einer eigenen Tabelle, welcher Datensatz gerade bearbeitet wird, und trennt grundsätzlich zwischen Ansichts- und Bearbeitungslayouts. Und Adam markiert in einer Gutachten-Lösung, wer gerade an einem Text arbeitet – andere Anwender sehen das und kommen nicht in den Editor. Ob das alles nötig ist, hängt allerdings vom Einzelfall ab: Gehört ein Datensatz ohnehin nur einem Benutzer, ist das Risiko gering.

Werkzeuge und Ausblick

Am Rande ging es auch um die Werkzeuge. Dirk empfahl VSCodium als quelloffene Variante von VS Code ohne Microsoft-Telemetrie. Adam arbeitet selbst längst nicht mehr zwingend im Editor; neben VS Code nutzt er Pi als flexiblen Harness mit seinen bestehenden Abonnements. Udo plant mit Claude und lässt die Umsetzung über Goose mit einem lokalen Modell laufen. André Kopietz und Swen Bauer wiesen auf neue Agenten-Werkzeuge hin, die sich direkt mit LM Studio und lokalen Modellen verbinden lassen. Adams Einschränkung: Für Coding wie in dieser Demo sind lokale Modelle noch mühsam – sie sind langsam und stoßen schnell an die Grenzen ihres Kontexts.

André sah in der Demo genau das, was er sich für die Zukunft vorstellt: Software on Demand, bei der man nur noch beschreibt, was man braucht, und FileMaker als zentrale Stelle die Module verbindet. Adam nannte den Haken: Bekommt man bei jedem Prompt ein anderes Interface, braucht es Vorgaben oder ein Basis-Interface, das immer wieder verwendet wird. Was noch fehlt, ist die finale Integration – dass die AI auch die FileMaker-Skripte selbst anpasst. Genau daran arbeitet Claris derzeit.

Adams Fazit: “Einfach ausprobieren. Es tut nicht weh – außer dass es Tokens kostet.” Die Links zum GitHub-Projekt und zu seinen beiden Salzburger Präsentationen stellte er im Anschluss bereit.

Weitere Infos und Download

github: fm-starter-ai
https://github.com/agametis/fm-starter-ai

github: fm-meets-mozart-2026
https://github.com/agametis/fm-meets-mozart-2026