Sobre el próximo Agentic Development Toolkit de Claris: qué acierta, dónde se detiene, y por qué sigo pensando que el camino más sencillo y potente hacia el desarrollo de FileMaker asistido por IA pasa por fuera del archivo.
El contexto #
En Claris Community Live #49, Wim Decorte (CTO, Soliant Consulting) y Rosemary Tietge (Claris Community Manager) explicaron a la comunidad la arquitectura detrás del próximo Agentic Development Toolkit de Claris para FileMaker. Es la primera mirada real a cómo Claris pretende llevar la programación agéntica, no solo la asistencia de chatbot, a la plataforma.
Es una pieza de ingeniería bien pensada. También es, creo, una solución a un problema más estrecho de lo que parece a primera vista, y una que refuerza por qué he estado llevando la lógica de negocio fuera de FileMaker en lugar de intentar hacer que FileMaker mismo sea nativo de IA.
Esto es lo que Claris mostró, lo que realmente resuelve, dónde se detiene, y por qué creo que la respuesta más general sigue viviendo fuera del archivo, al menos por ahora.
Lo que Claris está construyendo #
El Agentic Development Toolkit se lanzará como developer preview más adelante este trimestre (2026, sin fecha fija todavía), distribuido como un plugin de Claude para Claude Code / Claude Desktop, no como un plugin de FileMaker. Los requisitos, tal como se describieron:
- FileMaker 2026. La mayoría de las herramientas construidas por la comunidad ya funcionan con 2025 o 2026, pero el propio toolkit de Claris apunta específicamente a 2026.
- Una suscripción a Claude de Anthropic. Claude Code la requiere. Wim fue sincero al reconocer que esto por sí solo será una bifurcación real en el camino de la adopción.
- Un archivo local y cerrado. La versión actual requiere que el archivo de FileMaker esté local y cerrado para poder aplicarle el parche. El soporte para archivos alojados es un objetivo futuro reconocido, no una capacidad actual.
Claude es el harness objetivo inicial porque es el más adoptado, pero las convenciones subyacentes (skills, agents, MCP) están convergiendo entre distintos harnesses, Codex, Cursor, Windsurf entre ellos, así que la portabilidad más allá de Claude no queda descartada arquitectónicamente.
El preview se lanza en dos partes: el trabajo de esquema y scripting (el tema de esta sesión) y una capa de interfaz basada en WebViewer, mostrada antes por Martha en mayo. Se espera que ambas confluyan antes de cualquier lanzamiento de disponibilidad general, para el cual no hay fecha comprometida.
Lo fundamental: por qué los LLM en bruto se equivocan con FileMaker, y qué lo soluciona #
Modelo, harness y MCP son tres cosas distintas #
Wim trazó una distinción clara que vale la pena tener presente para cualquier cosa agéntica.
El modelo (Claude Opus, Sonnet, Haiku, etcétera) es solo el generador de respuestas. Entra input, sale output. No tiene agencia propia y no puede actuar por sí mismo. El harness (Claude Code, Codex y similares) es la capa de aplicación: interpreta la intención, orquesta herramientas, y puede realmente hacer cosas, como leer archivos, ejecutar comandos, escribir en el portapapeles. Si el modelo es el cerebro, el harness es el exoesqueleto. MCP (Model Context Protocol) no es ninguna de las dos cosas. Es solo un protocolo compartido que el harness usa para hablar con sistemas externos: Jira, QuickBooks, la Data API de FileMaker. El planteamiento de Wim, que suscribo, es que MCP tiene que ver sobre todo con el acceso a datos, mientras que la programación agéntica tiene que ver con el esquema: tablas, campos, scripts, layouts, cuentas, privilege sets.
Por qué el modelo solo se equivoca con FileMaker #
FileMaker lleva más de 40 años existiendo, y los datos de entrenamiento que lo reflejan son una mezcla de información actual y otra ya obsoleta desde hace tiempo: viejas funciones Status() conviviendo con los equivalentes más nuevos de Get(), por ejemplo. Si le pides ayuda de FileMaker a un modelo en bruto, a veces inventará funciones que suenan plausibles pero que no existen. El ejemplo de Wim fue una alucinación de SetLayoutObjectAttributes. No porque el modelo esté roto, sino porque la verdad de base de la que parte es simplemente inconsistente.
La escalera: skills, agents, tools #
La solución de Claris viene en tres capas.
- Skills. Archivos Markdown con front matter YAML (nombre + descripción), guardados en
.claude/skills/<name>/SKILL.md. Solo el front matter se carga en el contexto del harness al arrancar; la descripción es lo que hace que el harness invoque la skill completa cuando corresponde. Esto no es lo mismo que simplemente pasarle al harness la documentación de ayuda de FileMaker exportada en Markdown. Eso es información, no una skill accionable. - Agents. Una capa por encima de las skills: personas con nombre (un agente para calcs, un agente para esquemas) hacia los que el orquestador del harness dirige la intención del usuario, y que a su vez invocan las skills correctas para su especialidad.
- Tools. La capa donde vive el trabajo de ingeniería real, la parte que Wim llama el “trabajo pesado”.
La idea central: no dejar que el modelo genere XML #
Esta es la decisión arquitectónica más importante de todo el sistema. Pedirle al modelo que produzca directamente el formato XML del esquema de FileMaker es lento, caro y propenso a un bucle de validar-fallar-reintentar contra la herramienta de parcheo. En su lugar, Claris preconstruyó una biblioteca de plantillas XML validadas, derivadas de la salida de Save As XML, que cubre cada script step, tipo de campo y configuración de diálogo.
El único trabajo del modelo es interpretar la intención del usuario: qué debe decir el título del diálogo, cuántos botones, qué campos necesita esta tabla. El harness entonces selecciona de forma determinista la plantilla correcta y la rellena. Sin adivinar XML de por medio. Es la misma lógica que una combinación de correspondencia: elegir la plantilla ya probada, rellenar las partes variables.
Como los pasos mecánicos no requieren un modelo de primer nivel, el coste y la velocidad se reducen considerablemente una vez que existe un plan. La forma de trabajar de Wim es usar un modelo muy capaz para el alcance y la especificación, y luego bajar a algo más barato (Sonnet, en su ejemplo) para la ejecución mecánica, ya que los presupuestos de tokens de la suscripción son finitos y el modelo no necesita razonar mucho una vez que el plan está fijado.
Cómo meter código en un archivo binario #
Como .fmp12 es binario, solo hay dos vehículos reales para cambios de esquema programáticos. El XML del portapapeles permite copiar y pegar objetos de FileMaker, pero es limitado: no se pueden pegar cuentas ni privilege sets de esta forma. FMUT, la FileMaker (Solution) Upgrade Tool, es la herramienta de parcheo oficial y el mecanismo preferido de Claris, porque puede tocar todos los catálogos de esquema, incluidos los layouts.
Ambas son utilidades de línea de comandos preexistentes y documentadas. No hay nada nuevo ni propietario de Claris en ellas. Son las mismas herramientas disponibles hoy para cualquier desarrollador o proyecto de la comunidad.
Dónde el toolkit es honesto sobre sus límites #
Ninguno de los ponentes exageró el sistema, y eso es un mérito de Claris. Los layouts son “terreno de juego” pero todavía se están consolidando; el catálogo de esquema más complejo en XML está explícitamente marcado como trabajo en progreso. Los archivos alojados no están soportados en la versión actual, y si eso se convertirá en un requisito antes de la disponibilidad general dependerá del feedback del developer preview. No está garantizado que llegue para la GA. La traducción de capturas de pantalla o mockups a esquema es inherentemente probabilística, también: a diferencia de los scripts y los diálogos, no hay un puente determinista entre un layout visual y su XML, que es el único punto de todo el sistema, por lo demás determinista, donde el modelo realmente tiene que adivinar. Y el toolkit en sí se presenta como un refinamiento, no como una capacidad nueva: Claris lo describe como una versión más sistemática y de mayor calidad de lo que desarrolladores y herramientas de la comunidad (se mencionaron ai2fm, ProofKit y otras) ya hacen manualmente con la ayuda exportada en Markdown y XML construido a mano.
La comunidad ya estaba aquí #
Vale la pena decirlo con claridad, algo que la propia Claris solo reconoce de pasada: el mecanismo detrás de su toolkit —el XML del portapapeles y la FileMaker Solution Upgrade Tool— no es propietario. Es infraestructura de línea de comandos pública y documentada sobre la que cualquier desarrollador ya puede construir. Y varios ya lo han hecho.
Una herramienta que quiero señalar específicamente es ai2fm, construida por Dimitris Kokoutsidis. Toma la vía del portapapeles en lugar de la vía de la herramienta de parcheo que favorece Claris, pero la filosofía subyacente es sorprendentemente similar: mantener a la IA lo más lejos posible del XML nativo de FileMaker, y darle en su lugar una representación intermedia limpia, legible y basada en texto.
En concreto, ai2fm convierte cualquier editor compatible con VS Code en un IDE de FileMaker. Una capa gratuita ofrece autocompletado, documentación al pasar el cursor y validación en vivo para un formato .fmscript legible. Un pipeline de transformación XSLT con licencia se encarga del recorrido de ida y vuelta real: el XML nativo del portapapeles de FileMaker (XMSS y compañía) se traduce a texto de script plano, versionable en Git, se entrega a cualquier agente de IA (Claude, Codex, Gemini, Copilot, o un modelo local) para su edición, y luego se traduce de vuelta a XML válido de FileMaker para pegarlo.
Hay varios detalles que destacan:
- Los 214+ script steps están soportados, con salvaguardas contra alucinaciones de IA y detección de anomalías integradas en la conversión inversa, de modo que si un modelo se inventa un paso o un parámetro, queda atrapado antes de llegar jamás a tu archivo.
- Las ocurrencias de tabla, campos o referencias a sub-scripts que falten se comentan en lugar de descartarse en silencio. Eso es exactamente el comportamiento defensivo, sin sorpresas, que uno quiere de cualquier cosa que toque el esquema de producción.
- Los payloads se procesan solo en memoria, nunca se registran ni se escriben en disco, y nunca se usan para entrenar IA.
- Está siguiendo de cerca el propio ritmo de lanzamientos de FileMaker, hasta el punto de haber documentado bugs reales de serialización del portapapeles entre FileMaker 2025 y 2026, y ofrece soporte de migración consciente de la versión entre ambas.
Es una buena ilustración del punto de antes: el “foso” en este terreno no es el mecanismo, es la calidad y el cuidado de la capa de plantillas o traducción construida encima. Claris está formalizando un patrón que la comunidad ya había demostrado. ai2fm es uno de los ejemplos más serios, y actualmente en producción, de esa demostración.
Dónde aterrizo yo realmente #
Aquí está la parte que más me importa a mí, como alguien que ha pasado el último tiempo construyendo el patrón RAPI (Reverse API Integration) en varios casos de producción.
Fíjate en lo que hubo que construir para que la autoría agéntica de esquema fuera confiable: una biblioteca de plantillas determinista completa, un bucle de parchear/validar/reaplicar, un requisito de archivo sin conexión, además de admisiones abiertas de que los layouts son frágiles y que los archivos alojados aún no están resueltos. Es mucho esfuerzo de ingeniería invertido en hacer que la IA sea segura de usar contra un objetivo que es cerrado, binario y frágil frente a las versiones por naturaleza.
RAPI toma una vía estructuralmente distinta. En lugar de intentar hacer que FileMaker mismo sea seguro para que la IA escriba en él, mantiene a FileMaker como una superficie de persistencia y disparo de confianza, y traslada la lógica de negocio a capas funcionales externas accesibles vía OData. Eso elimina por completo la pelea con el formato binario: JSON y REST/OData son formatos que cualquier modelo ya maneja con fluidez, así que el problema de alucinación de XML nunca llega a plantearse. También elimina el requisito de archivo sin conexión, ya que la capa externa funciona perfectamente contra archivos alojados sin necesidad de traer nada local o cerrado. Y elimina la biblioteca de plantillas: no hay una colección paralela, anclada a cada versión, de fragmentos XML de FileMaker validados que haya que actualizar con cada lanzamiento anual de FileMaker. Como el objetivo no es hostil, cualquier modelo o harness sirve. No hace falta la cuidadosa estrategia de niveles de modelo de Claris solo para mantener los costes bajo control.
Esto no es una afirmación de que RAPI “gane” al toolkit de Claris. Es una afirmación más acotada y más útil: RAPI disuelve la necesidad del enfoque más difícil y más frágil en toda una clase de problemas, allí donde el papel de FileMaker es de persistencia y disparo, y no el lugar donde realmente vive la lógica de negocio. Eso es una parte grande del trabajo real de integración y automatización.
Lo que RAPI no toca es la porción restante: la evolución de esquema propiamente dicha, la autoría de layouts, y la lógica nativa de FileMaker que tiene que vivir dentro del archivo. Para esa porción, el enfoque de plantillas deterministas de Claris es la respuesta más honesta y defendible a un problema difícil, incluso en su forma actual, temprana y estrecha.
La conclusión práctica #
Si estás decidiendo dónde invertir esfuerzo para llevar IA al desarrollo de FileMaker hoy: mueve primero toda la lógica que puedas fuera de FileMaker. Allí donde el papel del archivo es de datos y disparadores y no de toma de decisiones, OData más una capa funcional externa te da desarrollo asistido por IA sin ninguno de los costes del formato binario. Reserva la autoría agéntica de esquema dentro del archivo para lo que realmente tenga que vivir ahí, y entra con expectativas realistas: solo archivos locales, solo 2026, un requisito de suscripción, layouts todavía consolidándose. Y vigila de cerca la cuestión de los archivos alojados. Es la variable más importante que determinará si el toolkit de Claris se convierte en una herramienta diaria para el desarrollador medio de FileMaker o se queda como una ayuda para iteración local en solitario.
El mecanismo que construyó Claris —plantillas, parchear, validar, reaplicar— es buena ingeniería, y demuestra gente que se ha topado con los fallos reales en lugar de limitarse a teorizar sobre ellos. Pero el esfuerzo de ingeniería invertido en hacer que un entorno hostil sea seguro para la IA sigue siendo, al final, un esfuerzo que no hace falta gastar si puedes elegir un entorno más amable para las partes del sistema que en realidad no necesitan vivir dentro de FileMaker.
Nota del autor. Todo lo anterior es mi interpretación de lo que se mostró en la retransmisión de Claris Community Live #49, y refleja mi opinión personal. Puedo haber interpretado algo mal o sacado una conclusión equivocada en algún punto; si crees que algo se leería de otra forma, te agradezco tus comentarios.