Thomas Hirt steuerte einen ausführlichen Praxisbericht zum Einsatz von FM-Lab bei – dem auf DuckDB basierenden Analyse-Framework, das eine komplette FileMaker-Lösung als strukturierten Objektkatalog für AI-Agenten verfügbar macht. Während FM-Lab beim Stammtisch in den Vormonaten als Werkzeug vorgestellt wurde, zeigte Thomas nun, wie es sich im echten Projektalltag schlägt.

Ausgangssituation

Thomas betreut eine komplexe, rund 20 Jahre alte FileMaker-Legacy-Lösung, die fachlich wertvoll, technisch aber kaum noch zu überschauen ist. Mit FM-Lab in Kombination mit Claude analysiert er Skripte und Prozesse der Datenbank deutlich effizienter.

Technisches Setup

  • Infrastruktur: Für die Analyse setzte Thomas eine dedizierte Linux-VM (Ubuntu 26) mit DuckDB und FM-Lab auf. Die AI greift nicht über eine REST-API, sondern über einen sicheren SSH-Tunnel direkt auf die VM zu.
  • Ressourcen: Der Import der XML-Dateien aus FileMaker ist ressourcenintensiv und benötigte temporär 48 GB RAM. Der gesamte Import dauerte etwa 80 Minuten, die resultierende DuckDB-Datenbank ist mit rund 1 GB hingegen erfreulich kompakt.
  • Preprocessing: Da die bisherige FM-Lab Version noch nicht auf Linux abgestimmt war, schlugen eingebaute Konvertierungschritte fehl. Thomas schalte daher ein eigenes Preprocessing vor, um UTF-16 nach UTF-8 zu konvertieren und ungültige Zeichen herauszufiltern. Um die Performance nicht zu belasten, entfernt er für die Strukturanalyse irrelevante Container- und Binärdaten.

Ergebnisse

Thomas berichtet von hervorragenden Resultaten: Die AI liefert brauchbare Analysen zu Prozessabläufen und Parameterübergaben und reduziert seine Analysezeit um bis zu 90 % – das hat ihm bereits Dutzende Arbeitsstunden erspart.

Feature-Requests und vorgefundene Bugs, etwa bei der unvollständigen Auslesung von Skript-Triggern, meldet Thomas direkt an Marcel, der sie aktiv behebt.

Für kritische Eingriffe empfiehlt Thomas eine strikte Isolation des Analyse-Hosts und regelmäßige Image-Backups. Bei besonders heiklen Code-Abfragen verifiziert er die AI-Ergebnisse zusätzlich durch einen direkten Abgleich mit den rohen XML-Daten. (Dieser Schritt ist in einer neueren FM-Lab Version nicht mehr erforderlich.)

Fazit

Obwohl es sich bei FM-Lab noch um eine Beta-Version handelt, die nachweislich einige Bugs und Lücken enthält, war der Produktivitäts-Gewinn im vorliegenden Projekt bereits enorm. Durch zusätzliche Tests sicherte Thomas seine Ergebnisse ab. Das gewählte Setup hat sich für den produktiven Betrieb bewährt.

Diskussion: Token-Kosten und lokale AI-Modelle

Im Anschluss entspann sich eine lebhafte Diskussion über die Verwendung von AI-Tools. Insbesondere weil bisherige Ansätze für Agentisches Coding auf Basis von FileMaker XML eine hohe Token-Last erzeugen können.

Marcel wies darauf hin, dass FM-Lab durch die Nutzung von DuckDB mit einem vorher gesäuberten Objekt-Katalog extrem sparsam arbeitet: Die AI hat somit gezielten Zugriff auf einen Knowledge-Graph und navigiert per SQL durch die Daten, was den Token-Verbrauch auf geschätzt 2 % bis 5 % gegenüber herkömmlichen Methoden senkt.

Um Kosten weiter zu senken, diskutierte die Runde den Einsatz lokaler, quantisierter AI-Modelle. Positiv hervorgehoben wurden Qwen 3.6 (27b-coding) und Gemma 4. Ein konkreter Test mit FM-Lab steht noch aus.