Thomas Hirt teilte seine Praxiserfahrungen mit dem agentischen Erzeugen von FileMaker-Code über FM-Lab. Zusammen in einer Übersicht seines Setups, die das Zusammenspiel der Komponenten erklärt, koppelte er seinen Erfahrungsbericht mit einer fachlichen Einordnung der beteiligten Bausteine.

Drei Komponenten – und eine vierte

Wer mit FM-Lab arbeitet, hat es im Kern mit drei Komponenten zu tun: dem Entwickler am FileMaker-Arbeitsplatz, dem AI-Agenten (bei Thomas meist Claude) und FM-Lab als Backend. Thomas hat dieses Gespann um eine vierte, selbstgebaute Schicht erweitert.

Der Zyklus beginnt bei der FileMaker-Lösung mit einem Save as XML-Export. Dieser geht an den FM-Lab-Konverter, der daraus den DuckDB-Katalog aufbaut. Für Thomas ist das die absolute Grundvoraussetzung:

Ich kreiere nicht einfach irgendein Script, wo ich nachher alle Bezüge noch korrigieren und prüfen muss – FM-Lab kennt meine Lösung, jede ID, jeden Namen, einfach alles.

Der Agent zapft zuerst genau diesen Katalog an: Bevor er coden kann, muss er wissen, was überhaupt da ist. Als zweite Quelle nutzt er fm-spec – die Datenbank darüber, wie man FileMaker tatsächlich programmiert. Aus Katalog und Spezifikation entsteht der Scriptvorschlag, der anschließend durch die Pipeline fm_generate_script läuft, wo geparst, aufgelöst, erzeugt und im Gate geprüft wird. Thomas verfolgt an den Kommentaren des Agenten mit, wie er Rückmeldungen aus der Pipeline verarbeitet und Fehler korrigiert, noch bevor ein Ergebnis bei ihm ankommt.

Die eigene Nachbearbeitungsschicht

Ein formal korrektes Script war Thomas nicht genug. Er wollte eine In-Code-Dokumentation und einen Script-Header mit eigenem Aufbau, Variablen benannt nach seinen Regeln, Tabellenverweise nach seinen Konventionen.

Grundlage dafür ist eine Dokumentation, die er als Markdown-Dateien in Obsidian pflegt und die jeden Aspekt seiner FileMaker-Nomenklatur abdeckt. Bemerkenswert ist, wie unspektakulär die Anforderung an diese Dokumentation ist: Sie ist nicht speziell für eine AI geschrieben, sondern schlicht strukturiert und systematisch gegliedert – solides ingenieurmäßiges Vorgehen. Auf dieser Basis ließ sich gemeinsam mit Claude ein Python-Script bauen, das als Zusatzschicht auf dem FM-Lab-Output aufsetzt.

An die so definierten Regeln hält sich die AI sehr streng – teils strenger als Thomas selbst. Liefert er eine überarbeitete Version zurück, kommt schon mal der Hinweis, dass er an dieser und jener Stelle seine eigene Nomenklatur nicht eingehalten habe. Das Review läuft also in beide Richtungen.

Null Paste-Fehler

Am Ende der Pipeline steht der Paste-Test: Das erzeugte Script wandert über die Zwischenablage in die FileMaker-Lösung. Und hier fiel das eindrücklichste Statement zum Ablauf:

Inzwischen habe ich bei keinem einzigen Script mehr einen Paste-Fehler. Null. Ich bin im Moment an einem elend langen, komplizierten Script mit etwa 1.200 Zeilen. Null Fehler.

Danach beginnt für Thomas der zweite Teil der Arbeit: prüfen, was gebaut wurde, den Stil beurteilen, überarbeiten, entscheiden – und dann wieder in den Austausch mit dem Agenten für die nächste Iteration gehen.

Stilles Scheitern

So beeindruckend die syntaktische Fehlerfreiheit ist, so klar benannte Thomas die Kehrseite. Das heikelste Thema beim Arbeiten mit AI sei das stille Scheitern: wenn die Modelle nicht realisieren, dass sie etwas nicht wissen. Dann kommen zwar alle Prüfungen durch – das Script lässt sich einwandfrei einfügen und hat trotzdem inhaltliche Fehler.

Grün bedeutet also nicht “keine Fehler”, sondern nur “keine gefundenen Fehler”. Die Frage, ob es inhaltliche Probleme geben könnte, welche die syntaktische Prüfung nicht finden konnte, lässt sich bei großen Lösungen als Mensch kaum noch beantworten – gestellt werden muss sie trotzdem.

Wo die AI noch schwach ist: Konzepte

Die zweite, für Thomas grundsätzlichere Schwäche liegt bei Konzepten und Abstraktion. Bei Formalismen und Syntax sei die AI übermenschlich gut – “da haben wir keine Chance”. Ein wirklich elegantes Script habe er dagegen kaum je bekommen: Formal korrekter Code, bei dem alten Hasen dennoch die Haare zu Berge stehen. Das lange Beispielscript, das er mehrfach erwähnte, sei nicht falsch gewesen, aber ineffizient – das Rad wurde mehrfach neu erfunden, statt bestehende Konzepte wiederzuverwenden.

Auf Nachfrage präzisierte Thomas diese Einschätzung: Im zweiten Bereich, in dem er intensiv mit AI arbeitet – PowerShell-Scripting für die Windows-Administration –, stellt er dieses Problem nicht fest. Dort seien die Fragestellungen viel enger, technischer und klarer umrissen; das mache Claude sehr gut, elegant und effizient. Der Unterschied liege im Kontext: Bei einem Script, das durch die halbe Lösung tanzt und unterschiedlichste Daten verstehen, abgleichen, zuordnen und validieren muss, ist schlicht schwerer zu erfassen, worauf der Programmierer eigentlich hinauswill.

Fazit: komplementär, nicht ersetzend

Thomas schloss mit einer klaren Einordnung des Verhältnisses von Mensch und Agent, Stand Spätsommer 2026: Die maschinelle Gründlichkeit fängt die menschlichen Routinefehler ab – wer dreißigmal dasselbe eintippt, macht ein- oder zweimal einen Tippfehler, die AI praktisch nie. Umgekehrt bleibt die menschliche Abstraktion unersetzlich.

Der entscheidende Punkt ist für ihn das Universe of Discourse – das Gebiet, das man mit einer FileMaker-Lösung bearbeitet. Ein Use Case ist eben nicht rein virtuell: Da gibt es Menschen und Gegenstände, die in der physischen Welt leben, und damit kann eine AI per se nichts anfangen. Ob Schreinerei, Hedgefonds, Immobilienbewertung oder Autowerkstatt – dieses Verständnis ist die Spezialität des Entwicklers. Erst wenn alles beschrieben und ein Datenmodell erstellt ist, kann die AI beim Überarbeiten und Schleifen wieder helfen.

“Ich darf noch was tun, ich bin noch nicht überflüssig”, fasste Thomas es zusammen. “Es dauert noch drei Versionen von FM-Lab, bis ich überflüssig bin.”