Desarrollo agéntico en FileMaker: qué es y qué cambia para tu empresa

El 27 de octubre Claris abrió el acceso anticipado a lo que llama desarrollo agéntico para FileMaker: un agente de programación, como Claude Code, Cursor o Codex, que trabaja directamente sobre tu archivo de FileMaker. Lee el esquema, los layouts, los scripts y los cálculos, propone cambios y, después de que alguien los revise, los escribe en el archivo. Claris lo explica en su anuncio: las solicitudes se aceptan de forma progresiva, en diciembre el acceso anticipado se abre a cualquiera y la versión definitiva llega a finales de febrero de 2027.

Para quien tiene una aplicación FileMaker en su empresa, la pregunta no es técnica. Es qué cambia en lo que paga, en lo que espera y en a quién se lo encarga. Nosotros llevamos desde principios de 2026 desarrollando FileMaker con agentes, y tenemos una respuesta que no es la que se suele oír.

Qué es, sin adornos

Hasta ahora, una IA podía escribirte un script de FileMaker, pero no podía ver tu aplicación. Un archivo FileMaker es binario: el modelo no sabía qué tablas tenías, qué campos ni qué scripts llamaban a cuáles. Lo que proponía era a ciegas y había que pasarlo a mano.

El desarrollo agéntico cambia eso. El agente ve la aplicación entera antes de proponer nada, y lo que propone se puede incorporar sin copiar y pegar. Claris insiste en dos cosas que nos parecen las importantes: cada cambio se revisa antes de entrar, y FileMaker sigue siendo quien ejecuta la aplicación con sus permisos de siempre. Necesitará FileMaker 2026.

No es magia ni es nuevo del todo. La comunidad lleva tiempo resolviendo el mismo problema por otra vía: exportar la solución a texto para que la IA la lea y devolver los scripts en el formato del portapapeles. Es lo que hace Agentic FM, el proyecto de código abierto que usamos a diario y al que contribuimos. Lo que trae Claris es hacerlo de forma oficial, directa y sin rodeos.

Lo que hemos aprendido haciéndolo

Hoy tenemos 58 archivos FileMaker indexados para que un agente los consulte: más de 75.000 objetos entre tablas, campos, scripts y layouts, y 958 versiones guardadas de esos archivos. El más grande, de un cliente, tiene 6.535 objetos. Antes de tocar nada, el agente pregunta quién llama a este script o qué se rompe si cambio este campo, y obtiene la respuesta en segundos.

Con eso delante, la IA escribe buen código de FileMaker. A veces mejor de lo que esperábamos: propone ideas que no se nos habían ocurrido, y ya nos sugiere el plan y las pruebas antes de empezar. También se equivoca. Hay que frenarla para que investigue antes de lanzarse, y revisamos todo lo que escribe, porque encontramos fallos con frecuencia. Cada error que repite lo convertimos en una comprobación automática: lo contamos con detalle en la chuleta de nuestra charla en fmCat 2026.

Pero lo que más nos ha enseñado no es dónde falla la IA. Es dónde no puede ayudar.

Lo escaso ya no es el código

Hace unas semanas pedimos a la IA un plan para ampliar el proceso de inscripción y pago de un cliente. El plan era bueno. Y empezaba con una advertencia: había que fijar tres decisiones antes de programar. En qué momento una inscripción pasa de borrador a pendiente de pago. Quién puede habilitar que se edite una vez enviada. Qué pasa con una solicitud presentada a dos categorías cuando solo puede optar a una.

La IA supo que esas preguntas existían. No podía responderlas. Las respuestas no estaban en el código, ni en los 75.000 objetos, ni en ningún documento: estaban en cómo trabaja ese cliente y en lo que había pasado en ediciones anteriores.

Esa es nuestra postura: la IA ya escribe el código; lo escaso es quien conoce el negocio. En el equipo lo decimos de una forma más directa. Lo que tú sabes del cliente es la pregunta que te voy a hacer. El resto lo podemos programar con la IA.

Sabemos que es discutible. Hay quien cree que, si el agente lee la aplicación entera, también entenderá el negocio. Nuestra experiencia es que entiende la estructura muy bien y el porqué muy mal. Un campo le dice qué se guarda, no por qué se decidió guardarlo ni qué cliente se enfadó la vez que no estaba.

Un prototipo no es una aplicación en producción

La otra mitad de la postura tiene que ver con el tiempo. Con estas herramientas, cualquiera puede generar en una tarde algo que funciona en una demo. Pero casi ningún encargo real es una primera versión. Es modificar lo que ya está hecho, con datos de años, usuarios que dependen de ello y otras partes de la aplicación que llaman a lo que vas a cambiar.

Hay una distinción que usamos a diario y que la IA, si nadie se la pide, no hace: separar las reglas del negocio de la interfaz. Esconder un botón para que nadie haga algo indebido funciona en la demo. Pero la regla tiene que existir en otro sitio, porque el día que alguien ponga ese botón en otra pantalla, la regla ya no estará. Las reglas viven en scripts que validan y guardan todo o nada. Esa decisión es de diseño, no de código, y es la que hace que una aplicación aguante cinco años.

Qué cambia para tu empresa

Los cambios van a ser más rápidos, y vas a querer más. Escribir el código cuesta menos tiempo. Eso no significa que una aplicación vaya a costar lo mismo de menos: el tiempo se desplaza a entender bien qué hay que hacer y a comprobar que lo hecho funciona con tus datos reales.

Tu tiempo pesa más. Si el código sale rápido, lo que frena un proyecto son las decisiones pendientes. Las tres preguntas del ejemplo no las respondimos nosotros. Cuanto más claro tenga tu equipo cómo funciona su proceso, más se nota la velocidad del agente.

La herramienta deja de ser lo que te diferencia. Lo que hoy nos parece una maravilla será lo habitual en pocos meses: Claris lo está poniendo al alcance de cualquier desarrollador. Lo que distingue a quien te ayuda pasa a ser cómo trabaja con el agente, qué reglas le pone y cuánto conoce tu negocio.

FileMaker no se queda atrás. Si te preocupaba que tu aplicación FileMaker quedara fuera de la ola de la IA, Claris acaba de responder: va a ser una de las plataformas con las que trabajan estos agentes.

Lo que todavía no sabemos

Es un acceso anticipado. Claris no dice todavía que esté pensado para producción, y la versión definitiva no llegará hasta febrero. No sabemos cómo se comportará con archivos grandes y antiguos, que es donde hoy más nos cuesta dar contexto a la IA. Lo probaremos y lo contaremos con datos.

Lo que sí sabemos es que las herramientas que usamos hoy cambiarán. La forma de trabajar, no: contexto antes que código, reglas antes que pantallas, y una persona que conoce el negocio decidiendo lo que no se puede deshacer.

Si tienes una aplicación FileMaker y quieres saber qué puede cambiar en ella, puedes ver cómo trabajamos en aplicaciones a medida con FileMaker y en inteligencia artificial aplicada, o escribirnos desde contacto.