Sobre el pròxim Agentic Development Toolkit de Claris: què encerta, on s’atura, i per què segueixo pensant que el camí més senzill i potent cap al desenvolupament de FileMaker assistit per IA passa per fora del fitxer.
El context #
A Claris Community Live #49, en Wim Decorte (CTO, Soliant Consulting) i la Rosemary Tietge (Claris Community Manager) van explicar a la comunitat l’arquitectura darrere del pròxim Agentic Development Toolkit de Claris per a FileMaker. És la primera mirada real a com Claris pretén portar la programació agèntica, no només l’assistència de chatbot, a la plataforma.
És una peça d’enginyeria ben pensada. També és, crec, una solució a un problema més estret del que sembla a primer cop d’ull, i una que reforça per què he estat portant la lògica de negoci fora de FileMaker en lloc d’intentar fer que FileMaker mateix sigui nadiu d’IA.
Això és el que Claris va mostrar, el que realment resol, on s’atura, i per què crec que la resposta més general encara viu fora del fitxer, almenys de moment.
Què està construint Claris #
L’Agentic Development Toolkit es llançarà com a developer preview més endavant aquest trimestre (2026, encara sense data fixa), distribuït com un plugin de Claude per a Claude Code / Claude Desktop, no com un plugin de FileMaker. Els requisits, tal com es van descriure:
- FileMaker 2026. La majoria d’eines construïdes per la comunitat ja funcionen amb 2025 o 2026, però el mateix toolkit de Claris apunta específicament al 2026.
- Una subscripció a Claude d’Anthropic. Claude Code la requereix. En Wim va reconèixer amb sinceritat que això per si sol serà una bifurcació real en el camí de l’adopció.
- Un fitxer local i tancat. La versió actual requereix que el fitxer de FileMaker estigui local i tancat perquè es pugui aplicar el pedaç. El suport per a fitxers allotjats és un objectiu futur reconegut, no una capacitat actual.
Claude és el harness objectiu inicial perquè és el més adoptat, però les convencions subjacents (skills, agents, MCP) estan convergint entre diferents harnesses, Codex, Cursor, Windsurf entre ells, així que la portabilitat més enllà de Claude no queda descartada arquitectònicament.
El preview es llança en dues parts: la feina d’esquema i scripting (el tema d’aquesta sessió) i una capa d’interfície basada en WebViewer, mostrada abans per la Martha al maig. S’espera que totes dues conflueixin abans de qualsevol llançament de disponibilitat general, per al qual no hi ha data compromesa.
Els fonaments: per què els LLM en cru s’equivoquen amb FileMaker, i què ho soluciona #
Model, harness i MCP són tres coses diferents #
En Wim va traçar una distinció clara que val la pena tenir present per a qualsevol cosa agèntica.
El model (Claude Opus, Sonnet, Haiku, etcètera) és només el generador de respostes. Entra input, surt output. No té agència pròpia i no pot actuar per si mateix. El harness (Claude Code, Codex i similars) és la capa d’aplicació: interpreta la intenció, orquestra eines, i pot fer coses de debò, com llegir fitxers, executar ordres, escriure al porta-retalls. Si el model és el cervell, el harness és l’exosquelet. MCP (Model Context Protocol) no és cap de les dues coses. És només un protocol compartit que el harness fa servir per parlar amb sistemes externs: Jira, QuickBooks, la Data API de FileMaker. El plantejament d’en Wim, que subscric, és que MCP té a veure sobretot amb l’accés a dades, mentre que la programació agèntica té a veure amb l’esquema: taules, camps, scripts, layouts, comptes, privilege sets.
Per què el model sol s’equivoca amb FileMaker #
FileMaker porta més de 40 anys existint, i les dades d’entrenament que el reflecteixen són una barreja d’informació actual i d’una altra ja obsoleta des de fa temps: funcions Status() velles convivint amb els equivalents més nous de Get(), per exemple. Si li demanes ajuda de FileMaker a un model en cru, de vegades inventarà funcions que sonen plausibles però que no existeixen. L’exemple d’en Wim va ser una al·lucinació de SetLayoutObjectAttributes. No perquè el model estigui trencat, sinó perquè la veritat de base d’on parteix és simplement inconsistent.
L’escala: skills, agents, tools #
La solució de Claris ve en tres capes.
- Skills. Fitxers Markdown amb front matter YAML (nom + descripció), desats a
.claude/skills/<name>/SKILL.md. Només el front matter es carrega al context del harness en arrencar; la descripció és el que fa que el harness invoqui la skill completa quan correspon. Això no és el mateix que simplement passar-li al harness la documentació d’ajuda de FileMaker exportada en Markdown. Allò és informació, no una skill accionable. - Agents. Una capa per sobre de les skills: personatges amb nom (un agent per a calcs, un agent per a esquemes) cap als quals l’orquestrador del harness dirigeix la intenció de l’usuari, i que al seu torn invoquen les skills correctes per a la seva especialitat.
- Tools. La capa on viu la feina d’enginyeria real, la part que en Wim anomena la “feina feixuga”.
La idea central: no deixar que el model generi XML #
Aquesta és la decisió arquitectònica més important de tot el sistema. Demanar-li al model que produeixi directament el format XML de l’esquema de FileMaker és lent, car i propens a un bucle de validar-fallar-reintentar contra l’eina de pedaç. En lloc d’això, Claris va preconstruir una biblioteca de plantilles XML validades, derivades de la sortida de Save As XML, que cobreix cada script step, tipus de camp i configuració de diàleg.
L’única feina del model és interpretar la intenció de l’usuari: què ha de dir el títol del diàleg, quants botons, quins camps necessita aquesta taula. El harness llavors selecciona de manera determinista la plantilla correcta i l’omple. Sense endevinar XML pel mig. És la mateixa lògica que una combinació de correspondència: triar la plantilla ja provada, omplir les parts variables.
Com que els passos mecànics no requereixen un model de primer nivell, el cost i la velocitat es redueixen considerablement un cop existeix un pla. La manera de treballar d’en Wim és fer servir un model molt capaç per a l’abast i l’especificació, i després baixar a alguna cosa més barata (Sonnet, en el seu exemple) per a l’execució mecànica, ja que els pressupostos de tokens de la subscripció són finits i el model no necessita raonar gaire un cop el pla ja està fixat.
Com ficar codi dins d’un fitxer binari #
Com que .fmp12 és binari, només hi ha dos vehicles reals per a canvis d’esquema programàtics. L’XML del porta-retalls permet copiar i enganxar objectes de FileMaker, però és limitat: no es poden enganxar comptes ni privilege sets d’aquesta manera. FMUT, la FileMaker (Solution) Upgrade Tool, és l’eina de pedaç oficial i el mecanisme preferit de Claris, perquè pot tocar tots els catàlegs d’esquema, inclosos els layouts.
Totes dues són utilitats de línia d’ordres preexistents i documentades. No hi ha res de nou ni propietari de Claris. Són les mateixes eines disponibles avui per a qualsevol desenvolupador o projecte de la comunitat.
On el toolkit és honest sobre els seus límits #
Cap dels dos ponents va exagerar el sistema, i això és un mèrit de Claris. Els layouts són “terreny de joc” però encara s’estan consolidant; el catàleg d’esquema més complex en XML està explícitament marcat com a feina en curs. Els fitxers allotjats no estan suportats a la versió actual, i si això es convertirà en un requisit abans de la disponibilitat general dependrà del feedback del developer preview. No està garantit que hi arribi per a la GA. La traducció de captures de pantalla o mockups a esquema és inherentment probabilística, també: a diferència dels scripts i els diàlegs, no hi ha un pont determinista entre un layout visual i el seu XML, que és l’únic punt de tot el sistema, per la resta determinista, on el model realment ha d’endevinar. I el toolkit en si es presenta com un refinament, no com una capacitat nova: Claris el descriu com una versió més sistemàtica i de més qualitat del que desenvolupadors i eines de la comunitat (es van esmentar ai2fm, ProofKit i altres) ja fan manualment amb l’ajuda exportada en Markdown i XML fet a mà.
La comunitat ja hi era #
Val la pena dir-ho amb claredat, una cosa que la mateixa Claris només reconeix de passada: el mecanisme darrere del seu toolkit —l’XML del porta-retalls i la FileMaker Solution Upgrade Tool— no és propietari. És infraestructura de línia d’ordres pública i documentada sobre la qual qualsevol desenvolupador ja pot construir. I diversos ja ho han fet.
Una eina que vull assenyalar específicament és ai2fm, construïda per en Dimitris Kokoutsidis. Pren la via del porta-retalls en lloc de la via de l’eina de pedaç que afavoreix Claris, però la filosofia subjacent és sorprenentment semblant: mantenir la IA tan lluny com sigui possible de l’XML nadiu de FileMaker, i donar-li en el seu lloc una representació intermèdia neta, llegible i basada en text.
En concret, ai2fm converteix qualsevol editor compatible amb VS Code en un IDE de FileMaker. Una capa gratuïta ofereix autocompletat, documentació en passar el cursor i validació en viu per a un format .fmscript llegible. Un pipeline de transformació XSLT amb llicència s’encarrega del recorregut d’anada i tornada real: l’XML nadiu del porta-retalls de FileMaker (XMSS i companyia) es tradueix a text de script pla, versionable a Git, es lliura a qualsevol agent d’IA (Claude, Codex, Gemini, Copilot, o un model local) perquè l’editi, i després es tradueix de nou a XML vàlid de FileMaker per enganxar-lo.
Hi ha diversos detalls que destaquen:
- Els 214+ script steps estan suportats, amb salvaguardes contra al·lucinacions d’IA i detecció d’anomalies integrades a la conversió inversa, de manera que si un model s’inventa un pas o un paràmetre, queda atrapat abans d’arribar mai al teu fitxer.
- Les ocurrències de taula, camps o referències a sub-scripts que faltin es comenten en lloc de descartar-se en silenci. Això és exactament el comportament defensiu, sense sorpreses, que es vol de qualsevol cosa que toqui l’esquema de producció.
- Els payloads es processen només en memòria, mai es registren ni s’escriuen a disc, i mai s’utilitzen per entrenar IA.
- Segueix de prop el propi ritme de llançaments de FileMaker, fins al punt d’haver documentat bugs reals de serialització del porta-retalls entre FileMaker 2025 i 2026, i ofereix suport de migració conscient de la versió entre totes dues.
És una bona il·lustració del punt d’abans: el “fossat” en aquest terreny no és el mecanisme, és la qualitat i la cura de la capa de plantilles o traducció construïda a sobre. Claris està formalitzant un patró que la comunitat ja havia demostrat. ai2fm és un dels exemples més seriosos, i actualment en producció, d’aquesta demostració.
On aterro jo realment #
Aquí està la part que més m’importa a mi, com algú que ha passat l’últim temps construint el patró RAPI (Reverse API Integration) en diversos casos de producció.
Fixa’t en el que va caldre construir perquè l’autoria agèntica d’esquema fos fiable: una biblioteca de plantilles determinista completa, un bucle de pedaçar/validar/reaplicar, un requisit de fitxer sense connexió, a més d’admissions obertes que els layouts són fràgils i que els fitxers allotjats encara no estan resolts. És molt esforç d’enginyeria invertit a fer que la IA sigui segura d’usar contra un objectiu que és tancat, binari i fràgil davant les versions per naturalesa.
RAPI pren una via estructuralment diferent. En lloc d’intentar fer que FileMaker mateix sigui segur perquè la IA hi escrigui, manté FileMaker com una superfície de persistència i disparador de confiança, i trasllada la lògica de negoci a capes funcionals externes accessibles via OData. Això elimina de cap a cap la baralla amb el format binari: JSON i REST/OData són formats que qualsevol model ja maneja amb fluïdesa, així que el problema d’al·lucinació d’XML mai arriba a plantejar-se. També elimina el requisit de fitxer sense connexió, ja que la capa externa funciona perfectament contra fitxers allotjats sense necessitat de portar res local o tancat. I elimina la biblioteca de plantilles: no hi ha una col·lecció paral·lela, ancorada a cada versió, de fragments XML de FileMaker validats que calgui actualitzar amb cada llançament anual de FileMaker. Com que l’objectiu no és hostil, qualsevol model o harness serveix. No cal la curosa estratègia de nivells de model de Claris només per mantenir els costos a ratlla.
Això no és una afirmació que RAPI “guanyi” al toolkit de Claris. És una afirmació més acotada i més útil: RAPI dissol la necessitat de l’enfocament més difícil i més fràgil en tota una classe de problemes, allà on el paper de FileMaker és de persistència i disparador, i no el lloc on realment viu la lògica de negoci. Això és una part gran de la feina real d’integració i automatització.
El que RAPI no toca és la porció restant: l’evolució d’esquema pròpiament dita, l’autoria de layouts, i la lògica nativa de FileMaker que ha de viure dins del fitxer. Per a aquesta porció, l’enfocament de plantilles deterministes de Claris és la resposta més honesta i defensable a un problema difícil, fins i tot en la seva forma actual, primerenca i estreta.
La conclusió pràctica #
Si estàs decidint on invertir esforç per portar IA al desenvolupament de FileMaker avui: mou primer tota la lògica que puguis fora de FileMaker. Allà on el paper del fitxer és de dades i disparadors i no de presa de decisions, OData més una capa funcional externa et dona desenvolupament assistit per IA sense cap dels costos del format binari. Reserva l’autoria agèntica d’esquema dins del fitxer per al que realment hagi de viure-hi, i entra-hi amb expectatives realistes: només fitxers locals, només 2026, un requisit de subscripció, layouts encara consolidant-se. I vigila de prop la qüestió dels fitxers allotjats. És la variable més important que determinarà si el toolkit de Claris es converteix en una eina diària per al desenvolupador mitjà de FileMaker o es queda com una ajuda per a iteració local en solitari.
El mecanisme que va construir Claris —plantilles, pedaçar, validar, reaplicar— és bona enginyeria, i demostra gent que s’ha topat amb les fallades reals en lloc de limitar-se a teoritzar-hi. Però l’esforç d’enginyeria invertit a fer que un entorn hostil sigui segur per a la IA continua sent, al final, un esforç que no cal gastar si pots triar un entorn més amable per a les parts del sistema que en realitat no necessiten viure dins de FileMaker.
Nota de l’autor. Tot l’anterior és la meva interpretació del que es va mostrar a la retransmissió de Claris Community Live #49, i reflecteix la meva opinió personal. Puc haver interpretat alguna cosa malament o tret una conclusió equivocada en algun punt; si creieu que alguna cosa es llegiria d’una altra manera, agraeixo els vostres comentaris.